ephemeral messages

[cblgh]

ephemeral messages are messages whose content is only available for a poster-defined time interval. implementing this correctly entails encrypting the contents somehow.

they can be used for sending sensitive information (transmitting files or sharing email addresses) or for scheduling when to grab some pineapple pizza later that same day (i.e. time-limited information)

an approach similar to substack's private channel's proposal (#34) could be taken.

an ephemeral message is posted containing an arbitrary payload (text, file, emote; basically any other message type) and a future timestamp that details the message lifespan. the lifespan is regarded as depleted if a client's local time exceeds the ephemeral message's lifespan. the message payload is symmetrically encrypted and the symmetric key is transmitted to peers in some fashion:

1. an asymmetrically encrypted message, containing the ephemeral message's symmetric key, is sent to each possible recipient at the time of posting. after the expiration time the message is no longer rendered, and ideally the symmetric key is disposed of in some fashion, or
2. the symmetric key is transmitted directly, i.e. outside of the log, to peers which are online at the time of posting. peers in want of the symmetric key send a want request somehow. if there is another peer online with the symmetric key and the lifespan of the message has not been depleted, the symmetric key is sent to the requester.

once we have sparse log capabilities in cabal this could potentially be used to in combination with the ephemeral message payload. (i still think it is valuable to signify that there has been an ephemeral message; it might also be valuable to also allow for the option to erase all trace.)

[cblgh]

based on the unnamed dat hackathon in berlin, it's entirely doable to do today with extension messages :~

just register an extension for this on cabal-core's replicate()-stream

[hackergrrl]

We could also implement this feature by just having the future timestamp you mention, and each client would use feed#cleer on the message when that time passes. This would require sparse mode support.

^ The way I'm picturing this feature wouldn't use any encryption scheme, it would just be a local deletion policy that clients follow.