Create GIF of message disappearing when deleted

[elimisteve]

That is, when someone else in the chat deletes it

[jimmcgaw]

Doesn't this presuppose a mechanism for deleting chat messages in the first place (which, AFAIK, doesn't exist)?

[elimisteve]

@jimmcgaw There's no deletion mechanism through the UI right now, that's true, but there's the generic CrypTag way to delete any kind of data, and that's by doing the programmatic equivalent of

$ cryptag deleteany id:07e406b9-dc20-4a8a-5189-f8c427257492

[elimisteve]

And there could be a setInterval() {...} call running within Backchannel that does the equivalent of

$ cryptag deleteany type:chatmessage parentrow:$id_tag_of_chatroom from:$myUsername

[elimisteve]

@jimmcgaw The origins of this issue: right now in Backchannel, if we were to run a command like

$ cryptag deleteany id:07e406b9-dc20-4a8a-5189-f8c427257492

where id:07e406b9-dc20-4a8a-5189-f8c427257492 is the ID tag for some chat message, the Backchannel UI will refresh as new messages are pulled, and because the cryptag deleteany ... command deleted a message, that message will disappear from the Backchannel UI.

So capturing a GIF of that would be cool, except it should be triggered by Backchannel automatically deleting a "self-destructing" message after 30 seconds (or whatever the user specified the time to be) rather than as a result of someone deleting the message via the command line.

[elimisteve]

@jimmcgaw So to respond to #19 (comment) , the ability to delete messages is useful, and it'd also be cool to add "self-destructing" messages (triggered from within a setInterval or whatever), but I say we don't worry about some place-holder showing that a message used to be there, unless you'd like to add that :-).

There's nothing built into CrypTag for sort of remembering that something was deleted, and while in some cases I think it'd be cool to create a Row tagged with type:rowdeleter that also specifies the ID of the thing to be deleted (which tells clients to delete said Row locally and/or in the folder/server/Backend), in this case (Backchannel), truly having no trace that a message was written in the first place would be best from a privacy standpoint.