Nostr Web Client

Thinking about gift wraps... Currently, NIP-59 defines kind 1059 for gift wrap, which falls within the range of "regular events," which are supposed to be persisted in relays. It would be interesting to introduce an ephemeral alternative kind for gift wrap events, which would complement the current system. This would allow events that aren't intended for storage in relays to benefit from protection against metadata leakage. One option would be to use a new kind number, such as 21059, for ephemeral gift wraps. This approach could provide an extra layer of privacy because these events would never be stored, only relayed. WDYT?

#dev #nostr

Reply to this note

Please Login to reply.

Discussion

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

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?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 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.

il_lost_ 5mo ago

https://www.coolr.chat/ is supposed by ephemeral, try that, you can probably remove the message

Gzuuus 5mo ago

Yes, that's cool(r) xD but messages are in plain text, just tested, so i can just subscribe and read the messages from everyone, which is cool if communication are not meant to be private

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

if the event kind were added to #orly's privileged event kind list it would only serve them up to author and p tagged npubs

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

also it should use "-" protected tag, that would make a proper relay refuse to allow recipients to repost it because only the author can post such events after authing to the pubkey npub

Gzuuus 5mo ago

All of these are local policies, which are fine, but they are not a silver bullet. Privileged or protected events can still be leaked and relayed through relays that do not enforce these policies.

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

you should not be using relays without due care and consideration

they are NOT dumb replicas, no matter what certain people try to say about them. they are very much critical to any mechanism protecting privacy because it's a RELAY protocol. you can only get around this by use of peer to peer protocols, which throws the baby out with the bath water.

so, yeah, there should be more effort aimed at "secret shopper" verifying the implementations of relays are not obviously violating the spec and possibly therefore your privacy.

a check for privilege verification would be very easy to implement.

"does this relay send this DM to subscribers without them being authed/authed to different npub not in the message?"

Gzuuus 5mo ago

I understand your point, but from my perspective, it seems a bit futile to believe that every relay implementation will strictly comply with that *optional* specification. And no one will abuse it

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

and my point is that if you base your design decisions on trustlessness with a relay based protocol you are gonna have a bad time.

i lean heavily towards the idea of finding ways to get more people being the middle man in their conversations. if 10% of nostr users are running a relay that's a lot better than being stuck with the problems of a trustless p2p architeture

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

distil the problem down to see what i'm talking about

why is p2p better? no middleman. why is it worse? it requires concurrent connection

why is relay better? asynchrony and getting around routing problems caused by the limitations of the IPv4 and NAT issue. and the clear and obvious constant obstruction against p2p connections that is deliberately being done to keep these clouds as middlemen in everything. for the benefit of the gigacorps and their spook friends.

relay is the solution that you have to make. rendezvous, specifically, that's why it's pretty much a fixture in every p2p system, and the usual achilles heel. consider tor and the directory servers. IPFS and the need for rendezvous service for nodes that have full inbound routing, for those that don't.

what is that they are adding to the p2p to make it work? a relay doing rendezvous.

NWC protocol hides the messages inside encrypted content anyway, and if you take the same approach for any rendezvous use case you see, the more busy this protocol is, the more silly it would be to keep a back-queue of events and send them when? the client is not going to *expect* to have ephemeral events that are older than like 2 seconds. this is gonna cause broken problems in the clients using relays as rendezvous as well.

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

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.

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.

il_lost_ 5mo ago

you can have channel like https://www.coolr.chat/?relay=wss://relay.damus.io&channel=test

so they are linkable things, but if you need markdown, a new kind is better