Nostr Web Client

yes

#YESTR

but they won't work unless receiver is online and subscribed to the relay ofc.

by default most relays respect that 20000-29999 are not to be stored. probably would want to vet this somehow. like, a certification service that you give it a relay address and ask it "does this respect ephemeral events" and it would send and then from another IP be subscribing and then another IP querying for it after it should be gone.

Gzuuus 5mo ago

Yes, I meant that I wasn't imagining them as replacements. Regular gift wraps have their use cases, and ephemeral ones have different use cases, such as real-time secure ephemeral chat.

Regarding relay implementations, I think relays have incentives to respect the ephemeral range since it saves them storage. I've noticed that strfry typically takes 5-10 minutes to evict ephemeral events, while khatru, for example, simply relays them without storing them. This behavior is hardcoded and cannot be modified, which is not good.

How are you handling ephemerals in Orly?

Reply to this note

Please Login to reply.

Discussion

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

ephemerals are not stored.

i don't see why you would want to store them, it contradicts the specification.

orly also actually deletes everything when it gets replaced or is deleted, and it refuses to re-save events that have a delete reference to them (delete by e tag, not a tag).

not implementing actual delete and actual replace clutters up the relay implementation with a lot of unnecessary shit. just delete it bellcurve.jpg

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

also, yeah, not storing ephemerals, IMO, is one of the whole points of nostr

- post office protocol (message database with optional auth requirement)

- publish-subscribe protocol (when new events are published interested parties can instantly get them)

- rendezvous protocol (ephemeral events make nostr able to implement rendezvous, which is critical to all privacy applications)

Gzuuus 5mo ago

That's good. I think the rationale behind the grace period for hanging ephemeral events is to improve robustness against dropping ws connections. However, it is not mandatory, and I've only seen strfry implementing it. I've also put together a circular buffer storage to handle ephemeral events and allow them to be req for a short period of time

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

yeah, i guess that can work but i think that would impact realtime services that depend on ephemeral rendezvous routing.

better would be to bulid in this "please repeat" message into your subprotocol if you ask me. this is an example of a case where you harm one use case by handling another.