This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
content:tech:rhizome [06/05/2013 20:27] Andrew Bettison Remove some useless text, add link to [Rhizome Retriever] |
content:tech:rhizome [21/02/2016 22:52] (current) Andrew Bettison Re-word [Technical documentation] section; remove link to GitHub (maintenance burden) |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Rhizome ====== | ====== Rhizome ====== | ||
- | **Rhizome** is a resilient | + | **Rhizome** is a resilient |
+ | ==== Technical documentation==== | ||
+ | |||
+ | **[[Rhizome API]]** contains links to the authoritative [[: | ||
+ | |||
+ | Other relevant information: | ||
+ | |||
+ | * [[Security Framework]] describes the cryptographic features of Rhizome | ||
+ | * [[: | ||
==== Purpose and features ==== | ==== Purpose and features ==== | ||
* Rhizome is a **[[http:// | * Rhizome is a **[[http:// | ||
- | * Rhizome is designed for [[http:// | + | * Rhizome is designed for [[http:// |
* Rhizome guarantees that payloads will remain intact wherever they are transported | * Rhizome guarantees that payloads will remain intact wherever they are transported | ||
* Rhizome makes no guarantees about delivery time or eventual arrival | * Rhizome makes no guarantees about delivery time or eventual arrival | ||
Line 20: | Line 28: | ||
* Users do not use Rhizome directly, but // | * Users do not use Rhizome directly, but // | ||
* Current Rhizome applications: | * Current Rhizome applications: | ||
- | * [[: | + | * [[MeshMS]], the simple text messaging service of the [[: |
* [[: | * [[: | ||
* the [[: | * the [[: | ||
* the file sharing service of the [[: | * the file sharing service of the [[: | ||
- | * [[: | + | * [[Serval SAM]] is a crowd survey app for Android that allows the user to fill in an [[http:// |
- | * [[: | + | * [[Sensor Logger]], an Android app produced by [[:content: |
* Future applications may include: | * Future applications may include: | ||
* voice mail | * voice mail | ||
Line 41: | Line 49: | ||
==== Rhizome' | ==== Rhizome' | ||
- | Every Rhizome | + | Every file distributed by Rhizome ("payload") is accompanied by some structured meta-data called a **[[Rhizome manifest|manifest]]**. |
- | * some meta data is supplied by the originating application to accompany the payload, but is not used by Rhizome, eg, File name, Content MIME type | + | |
- | * some meta data is created and used by Rhizome to identify, prioritise, route and expire the payload, eg, Bundle ID, Bundle Version, Payload size, Payload hash (digest) | + | |
- | * some meta data is supplied by the originating application and is used by Rhizome to prioritise, route and expire the payload, eg, sender and recipient | + | |
- | A Rhizome **bundle** = **manifest** + **payload** | + | A payload |
- | + | ||
- | == Rhizome manifest == | + | |
- | + | ||
- | The Rhizome manifest is a set of key-value pairs called **fields**, | + | |
- | + | ||
- | * The **text manifest** is the original implementation | + | |
- | * The original text format used [[http:// | + | |
- | * The **[[: | + | |
- | * Here are some sample (historical) implementations of the text manifest from [[: | + | |
- | * [[https:// | + | |
- | * [[https:// | + | |
- | * An example of a text manifest:< | + | |
- | recipient=FFA9248AF3848D3FD3FCCCF339C3AF9D574A3D6C9BA2FB3F6C587FB25C479F64 | + | |
- | sender=49259519777EF680E20C6ED05FA4B51EB86DDDC7D175A3B15B7AF2F9E446B54E | + | |
- | service=MeshMS1 | + | |
- | date=1351559461139 | + | |
- | id=E6856342C6F2DAFE560C18FE85EC1CCDAB5457D50BFDAE7FCF271D5B9C0E4123 | + | |
- | BK=8CEA7C075CD15F1CC8AA1D0F5E263ACD4ECEE6A870A87D90BBD68A4968B8939C | + | |
- | crypt=0 | + | |
- | filesize=39 | + | |
- | filehash=254CDA75BF5E8CA6B5498FE20C33F120BA50464B7BC7B09FD6C41D10722F1B0844137E55F073FCDC7A4388EA48DD282B2C5A6D42931C84E9E076A2BFA8A21BC0 | + | |
- | version=1351559461142 | + | |
- | </ | + | |
- | * Every manifest contains one or more cryptographic signatures to prevent tampering | + | |
- | * Rhizome | + | |
- | * Only the original creator (author) of the manifest | + | |
- | + | ||
- | == Backward and forward compatibility == | + | |
- | + | ||
- | Both Rhizome manifest representations (text and binary) are designed to allow upgrades. | + | |
- | + | ||
- | [[http:// | + | |
- | * The text manifest uses a special field delimiter (newline) that cannot appear in any field value | + | |
- | * The [[: | + | |
- | * Every Rhizome node uses only the manifest fields it recognises and successfully parses, and ignores any it does not (possibly logging | + | |
- | | + | |
- | + | ||
- | [[http:// | + | |
- | | + | |
- | * Software upgrades may introduce a new field that can coexist with the older field(s) it supercedes | + | |
- | * For a while, software upgrades create manifests containing the deprecated field and the newer field | + | |
- | * Eventually a software release and all following releases cease to insert the deprecated field | + | |
- | * This provides a time window during which the [[: | + | |
- | + | ||
- | == Sender and recipient == | + | |
- | + | ||
- | * If a bundle | + | |
- | | + | |
==== Rhizome' | ==== Rhizome' | ||
Line 128: | Line 85: | ||
* Rhizome nodes may transfer bundles using **[[http:// | * Rhizome nodes may transfer bundles using **[[http:// | ||
- | * Adjacent Rhizome nodes may transfer bundles over **[[http:// | + | * Adjacent Rhizome nodes may transfer bundles over **[[http:// |
==== Neutrality ==== | ==== Neutrality ==== | ||
Line 138: | Line 95: | ||
* Rhizome does not rank (prioritise) based on the content of payloads | * Rhizome does not rank (prioritise) based on the content of payloads | ||
- | ==== Bundle integrity ==== | ||
- | * Rhizome does not modify any manifest once it is created | ||
- | * Rhizome does not modify any payload | ||
- | * Rhizome creates a random 256-bit Elliptic Curve private key for every bundle, called the **Bundle Secret** or **BS** | ||
- | * The 256-bit public key derived from the Bundle Secret is called the **Bundle ID** or **BID** | ||
- | * Rhizome does not reveal the Bundle Secret to any other application or node | ||
- | * Rhizome computes the 512-bit SHA512 hash of the payload, called the **Payload Hash** or **PH** (also **File Hash** or **FH**) | ||
- | * At injection, Rhizome inserts the Payload Hash into the bundle' | ||
- | * Rhizome signs every complete manifest using the Bundle Secret | ||
- | * Rhizome nodes will only store and transmit manifests with valid signatures | ||
- | * Only an application possessing the original Bundle Secret can alter the manifest or payload | ||
- | |||
- | The net result of Rhizome' | ||
- | * any party may create a new bundle (with a new Bundle ID) | ||
- | * only the originating party may modify the manifest or payload of an existing bundle (keeping the same Bundle ID) | ||
- | * thus, once a bundle is created, all new payloads with the same Bundle ID are guaranteed to be from the same original sender | ||
- | |||
- | ==== Payload security ==== | ||
- | |||
- | * Rhizome can optionally **encrypt** a payload during injection with a one-way asymmetric cipher using the recipient' | ||
- | * Rhizome can optionally **encrypt** a payload during injection with a two-way session cipher constructed using the sender' | ||
- | * Rhizome will **decrypt** an encrypted payload during extraction if the node possesses the recipient' | ||
- | * The Payload Hash of an encrypted payload is the SHA512 hash of the encrypted form, not the clear text form | ||
- | |||
==== User intervention ==== | ==== User intervention ==== | ||
Line 179: | Line 112: | ||
The [[Rhizome Retriever]] was the first prototype of the manifest-payload distribution system. | The [[Rhizome Retriever]] was the first prototype of the manifest-payload distribution system. | ||
+ |