Deniable messages by default

"I want to be confident that anything I send to someone can't be used against me if their server is hacked."

(This user story is most relevant to #13 and #27, where the user wants something they wrote previously to now be gone, but it applies across the board since even a simple DM has the assumption they're talking to that person, rather than to any third parties who may gain access to the database.)

In practice it's effectively impossible to enforce any assumptions about the remote server at the protocol level. Anyone can implement ActivityPub, anyone will be able to implement something that looks like AP E2EE, including promising to anything connecting to it that it deleted something/does honour disappearing messages, and then just not actually delete what it receives (whether maliciously/deliberately[^1] or accidentally). A shared protocol like this is based on needing to trust the other side has implemented it correctly, and where for most of ActivityPub a failure to correctly implement something just means that the remote won't receive/display a message correctly or some other fail-safe error, a failure to make messages disappear is inherently fail-risky.

I think the best thing we can do is assume that messages aren't removed on the remote, try to avoid presenting them to users as if they invariably will, set things up so that good-citizen software will remove them, and locally ensure that any remote copies left are as deniable as possible. That places this in inherent conflict with #23, unless #23 is restricted to only apply in the instant of receiving something, so that any data at rest is spoofable (the user knows that everything received was created by whoever it's attributed to, since they know they didn't write it themself, but any third parties can't be sure which of the two it was).

Stepping out of the theoretical realm and into practical implementation, with the caveat that I'm definitely not a security expert, I feel like the best way to do this would be something along the lines of a "show your privates"/OTR (§Revealing MAC keys) publishing of the signing key for a message. That doesn't really work for the fediverse as a whole (something sent publicly can be assumed to be valid because so many remotes accepted it) but if E2EE operates on a more intimate level of one-on-one/small-group DMs then it's more viable. Potentially, after a disappearing message timed out and after deletion in general, the local server deletes the local copy and sends the remote(s) a Delete activity (which has the benefit of backwards compatibility for things that don't know about disappearing messages) which contains the key which originally signed the message as a payload? Maybe the local server should also publish the signing key on its end as well, though unless the same key is used for multiple messages with multiple people that risks proving that they had some connection with the remote even if it doesn't prove the exact contents of any message.

[^1]: I'll be honest, one of the projects I have in the planning stages is a datahoarding tool which would be able to plug into AP so users are able to collect images, informational/helpful posts, things that jog their imagination, etc.; disappearing messages (and even Delete activities) are in conflict with its mandate. The best I've been able to work out is a policy of storing that content in a way where it's indistinguishable from something that the local user is just pretending the remote sent out, or a note they jotted down themself.

The issue discusses deniable messages, disappearing messages, ActivityPub Delete activities, and OTR-style revealing MAC keys, but names no repository files, tests, or entry points. Start by resolving the protocol design questions and its conflict with #23; done would require an agreed, implementable approach for deniability and remote deletion.