@christianbundy good point that the message length cannot be increased. So adding "deleted": true at the flumelog layer would not work. "content": {} would not be valid in a feed according to ssb-feed because it needs a string type of length ≥ 3, ≤ 52 - but if it was box-encrypted it could in fact be shorter, e.g. "0.box", which would not leave room to replace with an object with a type property. How about use that, or even a shorter string, like "content": "X" to mark a deleted message? Client code should treat it as a private message because the content is a string, and fail to decrypt just as if it was encrypted to some other recipients. Or, I think it would be okay to borrow bytes from the signature if need be. Zero'ing the author field (or any of the other metadata fields) I think would be fine; we will see if it breaks anything.

Another situation would be deleting messages from ssb-ooo. ssb-ooo also uses a flumelog to store messages, but it does not validate them, except by hash. So I think it would be possible ssb-ooo could store a message value that is just {} - although I don't think this would happen now unless there was a broken or malicious implementation. I think it could be fixed in ssb-ooo by at just making it ensure that e.g. a message has a content property, which is not equal to the value used to mark deletion, but is at least as long as it in bytes.

That's odd about those stream errors. It reminds me, when replicating feeds, ssb-server should probably abort sending a feed if it encounters a deleted message in the feed - since the peer will not be able to validate it or any of the subsequent messages and will therefore discard them. This could be done for legacy gossip by hooking the createHistoryStream function, like how it is done for blocks in ssb-friends (formerly in scuttlebot/plugins/block.js) ("break off this feed if they suddenly block the recipient"). For ssb-ebt, I think hooking sbot.getAtSequence would be the way to do it. I don't think getting invalid messages would cause a peer to break the stream though, so those errors might be from something else. Maybe it could be local errors in replication causing the stream to be aborted locally. Do local RPC methods still work when they would output a deleted message or do they end with an error? like sbot.getAtSequence([feedId, seq]) for a feed id + seqnum of a deleted message, or createHistoryStream({feed: feedId, seq: seq-1, limit: 3}) (to output a deleted message with its previous and next messages)