Group:GNU Social P2P/Defunct/Routing

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:

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

Upon startup, a GNU Social core will announce to the network what transports it allows and which users it hosts.

Sending a packet

The packet is first created by the UI, and then sent to the sending user's core to be sent over the network.

The first step in creating a packet is encrypting the *object* to be sent to the user key to which the object is being sent, along with the sender's information, current date, and any other optional directives.

This encrypted payload is wrapped in a core outer packet specifying that the encrypted UI subpacket is destined for the receiving user.

If the sender's core cannot directly communicate with the receiver's core, an intermediate server is picked which can. Another core outer packet is created which contains the receiving user's core server as the destination. This is repeated until there is a path between the sending core and the receiving core.

The final packet, before being sent to the sender user's core, should include an outer packet specifying the next core the packet should be sent to, and a payload, encrypted either to the receiving user, or the next core server.

• Migration

• • Initializing Migration