Of the communication modes discussed in the previous post, "perusal" is the one that needs the most love right now. We're talking Twitter territory, so this post is timely. Remember "perusal" refers to communication which is both asynchronous and involves broadcasting to many people.
The wonderful thing about Twitter is that, when you reada something interesting anywhere, you can speak directly to the author about it on Twitter, and they'll respond, as often as not. This feature springs from the famous social media "network effect"; Twitter is where all the authors hang out now, so it's where everyone goes to talk to authors, creating a self-reinforcing cycle. People say that only a paradigm shift can beat an existing network. If new competitors try to compete on features, they'll get squashed by the existing network, which can relatively easily copy those features.
So let's talk about what peer to peer social might look like. That is, a system for perusal-type communication which doesn't depend on any central authority. People agree this is a hard problem. So we'll talk about it in avowedly handwavy manner.
1) It should be http based. Among other advantages, this will help with ramp up and network effects: even before our system takes over the world, its posts will be no worse than blog entries.
2) Its scope should include direct messaging, partly because that'd be nice to have too, but mostly because we can use the relationships between people to bootstrap some kind of trust graph. Much of the social graph is already available in people's phone's Contacts app.
3) It'll have two different roles in the system, which I'll uncreatively refer to as "people" and "servers"b. Both roles have public-private key pairs. People's apps record each others' public keys, so the system is local first that way. I don't need Facebook to manage my electronic contact for my brother. His app signs his posts, so any server can send them to me, and I'll know that they're really from him.c
Even for perusal, I don't really need Facebook fanciness to highly rank posts from my brother, or from my favorite musician. It's now easy to communicate with anybody in the world; the hard part is preventing enough of that communication to keep it useful.
4) So servers differentiate by recommending new posts that people want to read, that is, posts from strangers. Continuing the spirit of search engine and social media companies, there's a tension between what I want to read, and what other people want me to read. "Advertising" is when intermediaries get paid to sacrifice the former for the latter. If people know the public keys of all the people that they're already interested in, and those keys are used to sign all posts, there's no longer any robust way to insert advertising into those posts. The natural place for advertising then becomes the feed of new recommended posts.
5) People's apps should employ multiple servers. People can rate posts, and those ratings will be automatically shared and used to pick the best servers, forming a kind of market place for servers. Depending on how expensive it is to run a server, the market will efficiently price the fraction of the recommendations that will be advertising. Now we're really getting handwavy. Who says this can work? Well, we can talk about it more; first let's finish the sketch. :)
6) We also need to support a way for ratings to flow from readers to publishers. Partly because this is something that publishers like, but it needs to be supported natively so that servers can demonstrate to advertisers how effective they are. It's the trust graph which defeats sybil attacks. Attackers can create as many fake people as they like, and those won't matter because the rest of the world doesn't connect to them.
7) So everybody's rating everything, does that mean that all ratings have to be copied everywhere? Distributed consensus and trust algorithms appear to assume so. And of course, there's blockchain. But I hope we can do better. We don't need any of this to be precise, we just need it to more expensive for spammers to game the system than it would be for them to simply run a competing server. Therefore, we ought to have a protocol that enables participants to exchange ratings in a sparse, just in time fashion. We're talking about a kind of guerilla PageRank. Unfortunately, the term "gossip protocol" is already taken, so once we actually figure out his protocol, we'll need a new catchy term for it.
OK, that's about enough speculation for now. There are some major ideas that'll I'd like to talk about in the future: How do we support decentralized topics or groups? How can multiple independent parties evolve the software and the protocol? And of course, how would all of this effort make a system much better than existing centralized networks?
a When I say "read", I mean "read, listen to, watch, or otherwise experience".↩
b Once I say "server", many readers will immediately think "oh, that's federated, not peer to peer". Well I'm still hoping this'll be a bit more dynamic than your typical federated system like email. We'll see :).↩
c There are a lot of details to get right here, for example post-compromise security ↩
