Here's another potential extension I did not mention here yet: Maps with arbitrary keys, not just strings. A nice thing about them is that we could emulate sets with them, by using null as the entries. Sets are great, because you can quickly test whether something is in them. In ssb messages, we only have that capacity for strings, by doing objects with null values. But arbitrary-key objects generalize sets, and could thus replace them. And of course, they are useful on their own.

Cbor maps already support arbitrary keys, so this would not change the encoding at all. But then the js api could not use objects any more, but would have to use Maps. That would be a breaking change to the ssb-client js module. Would that be acceptable? I personally think that the protocol design should not be restricted because some implementation would need to change it's api.