Hacker Newsnew | past | comments | ask | show | jobs | submit | dieblur's commentslogin

I think the argument isn't so much that "everyone needs to be able to push to production" as much as "more than one person should be able to push to production". Bus factor is an important variable.


That's like saying a company needs two CEOs because of bus factor.

Somebody else can take over the role of being responsible for pushing to production any time.


Not if they've never done it before.


When it’s a no-tools manual process? Unlikely.


Why use a centralized server to guarantee unique usernames instead of using a public key as a username?, potentially with a friendly alias?


It's a UX tradeoff. People are used to services having unique usernames for everyone which they can use to look friends up. No one wants to say oh just add me on X I'm Qmeufhj32f84hfnejcn438f. Or Add me on X I'm one of the 100 people with real name Bob. Long term it doesn't need to be physically centralized and would make a good candidate for a blockchain with consensus. It's already an append only merkle-tree which is mirrored in other nodes for privacy of public key look ups.

The other effect it has is it allows us to have a global filesystem with all the semantics people are used to from filesystems with human readable paths of the form /$username/$path_in_users_space


What algorithms? Pretty bare README for a cryptography project.


Tanker developer here. We use libsodium as our underlying cryptographic library. It uses XChacha20/Poly1305 for symmetric encryption, Curve25519 for asymmetric encryption and signature, and Blake2 for hashing.


Why would I use your library over the tried and true https://github.com/dchest/tweetnacl-js ?


TweetNaCl is roughly equivalent to libsodium, on which Tanker builds. Tanker is easier to integrate into your app because it takes care of key sharing, multi-devices, user group managment, etc. These are all things you would have to handle by yourself using just a cryptographic library like TweetNaCl.


...and moving from one company to another with the same vision is a silly idea? Pretty obvious...


...moving to another conglomerate being silly is definitely not a moot point.


This doesn't even begin to make sense. You can't force people to register any creation on the blockchain and there can't be a main "only real things allowed" chain. If we want to shoehorn a blockchain into every possible problem ever, lets begin with ones that could actually work.


The idea is to enforce equipment manufacturers to prepare uniquely identifiable IDs in all imagery/footage their equipment produces, entice all software vendors to register all operations in a blockchain and store a reference to it in metadata; then reject any footage that can't have all steps verified as "fake".

How is that any different than tracking production inputs in logistic chains using blockchain?


Nothing can stop me from pointing a camera at my computer monitor and recording a verified video of a non-verified video.


Sure, but in that case your chain starts with your camera, producing "pro" looking video which would be totally unlikely (not mentioning trivial stuff like noticing monitor/lens distortions etc.). Analyzing subsequent processing steps stored in blockchain would likely show very low probability of authentic work due to missing many required steps (OK, there is still certain low probability you can fool it somehow, but would you want to waste so much time/processing power on it?)


This is whack-a-mole. If I can design deepfake software, it isn't much harder to design it to specifically anticipate the user filming the result. The user would input their monitor specs, their camera specs, etc., and the software would produce a weirdly distorted video which looks perfect when filmed with that camera from that monitor.

Or, people just outright sell doctored cameras where you can intercept the input feed.

This isn't like adult content filtering, where all that matters is that kids can't get around it. You have to assume people who know what they're doing are going to attack your technical solution, and apply ingenuity in doing so. When the enemy consists of hackers, you can't ward them off with a hack!


I believe that the usual response to this is that the devices include some kind of unmodifiable time and location stamping, although that argument spirals out of control pretty quickly.


Line-count really isn't a great way to measure developer productivity either though...


It does measure bug count though.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: