Thread by @SarahJamieLewis

Deletion in p2p systems is weird because it violates many of the expectations that people have from centralized solutions.

e.g. If Alice purges all data about Bob as a contact, then the next time Bob attempts to connect to Alice it will be interpreted as a fresh request.

Alice is then left with 2 options: either add Bob as a contact again, or block Bob from all future conversations. Nether is great.

So "deletion" must mean something else to the app e.g. maybe we want to only display a new authentication request if Bob actually sends a message.

But that necessitates a "shadow record" or "placeholder" sitting in the storage engine that Alice might be unaware of if she has expectations other systems.

We can build UX to try and break those expectations, but "deletion" is then fundamentally the wrong word.

So my question for you today is...what are your expectations and how would you like this reality surfaced?

Maintain the illusion of deletion? Subject the user to constant requests? Do you have a better word?

In cwtch we currently have 5 levels of conversation persistence:

1. Full history saved
2. History deleted every session
3. "Archived" = flagged and dropped to bottom of conversation list until a new message
4. Blocked - actively fail auth attempts.
5. Deleted - all data purged

My current problem is that none of those states adequately reflects the the traditional "remove conversation" in a way that matches the expectation of most users.

It would be easy enough to do, but that would leave data around that a user might not expect.

Thanks everyone for your thoughts on this, please keep them coming. A lot of my current work is trying to pick apart exactly what expectations people have and how those apply to decentralized / p2p solutions.

You've already given me more ideas to factor into new designs.

A few stand outs:

1. A few people suggested "remember / forget" as additional terminology which I quite like and I think could be made legible and allow the choice to be surfaced up.

2. The idea of giving Bob a (revocable) token they could preset is technically intriguing.

I also think there is probably a nice symmetry between flows around conversation e.g. :

Archive Conversation (Hide, but save)
Delete Conversation (History)

is like:

Archive Contact (allow new conversations)
Purge Contact (delete everything but allow new requests)

Although in the back of my mind there is a growing fear of "just how many buttons and options does this contact settings pane actually need before it becomes excessive"