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):
  • Bundle Identity (BID)
  • bundle version
  • payload size
  • payload hash (only if size is not zero)
  • tail (only for a Rhizome journal)
  • signature
• Optional information to assist prioritisation and delivery:
  • sender SID
  • recipient SID
  • expiry (Rhizome Use-By)
  • Rhizome bounding circle
• 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.

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":
  • rhizome_bundle.c in the Serval DNA source code
  • RhizomeManifest.java from the Batphone source code
• 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 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)

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