Initial Message Payload Specification

[oskarth]

This should give an overview of our message payload and contents. What's special about this one is that it doesn't really provide any security guarantees (or at least not many).

Things like upgradability are a concern here, as well as how to deal with new types (e..g what is a sticker in a CLI client?).

One of thinking of these is more like different clients, so TTT and Sticker market and Extensions would be their own specification. For now we can keep them listed in this initial spec, especially MUST ones like text/plain.

Also considerations re Transit, e.g. if we want to move to a different format like Protobuf. How would compatibility work.

Also considerations re what happens if someone puts a bad timestamp or clock.

See x9.md for current draft.

Acceptance criteria

• [ ] Someone can read this and implement a Status client (including links to other specs)
• [ ] They should clarify what security guarantees the protocol(s) provide and don't provide
• [ ] As well as what each protocol/layer requires and provides
• [ ] They should be described as orthogonal pieces, so if someone wants a different transport that should ideally require minimal tweaks to the protocols

In terms of who will judge, it'll be 2-3 main groups initially:

• [ ] Ourselves in protocol group
• [ ] Client implementers (Core, Embark and Nimbus people i.e. status-js and Stratus)
• [ ] Core dev calls participants

[oskarth]

@adambabik are there any follow up issues we should create to attack later?