Yep, sorry for the brevity -- I was on mobile. Right now the only valid message type is a JSON payload with both the content of the message and the signature e

Yep, sorry for the brevity -- I was on mobile. Right now the only valid message type is a JSON payload with both the content of the message and the signature embedded in the object. This has two problems: - The embedded signature is annoying because you have to surgically remove it before validating. - The embedded content is annoying because you can't delete a message without deleting the link from your signature chain. If we build validators that accept different message encodings, then we can end up with different types of feeds. Fixing the above is pretty simple: make both the signature and the content of the message appear adjacent to the the on-chain message. The signature authenticates the message, and the message references the content of the message. If you want to delete the content of the message, you can, and it doesn't require deleting the on-chain reference to its hash. Using different validators would also allow us to validate, say, Git commits, where any commit is valid as long as it contains a valid signature by the key we expect. Or maybe we validate Dat (hypercore) messages so that they're first-class citizens -- making SSB more of a meta-network for content signed with a trusted signature. My hunch is that interface developers will probably converge on a single Good Enough feed type for the application. My guess is that social network interfaces like Patchwork/Oasis will use something like GabbyGrove (CBOR + adjacent signatures and content), but that applications like Git-SSB will probably just use signed Git commits. Hard to say!