self-destructing items

[ThomasWaldmann]

items could self-destruct not only after t_upload + dt (see #67 ), but also after reading or downloading them.

so you could type / paste a message and email the paste url of it to the recipient. if the recipient completely downloaded / rendered the item, the item will self-destruct.

this makes sure that either only the recipient reads the msg or the recipient will notice that someone else read it (because it is not there any more).

note: we usually redirect to item view after upload, reconsider this

[ThomasWaldmann]

fundamental problem: self-destruction would happen after a complete read or download, not before.

but what if a file is only downloaded 99.9%, but the last byte is never downloaded?

the downloader would likely have a quite complete file, but the file would not self-destruct...

seems like a bad idea, closing.

[ThomasWaldmann]

the problem with partial downloads can be solved by not supporting them for small items (like < 1KB).

with that plus a new item type x-bepasty-redirect it can work like this:

creation:

• upload content as usual, create item at uuid1
• create a redirect-to-uuid1 self-destructing item at uuid2, type x-bepasty-redirect-selfdestruct
• give user url to uuid2

visit:

• user visits item at uuid2, which emits a http redirect to uuid1, then item at uuid2 self-destructs
• user can deal with stuff located at uuid2 (as long and as often he wants, unless otherwise defined)
• uuid1 is gone, uuid2 has never been communicated to anybody except the first one looking (which should be the receiver)