Introducing MIX Browser

MIX is a content publication platform, therefore a key component is a browser to be able to view any item and to serve as a reference implementation for other software to follow.

I have just implemented an initial version of the MIX Browser. This is what the “address bar” looks like:

Each MIX content item has a 32 byte itemId. This can be pasted into the itemId field. Once “Go” is pressed the browser will retrieve the content:

First of all it determines which Item Store contract is managing the item by passing the itemId to the getItemStore() method in the Item Store Registry contract. The first 8 bytes of the itemId is actually the last 8 bytes of the address of its Item Store contract.

Anyone can register a new Item Store contract, but the user agent must be hard-coded to know how to interact with it. Currently there is only one Item Store contract: Item Store IPFS SHA256. This Item Store stores each revision as an IPFS SHA256 hash.

MIX Browser then calls the itemStoreIpfsSha256.getItem() method to get all the information about the item that is stored in the contract’s state:

• Flags: each item can have the following flags set:
  - Updatable: item revisions can be changed.
  - Enforce revisions: revisions cannot be changed or deleted, only new revisions can be added.
  - Retractable: it is possible to retract the item in its entirety. This is not affected by the updatable or enforce revisions flags.
  - Transferable: the item ownership can be transferred to a willing receiver or set as unowned.
• Owner: the address of the account that owns this item. Only the owner can change the item’s content, owner or flags.
• Revision count: how many revisions this item has.
• Revision IPFS hashes: IPFS hash of each revision.
• Revision timestamps: the creation timestamp of each revision.
• Parent itemIds: when an item is created it can specify any number of parent items. The meaning of a parent is context specific and can be implied or specified in the content itself. Examples of what a parent can mean are: feed the item is published in, item being replied to, or item being retweeted / quoted.
• Child itemIds: any items that have declared this item as a parent are listed here.

Currently MIX Browser only reads the first revision. The 32 byte IPFS hash of the revision is converted into a Base58-encoded Multihash so the content can be retrieved from IPFS.

MIX uses Protocol Buffers to encode the content. Content from the storage layer (IPFS) is decoded using the ItemWrapper message from MIX item schema. Among other things, this message declares which compression algorithm is used to compress the payload. Currently MIX uses DEFLATE, but Brotli will replace it once a suitable JavaScript library is available.

The uncompressed payload is then decoded using the Item message. This produces an array of pairs of mixinIds and mixin content.

Content items can be composed of any number of mixins, but the first mixin is considered to be the content type for the item as a whole.

Example mixins are Video, Title, Description, Tags, Geolocation, Licence, Recording date, Language, Item derived from.

Each mixin type has a MIX content item that includes the Protocol Buffers schema that defines how it is encoded.

Mixin types are registered with the Mixin Registry contract to obtain a permanent integer mixinId.

Currently MIX Browser can only render mixins of type “Mixin”, that is, content that defines how different mixin types are encoded. It decodes the three fields: Name, Description and Protocol Buffers schema, and displays them as shown in the screenshot above.

I appreciate this is a little bit complicated — I am having an infographic produced to make it easier to understand.

UPDATE: the infographic is now produced: