Forgettablility, how?

since @tiago's thread is already so long %Z28HK1s... starting a new thread focused on how things like this could be implemented. I'll also mention where each one is for me in terms of priorities, but of course if you feel strongly you could implement them.

group encryption

This doesn't make it forgettable, but it does mean pubs won't be able to read the message, and so they won't expose it to GOOG. This is 100% on my personal roadmap.

message forget

Sometimes we wish we could forget something, but it's not that easy. If you think about it as "forget" instead of delete you get a better idea of the difficulties.

Basically, you need a way to tell everyone, forget this please, and then they do not pass it on - but at the same time, we don't want other people to forget things for us.

One idea, is to have a delete_key per message... when this is revealed, the message can be validated the message without having the body.

currently signatures are made just by sign(msg) but if you made it sign(hash(msg_body)|hash_delete_key = hash(delete_key)), and normally provided msg = {msg_body, hash(delete_key), sig}, which is verified like verify(sig, hash(msg_body)|hash_delete_key)

since we hash delete_key no one else actually known it! but if we published it with msg_hash=hash(msg_body), you could also verify the forgotten message like verify(sig, msg_hash, hash(delete_key)).

note: I write hash(value) when you know value and calculate the hash your self, and hash_value for when someone else gives you it, and you just use it.

This would work to a degree, but wouldn't prevent an "undelete". I guess it gives a community delete?

Anyway, this would require changing the log verify function, which is very deep in the machine. We wanna go there for group feeds though anyway.

So status of this is a "hopefully one day"

deniable private messages

This is a message that is explicitly denyable when you write it. I read about spys having code one time pads printed on special paper that would burn smokelessly.
Basically the idea is to use ephemeral diffie-helman to derive the key, then all parties forget the secret keys.
the difficulty here is that you need to send them something before hand, although I kinda like that, it's like I send you the smokeless paper to write your destructable message on, that means I have to solicit you to send me deniable messages.
I think this is a good thing because if you can send me unsolicit denyable messages that could be a vector for abuse.

I know @keks feels strongly about this one.

side protocol

This is another one I am excited about. Leave ssb permanent and build a side protocol that uses ssb identities but has no signatures etc. Maybe it's like meatspace chat, maybe it's VR, maybe it's just a IRC. Anyway, it can be heavily encrypted etc, but doesn't need an identity system because it uses ssb's. This would be mainly enabled by the relay-p2p branch of the TechTree

@cblgh whether it's in #boats would also be inside the encrypted portion! otherwise you are leaking a lot of metadata.

@ezdiy I like your "obesity" design! You could also use it with post-quantum crypto since that generally tends to be quite obese already.

The main reason I like the side protocol approach is that there are also many useful effects of permanence and it's very hard to balance the needs of forgettablity and permanence in one protocol.