User names are synonymous with domain names on OpenBook, and that lets us verify peers with traditional SSL certificate chains. The SSL layer in HTTPS verifies the identity of your peer using trusted servers called Certificate Authorities.
If a sub-domain fails SSL domain authentication, the parent domain can be used as a fallback. This way, most social networks will only need one secure key, while more advanced networks can let their users each have their own secure key-pair.
Pages, like on the web, are addressed by paths on their respective servers. If I wanted to get a page from the president, I might request:
OpenBook links are intentionally indistinguishable from HTTPS web links. This allows applications to fall back on browsers to display links which can't be read as OpenBook pages.
Pages are the only unit of content on OpenBook. Pages can be located at any path on a peer, but every peer should at least make one page available at their root path,
Pages contain the following, encoded in JSON, when they are retrieved:
The most critical capability is the ability for a page to link to additional OpenBook content. This is done with normal links so that bi-directional fallbacks can be enabled. When an https link is published, the link is expected to be either a normal https website, an OpenBook page, or both. It is up to the reader to follow and interpret the links as they wish.
Content is formatted in Markdown, which, like OpenBook, is a work in progress. OpenBook will select a specification of Markdown as the appropriate dialect emerges.
An OpenBook POST sets aspects about the relationship of the sender to the receiving page. A POST can set any of the following:
When any of these attributes are included in a post, the values should override the existing state.
An OpenBook post is also used to transmit 'notification', which is a fufillment of a subscription. These are one-time events unlike the other attributes which are settable relationships between the sender of the POST and the recipient page.
To respond to content, make it available to GET on your server (publish it first). If this server is in response to some particular content and/or is forked from a particular page, link to it appropriately from the page.
Next, send the link of the new page to the page you have forked or are responding to. Include the URL of your new page in the appropriate
Feedback is sent in the form of opinions, which is a string that is either 'like','dislike' or 'report'. An empty string represents the lack of an opinion. Opinions can be sent about any link on the page, including traditional links as well as links to OpenBook pages. Embedded content like images cannot be targeted as it is considered part of the page's content. However, the opinion of the whole page can be sent by setting the opinion of the empty string target.
Say I want to some feedback to a page, providing positive feedback about one link and a severe report about another. I would send an ojbect of opinions, with the exact href of the links as the keys and 'like', 'report' as my respective values. I might include an extra 'like' with an empty string as the key, if I wanted to give the whole page positive feedback.
If one peer is interested in a page, she can subscribe, and she will expect that page to notify her when it changes. In order to subscribe, needs to set the 'subscription' attribute in the POST she sends to the page. She sets the subscription attribute to a path on her server.
Now, when that page changes, it should send her a POST with a notification. The notification value that gets sent is equal to the page's path, so our user can identify which page is announcing its update.
Lastly, to enable large social networks to grow, POSTs can be sent in bulk. This allows large social networks to communicate on behalf of their users quite efficiently.