Nostr Web Client

if it's ephemeral, it should not be cached. at all. if there is nobody to receive it, it goes to /dev/null

use a regular, replaceable or parameterized replaceable if you want it to be cached. put an expiration on it, or update it frequently, as in replaceable.

don't mix up the use cases by making the middle man do cache duty when there is a cache method existing already in the protocol. if your application is using ephemerals but you expect to need this, you should consider switching the events to replaceable or addressable events, and putting expiration timestamp tags on them. otherwise what happens when your realtime collab app gets confused when it drops the subscription and then gets 10 seconds of past events loaded into it.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

again, you see, the problem is that there is this illusion about privacy that is in conflict with reliability, at the base of this engineering decision, to break the guarantees of an aspect of a protocol.

you want to use ephemerals because you don't trust the relay

but you need the events to be persistent for a short time so clients can catch up

see the contradiction there? either trust the relay, or go p2p. if you go p2p you see that it's no different to the ephemeral event over the relay, and when you think about it, the whole internet is an ephemeral event transport.

Reply to this note

Please Login to reply.

Discussion

Gzuuus 5mo ago

Yes, I understand. To be honest, there haven't been any problems with strfry having a 5 minute TTL for ephemeral events. strfry is the major relay implementation running on Nostr, accounting for around 27% according to nostr.watch, where the major relays that everyone uses implement it. There have been numerous experiments with ephemeral events for real-time stuff, and I've never heard of anyone having any issues with the temporary retention of ephemeral events. Definitely, for sync communication, it doesn't make sense to keep ephemeral events for any length of time. However, the rationale here I think is to improve the reliability of flaky ws connections. It's not like your use case will suffer from busy relays keeping a TTL for ephemeral events since filters remove all the noise from busy relays. In any case, I'm totally fine with no TTL at all; it wasn't the discussion, to be honest.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

i doubt it would cause problems for most of the current uses of it but i for one wouldn't mind if NWC performed better.