116 releases

Uses old Rust 2015

0.37.1 Dec 1, 2020
0.37.0 Aug 28, 2018
0.36.0 Apr 5, 2018
0.35.0 Dec 27, 2017
0.2.8 Jul 8, 2015
Download history 52/week @ 2023-06-03 10/week @ 2023-06-10 214/week @ 2023-06-17 61/week @ 2023-06-24 281/week @ 2023-07-01 145/week @ 2023-07-08 51/week @ 2023-07-15 72/week @ 2023-07-22 44/week @ 2023-07-29 58/week @ 2023-08-05 69/week @ 2023-08-12 148/week @ 2023-08-19 137/week @ 2023-08-26 52/week @ 2023-09-02 300/week @ 2023-09-09 56/week @ 2023-09-16

553 downloads per month
Used in 9 crates (8 directly)

GPL-3.0 license

18K SLoC

This crate has been renamed to sn_routing https://crates.io/crates/sn_routing


Client and node implementations for a resilient decentralised network.

The network is based on the kademlia_routing_table and uses the XOR metric to define the "distance" between two XorNames. XorNames are used as addresses of nodes, clients as well as data.

Messages are exchanged between authorities, where an Authority can be an individual client or node, or a collection of nodes called a "section", or a subset of a section called a "group". In all cases, messages are cryptographically signed by the sender, and in the case of sections and groups, it is verified that a sufficient number of members agree on the message: only if that quorum is reached, the message is delivered. In addition, each message has a unique ID, and is delivered only once.

Section and group authorities are also addressed using a single XorName. The members are the nodes that are closest to that name. Sections contain a minimum number of nodes with the minimum value specified as a network-wide constant. Groups are of fixed size, defined as the above minimum section size. Since nodes are assigned their name by the network, this provides redundancy and resilience: a node has no control over which section or group authority it will be a member of, and without a majority in the section or group it cannot forge a message from there.

The library also provides different types for the messages' data.


A decentralised service based on the routing library uses Client to send requests to the network of nodes and receive responses.

Node is used to handle and send requests within that network, and to implement its functionality, e.g. storing and retrieving data, validating permissions, managing metadata, etc.

Client creation

A client's name is a hash of its public keys. Upon creation, the client will attempt to connect to the network through any node, and exchange public keys with it. That node becomes a bootstrap node for the client, and messages to and from the client will be routed over it.

use std::sync::mpsc;
use routing::{Client, Event, FullId};

let (sender, receiver) = mpsc::channel::<Event>();
let full_id = FullId::new(); // Generate new keys.
let client = Client::new(sender, Some(full_id), None).unwrap();

Messages can be sent using the methods of client, and received as Events from the receiver.

Node creation

Creating a node looks even simpler:

use routing::Node;

let node = Node::builder().create().unwrap();

Upon creation, the node will first connect to the network as a client. Once it has client status, it requests a new name from the network, and then integrates itself in the network with that new name, adding close nodes to its routing table.

Messages can be sent using the methods of node, and received as Events from the receiver. The node can act as an individual node or as part of a section or group authority. Sending a message as a section or group authority only has an effect if sufficiently many other nodes in that authority send the same message.

Sequence diagrams


~350K SLoC