Consider not restricting message deletions to be soft deletes

[AreebaAziz]

Currently the specifications require that deleted messages (and edited messages) are not actually removed from the chat, but marked as deleted and it is up to the client UI to display the message as deleted.

There can be several cases where end-users may not wish their messages to be soft deletes. For example: accidentally sending sensitive information in the chat (eg. yubikey accidental presses), sending an embarrassing message. With the current specs the participants of the chat can still read the original messages.

There is the issue that we only want users to append to the chat file for security reasons. If they can only append they cannot rewrite original messages.

I have a potential concept that may solve the issue? If interested you can view it here (with diagrams and a demo): https://github.com/AreebaAziz/event-based-chat/tree/solid-demo

Essentially:

• end-users send an HTTP PATCH request to the server for new event (such as a new message, delete a message)
• the server either
  • appends the event to the event_log (soft delete)
  • enqueues the event in a FIFO queue (hard delete)
• another component which could be within the Pod Provider listens for changes in either the event_log file or the FIFO queue depending on the type of channel. On a new event, it updates a generated_chat file with the updated chat.
• clients listen for changes to the generated_chat file only

I have a working conceptual demo in the Github repo if you are interested, otherwise we can just discuss the soft vs hard delete.

[csarven]

As I understand it:

• chat participants can only Read and Append statements to the chat instance, and so;
• allowing participants to remove statements will be outside of the design scope of Solid Chat.

For chat participants to be able to delete statements from the shared chat instance (using PATCH requests with insert directive) will require participants to have Write access. Something like that would potentially allow anyone to delete any statement.

For chat participants to delete only their own messages, then messages would need to be separate resources so that access controls can be set independently - this is irrespective to messages being stored in one or multiple storages. It is technically feasible but not sure if that's the direction that Solid Chat should go.

For enviornments or scenarios where messages are ultimately immutable by chat participants, Solid Chat should work as advertised.

---

Alternative designs: using ActivityStream Vocab/Core (possibly with ActivityPub, and optionally server-server communication for federation) or possibly with Web Annotation, both using Linked Data Notifications for delivery and discovery of (chat) activities (e.g., threaded in-line replies but can work on resource-level too: c in-reply-to b in-reply-to a)

[AreebaAziz]

allowing participants to remove statements will be outside of the design scope of Solid Chat.

The design I proposed didn't have participants removing statements, it was more a trusted entity that would either save the full immutable chat log (soft delete) or not (hard delete). Participants would still only have append access to a chat event log; they would append a "delete" message and the trusted entity would rewrite the visible chat for participants.

But if solid chat is a client-client specification then we can't use a trusted entity to mediate.