This is an old revision of the document!
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:
recipient=FFA9248AF3848D3FD3FCCCF339C3AF9D574A3D6C9BA2FB3F6C587FB25C479F64 sender=49259519777EF680E20C6ED05FA4B51EB86DDDC7D175A3B15B7AF2F9E446B54E service=MeshMS1 date=1351559461139 id=E6856342C6F2DAFE560C18FE85EC1CCDAB5457D50BFDAE7FCF271D5B9C0E4123 BK=8CEA7C075CD15F1CC8AA1D0F5E263ACD4ECEE6A870A87D90BBD68A4968B8939C crypt=0 filesize=39 filehash=254CDA75BF5E8CA6B5498FE20C33F120BA50464B7BC7B09FD6C41D10722F1B0844137E55F073FCDC7A4388EA48DD282B2C5A6D42931C84E9E076A2BFA8A21BC0 version=1351559461142
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:
Backward compatibility is done using a standard replace/deprecate/delete process: