@Dominic

This is too much for now.

Ok, that's a clear statement and I can work with that. Here is a list of facets of an hsdt rollout, packed into individually implementable chunks. We should be able to pick any subset of these and bundle it into a single rollout. I do not include any semi-canonical stuff, because that can be added at any point, independent from our choices here (and I'll be happy to contribute to the design).

• introduce a new hash suffix for messages encoded in canonical minimum viable hsdt (note: not the final spec!)
• optionally remove byte strings from hsdt, if supporting them is too much work in the data base
• optionally remove Infinity, -Infinity, NaN and/or -0 from hsdt, if supporting them is too much work in the data base
• extend the logical data model of mvhsdt with any subset of the following data types (some of these might imply database changes)
  • various fixed-size integers
  • specialized type for cypherlinks
  • sets
  • maps with arbitrary object keys (requires ssb-client to represent them as Maps, not objects, this is a breaking change)
• specify a fixed order of metadata for hsdt messages, encode them efficiently (this includes a binary encoding of cypherlinks in metadata)
• drop the hash metadata
• drop the timestamp metadata
• drop the author and sequence number metadata
• prefix each message content with a string that specifies the type (thus it can be encrypted, yet does not need to be encoded as an ordinary map entry)

If we can deploy an improved protocol, we can deploy another one.

I'll take you by the word.