Silktorrent Specification Version 1.0
Currently this specification lacks implementation.
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.
Given the lessons learned from the
the American branch of character encoding formats, ASCII
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
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;
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
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.)