Closed TheDiscordian closed 3 years ago
CC @fusetim, who helped me navigate the specs :).
@vyzo: Would you mind taking a look?
I think this should be left up to the application validator.
On Fri, Jul 2, 2021, 17:44 Max Inden @.***> wrote:
@vyzo https://github.com/vyzo: Would you mind taking a look?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/issues/346#issuecomment-873051764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAI4ST5VIY4IEUZMQLP6I3TVXGEDANCNFSM47VUQGLQ .
With @vyzo's reply above and given that the issue has stalled I will close here.
@TheDiscordian please comment in case you think we should continue the discussion.
I'm proposing a timestamp field be added to the Message object, and used to expire messages after a TTL. Similar to how messages are forgotten in gossipsub after
seen_ttl
. I discovered this while working on a new chat project: http://portal.thedisco.zone/testing/chat_experiments/I noticed repeated messages, which led me to file https://github.com/ipfs/js-ipfs/issues/3724. What happens is nodes are innocently rebroadcasting messages after losing connection, but this makes it appear as if new messages are being received, and they are processed as such. This to me though seems like it might not always be in an innocent scenario, couldn't a malicious node harvest messages I post in a public room on Disco Chat, and later replay them, impersonating me? It's one example, but I see how someone building an application could miss this, and the solution seems to me, to embed a timestamp into the message. I think it makes more sense for the protocol to do that, as it seems to be an inherit problem that'd need solving if someone is to rely on
from
.Specifically I'd be proposing a structure like this:
As a start. Then I see at least 2 options:
seen_ttl
, but instead maybestale_ttl
, and after the TTL, the message is considered stale, and rejected. Much like the signature verification options, this could come with options to be disabled entirely if wanted (omittingtimestamp
from transmission).I couldn't find any write-ups about this, and to me, it seems without some sort of expiry, it's difficult to just rely on the authenticity of a message (has it been reused?). What do you think?