Agreed, and I think the critical inflection point will be the development of an open, decentralized hosting+sharing+identity protocol.
Why all three? Well, I can't imagine an open hosting protocol without the hosted information being private by default (otherwise the proverbial cat starts outside of the bag, and good luck getting it back in). That implies end-to-end encryption. To do that and still be able to communicate requires a key exchange system -- that's the sharing bit. And to know who you're sharing with requires an identity definition, which has to be stored somewhere. And now we've closed the loop.
There are definitely people working on that problem (I know, because I'm one of them).
> IPFS is a new hypermedia distribution protocol, addressed by content and identities. IPFS enables the creation of completely distributed applications. It aims to make the web faster, safer, and more open.
> The InterPlanetary File System (IPFS) is a peer-to-peer distributed file system that seeks to connect all computing devices with the same system of files. In some ways, IPFS is similar to the Web, but IPFS could be seen as a single BitTorrent swarm, exchanging objects within one Git repository. In other words, IPFS provides a high throughput content-addressed block storage model, with content-addressed hyperlinks. This forms a generalized Merkle DAG, a data structure upon which one can build versioned file systems, blockchains, and even a Permanent Web. IPFS combines a distributed hashtable, an incentivized block exchange, and a self-certifying namespace. IPFS has no single point of failure, and nodes do not need to trust each other.
Perhaps I misunderstand the problem, but can you elaborate what does "an open, decentralized hosting+sharing+identity protocol" enable that a set of https servers does not?
I mean, pretty much anyone can set up a server to securely host data right now, the main limiting factor is lack of desire, not lack of ability.
Only the identity part is not decentralized but any significantly useful identity anyway needs a solid tie back to the pysical world, as enforcing commitments requires a reasonably reliable ability to trace that identity down to a specific person for legal consequences and expelling harmful actors requires that it is hard to create many fresh identities; I am not aware of any successful identity system that does not ultimately piggyback off of some existing, very centralized sources.
Some clarifications: first, I need to be clear that I'm not saying three protocols (one for each), I'm saying a single protocol that does all three. Approaching the problems separately leads you to something quite similar to the mess we're already in. Second, security is a necessary but insufficient condition for privacy -- just look at Facebook. You can access it with https; that doesn't make it private. And third, the problem is one of agency (tangent: good recent article re privacy vs agency https://medium.com/message/mark-zuckerberg-s-personal-news-s...). The root goal of decentralization is divestiture of agency.
Now, for the sake of argument let's say everyone who wants to host something online has a button that automatically deploys an SSL cert and an https server with domain name, etc. Let's say they throw up a blog on that site. How do they create private posts? That's the critical part, and that's where https isn't just unwieldy, but downright inadequate.
The goal of a network is to facilitate connections between agents, not between topological nodes, and https only provides confidentiality between those topological nodes. If you want everyone to be able to host their own stuff on their own servers, and still retain the ability to have a private post, you need a defined way to share things between those agents. And you could, in theory, write a decentralized protocol for that kind of sharing mechanism, but that requires a sense of who you're sharing things with -- an identity protocol. So you need all three.
Now as you mentioned, identity validation is a very complicated, highly variable problem. Facebook has much lower physical verification requirements than your bank does. There can never be a perfect guarantee that this digital entity is the same as the person you have in your head, in much the same way that you can never truly guarantee that the person sitting next to you at a bar isn't, in fact, impersonating your best friend. You just mitigate that risk as much as possible, which is best done with a protocol that allows people to implement as strict (or nonexistent! can't rule out anonymity) a verification as they need.
And yeah, you could definitely write some protocols that, along with https, accomplishes the above. Arguably that's exactly what Facebook has done (in a closed, sleazy, really not private way). But even if you wrote an open copy of facebook, it's impractical for every single user, or even a large percentage of them, to have their own servers (this, I think, is the fundamental failing of Diaspora). So now you're describing, almost exactly, email over https -- and it still doesn't stop gmail from reading your messages.
Sorry if that's a little meandering, it's been a very long month and I'm exhausted right now, but I wanted to give you at least some kind of response. Does that help clear things up?
That effectively implement storage+sharing+identity? Not that I'm aware of, which is why I'm working on one (https://github.com/Muterra/doc-muse). Plenty of things try and tackle one or two of those but I've never seen anything address all three. I would really, really like to know if one exists so I can pick it apart and learn from it.
A big part of the difficulty is that you truly can't be everything for everyone, but you really need to be something for anyone. If you approach it as a distributed social networking problem (which is most of what I've seen) then you're really missing the indescribably large forest for one specific tree.
The blackbox I've focused on for this protocol is (arbitrary insecure physical bytestream in) -> [box] -> (arbitrary private, authenticated, integrity-verified bytestream out). We use networks to communicate between persons/services/things, not between IP addresses -- the right place to address the problem is between network and application.
Can you give some examples? I'm not aware of any protocols that fit the storage+identity+sharing triad I mentioned above (except the one I'm working on).
Why all three? Well, I can't imagine an open hosting protocol without the hosted information being private by default (otherwise the proverbial cat starts outside of the bag, and good luck getting it back in). That implies end-to-end encryption. To do that and still be able to communicate requires a key exchange system -- that's the sharing bit. And to know who you're sharing with requires an identity definition, which has to be stored somewhere. And now we've closed the loop.
There are definitely people working on that problem (I know, because I'm one of them).