secushare Protocol

secushare Protocol

Protocol Layers

secushare employs PSYC on top of GNUnet's cryptographic routing. The job is complex enough to require its own stack of protocols. Here's an illustration comparing the old to the new protocol stack:

This stack comparison is discussed in detail in How the Internet is Broken. Here we focus on the new architecture only:

GNUnet & PSYC Stack

This is the list of layer implementations that together produce an Internet stack for distributed private social networking:

Applicationscommunication, exchange, social tools
Talergeneric taxable anonymous micropayment system
PSYC socialTBD: higher-level PSYC functions: redundant fail-safe channel masters, picking candidates for agnostic relaying, merging of several channel states into profiles, calendar, dashboard, private distributed social graph etc
PSYC pubsub(aka gnunet-social) scalable social modeling (PSYC entity layer)
GNSGNU Name System
Onion RoutingTBD: authority-free metadata protection
MulticastTBD: cloud-like distributed scalability layer
GNUnet psyclower-level PSYC routing layer
psycstorelower-level PSYC message history storage plus entity-level distributed state access (which implies channel memberships)
GNUnet CADETsybil-attack-resistant packet routing layer, end-to-end encrypted circuits with ratcheting
R²N DHTdistributed hashtable
COREpoint-to-point encrypted tunnels
Physical, HTTPS, TCP/IPdedicated cabling, ad-hoc wi-fi or existing broken Internet

The stack up to GNUnet social is described in tg's masters thesis "Design of a Social Messaging System Using Stateful Multicast" although the described APIs have evolved a bit since then.

Careful readers will notice that it assumes a single node to act as its own channel master, making the channel go down as the node goes down. This is okay if places (chatrooms, forums etc) are actually comprised of multiple channels of which some may be up and some may be down. Another possible solution is to allow for redundant masters in a byzantine architecture, or simply stepping in when the currently active one becomes unavailable. In other words, there are several ways to address this aspect.

The planning for the multicast and onion routing layers are in advanced stages, we don't expect any showstoppers coming from that direction, either. And luckily those parts aren't necessary to deliver a working prototype, they merely serve to improve scalability and anonymity.

Payload Syntax

XML and derivate formats such as RDF and XHTML are very extensible and very powerful semantically. The 'Semantic Web' even combines rich data with immediately viewable mark-up. All of this flexibility comes at the price of verbosity and costly processing. This is why many developers flee to JSON, a format which is seen as being simple and straightforward. Actually, it isn't that simple either, especially if you still need a certain degree of extensibility and backwards compatibility into the future.

The PSYC protocol syntax is more straightforward than JSON. It can do without specific rendering libraries and is several times faster in processing than either XML and JSON as benchmarks have shown. Still by means of concepts like method and variable inheritance it is painlessly extensible and future compatible. Additionally it can carry binary data naturally, which is a great plus when it comes to doing end-to-end cryptography and media rich social networking.

So from our perspective we would recommend encoding message payloads in PSYC syntax, but that doesn't mean we can't design a protocol in such a way that it will just as well be able to deliver XML or JSON documents in established protocols such as OStatus.

Protocol Syntax

The protocol itself should be able to carry any kind of payload by providing some nice framing around the content. Let's not repeat the mistakes made with XMPP (= no framing, no easy way to transmit XML because the protocol itself is a kind of XML, and more).

HTTP is an example of a protocol which allows for any content to be delivered. Very successful at that, actually. The downside of it is, it can only carry one binary payload per message, therefore you still need a protocol syntax for multiple binary items, and it has a query/response architecture which is unnatural for messaging. Therefore, several binary routing protocols are a possible choice as they allow for structured binary payloads.

PSYC is text-based to allow for easy generation of content, but designed like a binary protocol for efficiency, so it's a strategic in-between choice.