I announced OpenBook today and have intentionally left out a few things out of the design.
In the interest of keeping this network as flexible and reliable as possible, I focused on removing overreaching definition and eliminating unenforceable rules.
This network needs to support users and user systems of all shapes and sizes. A 'user' nowadays can be a person, a group, a company, a bot, a segment of a person's online identity, a project, etc. Even more problematic is the fact that the identity of one "user" is likely to evolve between these things. A peer in this network needs to be a truly generic thing, so that any application can decide how to handle this ever-present problem. The easiest way to do that is to enable peers to be defined in hierarchies, and leave it at that.
Recognize that any top-level peer can follow its own rules, but keep the top level peer in the name so you can always understand the patterns the node follows. For example, if you trust the social network
celebrity.name, you might know that
daniel.craig.celebrity.name is really him, and users will understand that his account behaves according to the rules of
celebrity.name. With namespaces of any depth, very powerful user structures can be built.
Peers will need to navigate trust much like they do in the wild world web today. A top-level provider will need to earn its own trust by gaining popularity and behaving well. By default, all top-level peers will be viewed equally, until some start becoming known as reputable providers with real users and consistent behavior. Names can also loose trust, like when groups of domains start getting recognized as spammers. A hierarchical peer definition is critical for this pattern, because it allows you to block spammers at the highest possible level.
We only need to define how peers communicate between eachother. We should never limit the way the node interfaces with the user. Most application developers will create typical web applciations, but the protocol shouldn't depend on that in case the developer wants to interface with its users over SMS, email, command line, or even BCI.
While the network needs to be flexible, it's core language should not be. Giving mechanisms for companies to create their own content types will quickly lead to a diverse and difficult-to-read plethora of content formats. Guidelines can be written against it, but this is the wild web out here and nobody will be able to enforce it. This system needs to be self-enforceable: there should be no easy way for large companies to poison the network by allowing them to control the format of the data they distribute.
As you can see, aspects which are often large parts of social protocols have been left out of OpenBook entirely. Users are entirely generic and are defined only by the structure of the network. Software on OpenBook can authenticate and interface with users in whatever way it wants to, assuming it even interfaces directly with users. Lastly, the data on OpenBook is not customizable at all. As it turns out, keeping the content simple and human-readable is dramatically better for users.
OpenBook is just that now, completely open and free to read, critique, and improve. What do you think of OpenBook in comparison to other protocols? Do you think these things which I have excluded are essential? Don't hesitate let to me know. This is a team effort, and all of us little guys are on the same side.
I am proud to announce OpenBook, a simple approach at open social networking. I invite you to explore the concept and let me know what you think.
We need to start teaming up to build some great apps for the next generation of web networking. I am going to start writing software for this protocol, starting with this open-source blog, which I will release on Monday. I hope you all join me in ushering in an open era of social networking.