Group: GNU Social P2P/Defunct/Routing

THIS IS CURRENTLY OUT OF DATE

Routing in GNU Social

In GNU Social, cores can support arbitrary numbers of transports, and as such, sometimes there will exist two cores who do not have any direct means of communication. Additionally, we assume that some nodes will enter and leave the network. To provide the illusion of a consistent network, we define and utilize the following concepts:

Migration: The transfer and storage of GNU Social objects from one user's datastore (Alice) to another user's datastore (Bob), advertised to the network such that in the event that Alice's node stack is unreachable, other users will be able to query Bob's node stack to gain access to Alice's data.

Indirect Routing: In the event that two peers are unable to directly connect as a result of having no shared transports, they will connect through one or more third parties which have shared transports.

A typical GNU Social Packet

Any given packet has the following levels:

• I'm not sure if this is true anymore.

Teddks 19:39, 22 June 2010 (UTC)

Core outer packet

This header information is encrypted to the core key. It identifies:

• The inner packet's *destination*. This may be another core, or a user on the local core.
• The UI inner packet
• Optionally, other directives or information.

UI inner packet

This contains the following information:

• What user caused this packet to be sent
• The date at which the packet was originally created
• The serialized GNU Social object for synchronization
• Additional optional directives or information

Routing

Bootstrapping

Since GNU Social is a social networking system, it is safe to assume that any GNU Social user will have one or more friends. As such, upon starting a node, a GNU Social user will be able to bootstrap by providing the core with a list of one or more cores to query for node descriptors. If a core is being operated without any user interface guaranteed to be present, the operator of the core can provide a list of cores manually.

Privacy-Enhanced Routing

One of the design goals of P2P GNU Social is full user control of and privacy with respect to the social graph. This presents a routing problem, because we cannot always directly connect to friend nodes, as the set of nodes we directly connect to would correspond with friends who we exchange information with, leaking the social graph.

To mitigate this risk, P2P GNU Social will utilize the Tor protocol and software for onion-routing, with a few changes.

Initial Version

To ease implementation, the early version of GNU Social will not modify the mainline Tor program, and will use the Tor network for routing. Each core will control a Tor Onion Proxy that will serve a Tor Hidden Service. Cores may publish their hidden service descriptors to the main Tor directory servers, or they may only share them with friends. Reliance on the Tor directory servers for hidden service descriptor lookups should be minimal; eventually, decentralized peering ala SKS should be implemented to eliminate the need for centralized directory servers.

In this version of the network, all communication between cores happens over a Tor hidden service link, and the addresses of cores are .onion URIs.

Later Versions

Eventually, we will transition to a different model, wherein each core runs an Onion Router, with a descriptor that is not (by default) published to the main Tor directories, but shared via the SKS protocol with friend nodes. Rather than make hidden service connections, cores will build circuits through the GNU Social network (and optionally the mainline Tor network), using Exit Enclaving to create end-to-end encrypted transport links.

Mirroring and Caching

To ensure data our data remains reachable even when our node is down, we implement a system of mirroring or caching of friend data. This is achieved by using BitTorrent as the transport layer of anything that needs to be mirrored.

The initial push of metadata to friend cores will include an infohash that cores or UIs can load into a BitTorrent client to download the full data. After they finish, they should seed to at least 1.0, or until another ratio in the event that they have a defined relationship with the original source of the data. The originating core and possibly other cores will serve as trackers, and clients will communicate with trackers over Tor. This allows data to remain reachable even when the original core is down, and for large amounts of data to be transferred without incurring large costs on one party.