User Tools

Site Tools


Rhizome manifest

Every Rhizome bundle consists of a single manifest and an optional payload. The manifest carries meta-data about the bundle:

  • Essential (“core”) information needed for bundle integrity (anti forgery and tampering), transport (de-duplication) and prioritisation (Rhizome rank):
  • Optional information to assist prioritisation and delivery:
  • Information used to associate the bundle to applications:
    • service
    • content type
  • Other optional, application-specific meta-data:
    • file name
    • creation date
    • format (eg, character encoding, image dimensions)

The last two categories of meta-data could be encrypted without affecting Rhizome transport and storage, since they are only needed on the recipient's device, and so will be encrypted in future.

Manifest format

The Rhizome manifest consists of 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 US-ASCII character encoding and may be upgraded to Unicode UTF-8 when needed
  • The Rhizome binary manifest is not yet implemented
  • Here are some sample (historical) implementations of the text manifest from Serval Mesh release 0.90 "Shiny":
  • An example of a text manifest:
  • 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.

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

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 Auto Upgrade has a chance to upgrade all the Rhizome software in the field
content/tech/rhizome_manifest.txt · Last modified: 27/09/2015 19:40 by Andrew Bettison