Willow Sideloading Protocol

Status: Proposal

The WGPS presents a way for two peers with an established connection to efficiently exchange data. But running the necessary infrastructure to establish such connections (e.g. a STUN server, distributed hash table, or relay servers) is a non-trivial task, limiting who can operate them.

The Willow Sideloading Protocol presents a way for peers to transmit data to each other asynchronously and via completely user-improvised channels.

Instead of statefully coordinating which data to exchange, the Sideloading Protocol uses drops, arbitrary sets of Entries and Payloads compiled into a single bytestring. A drop can then be treated as a kind of static store which can be joined with any other store as per the Willow Data Model.

Drops are then shared via the informal ad-hoc infrastructure we refer to as the Sidenet:In contrast with sneakernets which only use physically transported storage devices, the sidenet also includes the internet and other established networks.

Drops will often undoubtedly contain stale data that users are already aware of or no longer need. But what the sideloading protocol gives up in efficiency it more than makes up for in simplicity and flexibility. It is simple to implement, and works with the infrastructure users already have.

Finally, given that this protocol cannot interactively authorise users (e.g. via private area intersection), drops are always fully encrypted.


In order to use the sideloading protocol, one must first specify a full suite of instantiations of the parameters of the core Willow data model. In addition to this, the sideloading protocol requires the following:


Let entries be an arbitrarily selected set of PossiblyAuthorisedEntries from a namespace namespace, transformed into a sequence by ordering according to the following criteria:

This ordering takes maximum advantage of our relative encodings.A PossiblyAuthorisedEntry p1 is prior to an PossiblyAuthorisedEntry p2 if

Let initial_entry be the result of default_entry(default_namespace_id, default_subspace_id, default_payload_digest).

Let contents be the concatenation of

Finally, let drop be the result ofencrypt(contents).


Once created, drop can be transported by whatever means a single bytestring can be transferred, to be decrypted and the recovered contents ingested by its intended recipient.

A Sideloading emblem: A stylised drawing of tufty grass growing in between the cracks of paving stones, next to a graffiti-styled rendition of the word "Sideload".