Silktorrent Specification Version 1.1

General Overview

Silktorrent graph consists of vertices that are Silktorrent servers and sets of directed edges that are one-way tunnels between the 2 vertices. The number of directed edges per pair of vertices can be greater than 2. Edges that start and end at the same vertex do not exist in the Silktorrent graph. It is not specified, what the set of tunnels between any 2 vertices must consist of, but the existence of the tunnels is probabilistic. That is to say, any tunnel can cease to exist or re-appear at any moment and if all tunnels between the 2 vertices cease to exist, then the 2 vertices loose direct connection.

Addressing

Background

Given the lessons learned from the TRON encoding and the American branch of character encoding formats, ASCII to Unicode, the Silktorrent is designed so that from addressing point of view the Silktorrent can cover the whole Universe. That entails infinitely large address space, which in turn entails infinitely large addresses, which can be avoided by using relative addressing. That way the huge computers of aliens can still communicate with the "tiny" computers of 2015 human race.

The Silktorrent graph nodes in the relative address space can originate from different, disconnected, regions of the infinite address space.

The Addressing Specification

There exist 2 levels of addressing:

• addresses of Silktorrent graph nodes within the Silktorrent graph;
• addresses of tunnel entry and exits at the addressing space of the tunnel;

If some data-carrying creature walks in the tunnel, then the tunnel can be a whole world in its own right and has a lot of addressable objects, for example, houses, doors of the houses, but one of those addressable objects, a door, is an entry to a tunnel and another one, another door, is an exit from the tunnel. As the tunnel is a world in its own right, the the world can be shared with other tunnels that form other directed edges in the Silktorrent graph. That means that the data-carrying creature can get lost and accidentally use a wrong door for exiting the tunnel and end up at a wrong Silktorrent graph vertex. Different data-carrying creatures might even cooperate and exchange tasks at that world, but some of the creatures might be killed off by censorship enforcing creatures or just die there for other reasons, leaving the data undelivered.

Partial list of worlds that can be used for forming the tunnels:

• ordinary http;
• Tor network;
• GNUnet
• mail-pigeon-drones that use automated battery exchangers at battery exchange stations;
• public transportation vehicles that have some data exchange equipment mounted on them;
• commuter cars/bicycles/backpacks with some data exchange equipment;
• manual exchange of USB-sticks by people, who travel;
• HAM radio based data exchange;

As the throughput of those tunnels is very limited, a counter-measure for flooding attacks is to allow tunnel implementations and Silktorrent vertex nodes to choose, what data to relay, where to relay it and what kind of data packages to receive.

The communication protocol of the Silktorrent also has 2 levels:

• Silktorrent graph communication protocol (hereafter:SGCP)
• Tunnel specific communication protocol that implements the SGCP through an adapter design pattern.

Silktorrent Graph Communication Protocol (SGCP)

The protocol is LightMSGP_v2 with additional requirements.

The V0 has been designed, but the set of requirements still needs to be written down here. The current idea is that there is a set of fixed sized packages that are used for encoding arbitrarily sized files. To make it harder for censors to choose, what traffic to delete, the packages use temporary ID-s for recipients and senders. The proper math behind that needs to be worked out, specially the query part, where the Silk-torrent-network-as-a-database returns a very small set of temporary ID-s with Silktorrent network specific addresses and the temporary ID-s as numbers have wide distribution among numbers between 0..IDmax, yet enough collisions between different queries to make it "hard enough" to track the owner of the query by studying a series of queries. However, even a naive implementation will probably get pretty far here, specially compared with the current situation, where no implementations of any kind exist and given the fact that traffic anonymity is guaranteed by inherent mix-net at USB-drop-copy sites and special software like the Tor and GNUnet.

Some rough notes in Estonian to help to recall the details:
Siia tuleb siis see jutt fikseeritud pakettide suurustest, kus server deklareerib suurusega ja aksepteeritava jaotusega ja muude parameetritega oma vastuvõtunõuded, toetatud räsialgoritmid, jne. pikk lugu koos turva-teemaga, a la sõprade signeeritud paketid võetakse kindlalt vastu, pakkettide saatjate ja vastuvõtjate anonüümsuse tagamise teema (mitu ID-d, muutuvad saatjate ID-d, jne.)