doc-golix

pable of eventual decentralization [1], doesn't that imply heavy use of cryptography? I can't imagine a digital network where you can create privacy (and therefore agency) any other way. And yet clearly, government entities like the FBI are publicly railing against encryption as a useful tool for terrorists and criminals. Plenty of people, myself included, find this policy debate to be frighteningly under-informed, but if your goal is to avoid government attention to maximize the chances for success, it's not our opinion that matters, it's the FBI's. So I think think this kind of friction is unavoidable, implying the smart money is on people who can cleverly minimize its impact. [1] On a related note, I'm working on exactly this problem, at a protocol level. If you're curious, check out our documentation repo https://github.com/Muterra/doc-muse

And different organizations will have different requirements for trust: for example your bank is going to have very different requirements to "name" your account than, say, Facebook. Informally I've called this the difference between identity authentication vs identity verification, but I know that's not ideal terminology -- does anyone have a better suggestion? [1] https://github.com/Muterra/doc-muse

er determine what data is acquired, stored, shared, etc. If this mischaracterizes any of the above protocols, I would be really grateful for corrections. It's to everyone's benefit to understand the high-level technical details of these projects. However, the system architecture described above is not, in my mind, a tenable approach to distributable social applications. Simply put, this kind of "private server as my digital avatar" + "protocol so avatars can talk" paradigm completely misses the appropriate choice of abstractions and division of concerns for social applications. First and foremost, this is still yet another example of "privacy by promise". It just so happens that the promise is given to you by the servers of whomever you're sharing with. But then, as data is decrypted at rest, you must also trust their coding ability, their deployment ability, their... this gets very messy, very quickly. The security footprint for implementing these protocols is immense. Secondly, this approach focuses on one specific use case: websites. The vast majority of publicly-networked applications will, at some point, have a need to perform identity, sharing, or content management. However, they may not necessarily have anything to do with text: for example, a distributed sensor network might communicate only using binary messages, but that doesn't make it any less social. Since bytes are the more basic unit, any general-purpose social protocol should therefore support them natively. A much more robust approach is to address the "social protocol" at a much lower level: to provide only the bare minimum that any social application will need, giving transport-layer bytestreams cryptographically-enforced privacy with many-to-many capability. Only then can you escape requiring everyone to operate their own web service, which is, I firmly believe, an unrealistic goal. [1] https://github.com/Muterra/doc-muse [2] https://raw.githubusercontent.com/tent/tent.io/master/source... [3] https://github.com/bartekrutkowski/hubzilla/blob/master/exam... [4] https://wiki.diasporafoundation.org/Federation_protocol_over...

ate, as if the perceived triviality of, say, instagramming food pics might also imply that there is any less of a violation of our personal agency. That, for me, is why "private-by-default" is and always has been so vital: without it, you're incapable of exercising any meaningful control over the digital world around you. I'm always sad to see this framing left out, because I think it's a very important perspective to have. The second, and likely more appropriate point (given that this is HN), is that this isn't just economics and geopolitics. It is a technical failure that allowed third parties to have any control over it in the first place. HTTP doesn't even protect security, much less privacy. HTTPS is a step forward, but if you think it's sufficient in protecting privacy, I would offer Facebook as a counterexample. Protection of data in transit is an insufficient condition for privacy, and therefore an insufficient condition for agency. It's perfectly possible to create a protocol to address this, to afford not just security but agency, and I am absolutely positive that there are people out there working on this (I know, because I'm one of them: https://github.com/Muterra/doc-muse). But the hard part is overcoming the inertia we already have, and on that front, we are indeed back to economics and politics.