self destructing messages #51
Replies: 3 comments 13 replies
-
|
Thanks a lot for the feedback! Really great to hear you got it up and running without any major hurdles :) The self-destructing messages is a great idea, but it is really hard to implement from a cryptographic standpoint, at least in a way where we can guarantee that messages are actually deleted within their specified time-frame, since once someone has the message, you can't really "coerce" them to delete it. Even if we add a message time out to all LXMF clients that currently exist, anyone can just implement their own client that ignores the self-destruct time. But maybe it would still be valuable to add support for this in a standardised way, so clients that want to support it can. It would be pretty simple to implement, and we just need to agree on an LXMF field to use for a "deletion timestamp" value. I think there'd be value in this from an ease-of-use perspective, even though there is no way to cryptographically guarantee that the deletion occurs. |
Beta Was this translation helpful? Give feedback.
-
|
was thinking more along the lines of implemented in the "user client" eg Nomadnet or Sideband. Pretty much to cover the compromised device scenario..eg iphone/laptop siezed at an airport and they force you to unlock it. at least with a "timeout" set locally eg:24hrs.. received messages could just be wiped after a set time. So not dependent on sender and probably not needed in the LXMF protocol as such? |
Beta Was this translation helpful? Give feedback.
-
|
Briar faces this same problem and it currently implements self-destructing messages as messages that are only wiped locally, and no notification is sent to the other party. A message is simply displayed locally that all messages in this conversation are now set to self-destruct. Eventually the Briar protocols may support "requests for deletion" where a client can politely ask a peer to delete a message, but as we noted, this could be trivially defeated by peers making backups or ignoring the request. |
Beta Was this translation helpful? Give feedback.
-
|
Right, I get you. This is definitely worth looking at, and it seems like an area that needs to be considered carefully to provide the right benefits to the users, without needlessly complicating matters them. If anyone knows about good/bad examples of how this has previously been done right and wrong, it would be really useful to gather them here. |
Beta Was this translation helpful? Give feedback.
-
|
I think the Signal App is the best implementation on the end user app side. Only other suggestion is if store and forwarding happening for messages then maybe that is where the self destruct from the sender comes in... i.e. if recipient not online.. and expiry time exceeded, then sender (or intermediaries) doesn't forward on the message. Thus end recipient would not receive an expired mesg when they come back online. Hope that makes sense.. :) |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense. Since there is already a default expiry value for messages in LXMF, this could be made configurable on a per message basis quite easily. I think that is probably the right way to go, although no guarantees can be made as to what PNs will actually honor the setting. |
Beta Was this translation helpful? Give feedback.
-
|
The obvious solution du jour would involve smart contracts to make sure people comply with rules. But something like this might be a better idea: https://github.com/pfrazee/vitra All you really want to know is whether the other party has behaved or not. So you want some proof that they executed the "op_code" or if they did not. Almost like a ZK-Proof. You don't need to force compliance for 99% of cases, but rather just know whether someone "betrayed" you (to use dramatic language) and then you can act appropriately as needed. |
Beta Was this translation helpful? Give feedback.
-
|
That is very interesting, I see that now, after actually reading a bit more about it, which I had not done when I wrote the comment ;) If they have indeed found a "pure" solution to the problem, it is completely remarkable, but I think it looks more like some sort of distribution of trust between multiple parties (which is, in a way, kind of a mini-blockchain). I need to read their whitepaper though, since I don't yet understand what they are actually doing. Incredibly interesting stuff though! |
Beta Was this translation helpful? Give feedback.
-
|
Vitra doesn’t ensure that a node cant be bad, it just tells you when they are bad. At least that’s how I understand it |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it is still a very useful concept! I have to go through their docs to see exactly how they are doing it. There must still be some kind of consensus establishment. Wonder how they do that without some sort of blockchain. |
Beta Was this translation helpful? Give feedback.
-
|
hey @pfrazee, how do you ensure that nodes report on their good (or bad behavior), without blockchain? there are “watch tower” nodes? |
Beta Was this translation helpful? Give feedback.
-
|
Vitra produces a signed log of operations and the resulting state which can be fetched and then replayed. The checks are 1) that the op log and resulting state are correct for the given smart contract, and 2) that the log hasn't been rewritten since a past sync. Watch towers aren't baked into it. Vitra will emit a fraud proof, but it's up to you to establish who acts as a watchtower and what they do with a fraud proof. |
Beta Was this translation helpful? Give feedback.
-
|
Can the encryption be turned off for us ham radio people ? Or am I missing
something?
Steve
On Mon, May 2, 2022 at 4:10 PM timp34 ***@***.***> wrote:
Just started out with Nomadnet over a couple of Lora modules.. must say
this was soooooo much easier than Meshtastic and android phones etc.. to
get link up and running and usable with Nomadnet - well done on this it and
looking forward to expanding my testing as have about 8 lora radios looking
to spread out and test with Nomadnet/Reticulum.
A feature request/suggestion is "self destructing" or "disappearing"
messages within Nomadnet. similar to timeout in Signal App.
Maybe even just an option to "delete" messages past certain duration - eg:
7 days.
Keep up the great work!
—
Reply to this email directly, view it on GitHub
<#51>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APRMG4TRAVHPO6T4Y5FKEF3VIBOF7ANCNFSM5U5LG34Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Pardon the brevity, sent from a mobile device. So there.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Steve |
Beta Was this translation helpful? Give feedback.
-
Just started out with Nomadnet over a couple of Lora modules.. must say this was soooooo much easier than Meshtastic and android phones etc.. to get link up and running and usable with Nomadnet - well done on this it and looking forward to expanding my testing as have about 8 lora radios looking to spread out and test with Nomadnet/Reticulum.
A feature request/suggestion is "self destructing" or "disappearing" messages within Nomadnet. similar to timeout in Signal App.
Maybe even just an option to "delete" messages past certain duration - eg: 7 days.
Keep up the great work!
Beta Was this translation helpful? Give feedback.
All reactions