Safe snapchat with one-time use data

Apps like snapchat shows us that there is a great demand for data that gets deleted once it is consumed. But the problem with deletable data on Safe is that it means an owner needs to be attached to it which could compromise anonymity. Also for deduplication to work, data simply can’t have an owner. But here’s a thought. What if we had single use data? The moment you request it, it gets deleted. It’s one-time use only.

Text message, emails, video message, they could all work with this. It would be the responsibility of the recipient to archive it if he wants to, if not, it’s gone. Of course if the connection is lost during transfer the data is lost forever so maybe it’s not a good idea to use that for important communication but for everything else, especially for what apps like snapchat is used for, it’s good.

Farmers are happy because the data doesn’t clog their hd for no reason. This is also the kind of data that will actually be requested compare to data that is simply archived on Safe which makes it valuable to store. Since it isn’t stored forever it could be cheaper to put which in turn makes Safe more accessible and appeal to more people.

There is a risk of collision if someone uploads the exact same data but this could be mostly sidestepped at the app level simply by adding a single random number to the data. Worst case if a collision occurs the request is rejected by the network. Again the data should be encrypted for the recipient to read so it shouldn’t be a problem.

To avoid trolls who request random data(assuming they somehow find out the data exist, troll data manager maybe?) just to delete it for fun, maybe the recipient needs to sign(somehow, crypto stuff…) its request so the network can know they are the legitimate recipient.

Anyway, maybe the messaging api already handles all that but I haven’t seen much news about it lately.

Thoughts?

2 Likes

Perhaps we can have a mechanism that will use an API to create a slave account for this exact circumstance.

I feel like there would be a variety of methods that would be able to satisfy this situation. From incorporating some kind of virtual emulation that would spawn an instance or being able to use built in APIs to create onetime accounts (I don’t believe this functionality exists yet but if dirvine is reading this I bet you it will).

In the case of email or messaging perhaps you could have a switch to set whether you want to use single use data or regular data. Some of us like to archive by default but other times it’s just preferable to have it auto delete. (Instant messages compared to say email. Sometimes it’s handy to have a log of your IMs but most of the time not so much.) Ultimately I don’t think this should be hardcoded into anything but rather a user preference so the user could opt for either persistence or using less puts or something.

1 Like

like @Blindsite2k mentioned, you may want to keep an app like this in the messaging protocol. If it isnt technically saved to SAFE, the storage and deduplication will not kick in…i think…lol…you may want to check this thread as well…

3 Likes

https://github.com/brian-js/rfcs/blob/1e4b830fd3eeac8b4a0e0f62243ebc166e545a8e/proposed/0021-MPID-Messaging-delete/0021-MPID-Messaging-delete.md

1 Like

Interesting, it does seems to cover the case. Also I found this comment in another RFC:

With the messaging feature now having been implemented on the Vault and Client side

So I guess it’s coming soon too. Thanks for the link.

Throw-away messaging would eventually enable a compute layer.