The Serval Project Wiki

User Tools

Site Tools

You are here: The Serval Project Wiki » content » Technology Roadmap » Rhizome
Trace:
content:tech:rhizome

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Last revision Both sides next revision
content:tech:rhizome [14/05/2013 23:18]
127.0.0.1 external edit 		content:tech:rhizome [14/12/2015 08:22]
Paul Gardner-Stephen [Technical documentation]
Line 1: Line 1:
 ====== Rhizome ====== ====== Rhizome ======
  
-**Rhizome** is a resilient file distribution system developed by [[:|The Serval Project]].  It forms the basis of all non-[[http://en.wikipedia.org/wiki/Connection_oriented|connection-oriented]] services provided by [[:content:servalmesh:|Serval Mesh]], such as [[meshms|text messaging]], file sharing, voice mail, and automatic software upgrades. +**Rhizome** is a resilient content distribution system developed by [[:|The Serval Project]].  It forms the basis of all non-[[http://en.wikipedia.org/wiki/Connection_oriented|connection-oriented]] services provided by [[:content:servalmesh:|Serval Mesh]], such as [[meshms|text messaging]], file sharing, voice mail, and automatic software upgrades. 
  
 +==== Technical documentation====
 +
 +Authoritative documentation of Rhizome now exists in the source code of the Serval Mesh software, and should be used in preference to the older documents on this wiki.
 +
 +  * Rhizome REST API [[https://github.com/servalproject/serval-dna/blob/development/doc/Servald-REST-API.md]] 
 +
 +===== Older Documentation
 +
 +See note above, as there exists important updates to much of this documentation, and which is documented directly in the source code repositories.
 +
 +  * [[Rhizome API]] describes the APIs for applications that use Rhizome
 +  * [[Security Framework]] describes the cryptographic features of Rhizome
 +  * [[:content:activity:naf4]] describes the original development of the Rhizome HTTP REST API (beware: some details will be out of date)
  
 ==== Purpose and features ==== ==== Purpose and features ====
Line 41: Line 54:
 ==== Rhizome's data model ==== ==== Rhizome's data model ====
  
-Every Rhizome **payload** ("file") is accompanied by some structured meta data called a **manifest**: +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 [[SID]], [[Rhizome journal]] head, [[Rhizome bounding circle]], [[Rhizome lifetime]]+
  
-A Rhizome **bundle** = **manifest** + **payload** +A payload plus a [[Rhizome manifest|manifest]] together form a **[[Rhizome bundle]]**.
- +
-== Rhizome manifest == +
- +
-The Rhizome manifest is a set of key-value pairs called **fields**,  A manifest is stored and transmitted in either text or binary representation: +
- +
-  * The **text manifest** is the original implementation +
-  * The original text format used [[http://en.wikipedia.org/wiki/ASCII|US-ASCII]] character encoding and may be upgraded to [[http://en.wikipedia.org/wiki/UTF-8|Unicode UTF-8]] when needed +
-  * The **[[Rhizome binary manifest]]** is not yet implemented +
-  * Here are some sample (historical) implementations of the text manifest from [[:content:servalmesh:releases:version_0_90|Serval Mesh release 0.90 "Shiny"]]: +
-    * [[https://github.com/servalproject/serval-dna/blob/batphone-release-0.90/rhizome_bundle.c#L87|rhizome_bundle.c]] in the [[:content:servaldna:|Serval DNA]] source code +
-    * [[https://github.com/servalproject/batphone/blob/0.90/src/org/servalproject/rhizome/RhizomeManifest.java|RhizomeManifest.java]] from the [[:content:servalmesh:development|Batphone]] source code +
-  * An example of a text manifest:<code> +
-recipient=FFA9248AF3848D3FD3FCCCF339C3AF9D574A3D6C9BA2FB3F6C587FB25C479F64 +
-sender=49259519777EF680E20C6ED05FA4B51EB86DDDC7D175A3B15B7AF2F9E446B54E +
-service=MeshMS1 +
-date=1351559461139 +
-id=E6856342C6F2DAFE560C18FE85EC1CCDAB5457D50BFDAE7FCF271D5B9C0E4123 +
-BK=8CEA7C075CD15F1CC8AA1D0F5E263ACD4ECEE6A870A87D90BBD68A4968B8939C +
-crypt=0 +
-filesize=39 +
-filehash=254CDA75BF5E8CA6B5498FE20C33F120BA50464B7BC7B09FD6C41D10722F1B0844137E55F073FCDC7A4388EA48DD282B2C5A6D42931C84E9E076A2BFA8A21BC0 +
-version=1351559461142 +
-</code> +
-  * Every manifest contains one or more cryptographic signatures to prevent tampering +
-    * Rhizome nodes will reject manifests with no signature or a signature that does not verify +
-    * Only the original creator (author) of the manifest may possess the signing key, so is the only party able to modify the manifest (publish newer Bundle Versions with the same Bundle ID) +
- +
-== Backward and forward compatibility == +
- +
-Both Rhizome manifest representations (text and binary) are designed to allow upgrades. +
- +
-[[http://en.wikipedia.org/wiki/Forward_compatibility|Forward compatibility]] arises from an extensible manifest data format that allows unrecognised fields to be skipped: +
-  * The text manifest uses a special field delimiter (newline) that cannot appear in any field value +
-  * The [[Rhizome binary manifest]] stores the length of every field +
-  * Every Rhizome node uses only the manifest fields it recognises and successfully parses, and ignores any it does not (possibly logging a warning) +
-  * Every Rhizome node always stores and transmits the manifest intact, without modification, including any unrecognised fields +
- +
-[[http://en.wikipedia.org/wiki/Backward_compatible|Backward compatibility]] is done using a standard replace/deprecate/delete process: +
-  * The format and meaning of existing fields is never changed +
-  * 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 [[automatic upgrade]] has a chance to upgrade all the Rhizome software in the field +
- +
-== Sender and recipient == +
- +
-  * If a bundle does not indicate the [[SID]] of its intended recipient, it is for general consumption (broadcast) +
-  * If a bundle does not indicate the [[SID]] of its sender, then it is of unknown origin (anonymous)+
  
 ==== Rhizome's data transport ==== ==== Rhizome's data transport ====
Line 138: Line 100:
   * 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's manifest 
-  * 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's crytpo system is that: 
-  * 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's [[SID]] public key 
-  * Rhizome can optionally **encrypt** a payload during injection with a two-way session cipher constructed using the sender's and recipient's [[SID]] public keys 
-  * Rhizome will **decrypt** an encrypted payload during extraction if the node possesses the recipient's [[SID]] secret key 
-  * The Payload Hash of an encrypted payload is the SHA512 hash of the encrypted form, not the clear text form 
-  
 ==== User intervention ==== ==== User intervention ====
  
content/tech/rhizome.txt · Last modified: 21/02/2016 22:52 by Andrew Bettison

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution 4.0 International
CC Attribution 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki