Replying to Avatar unclebobmartin

Why would I trust that a relay would hold kind:0 indefinitely? I don't think that's a requirement. Moreover, relay X may have started long after any kind:0 for user xyz was sent, so it may never have that kind:0 for user xyz.

Is it more private to use a kind filter? I don't see why. If the data is available, it's available.

Is it more efficient to use a kind filter? I suppose, but the traffic of metadata messages on the network doesn't seem particularly burdensome compared to the event traffic.

The more-speech use-case is apparently quite a bit different from some other clients. Some clients treat nostr as a kind of twitter replacement. But more-speech uses nostr more as a news channel; a place for longer articles and prolonged threaded discussions.

As such, more-speech does not use the REQ filters to follow users. Rather more-speech gathers every message on the network, and then allows the user to pick and choose which users and topics they wish to follow by separating them into various tabs on the screen.

So, if I want to see all the 'bestofhn' stuff, I can go to that tab. If I want to see 'RobosatsOrderbo' I can go to that tab. Indeed, I have a tab set up for this particular discussion.

>From: Giszmo47 at 07/29/22 09:58:43 on wss://nostr-relay.wlvs.space

>---------------

>For that you use a kind filter. Get all replaceable events without a "since" and all other content "since" last connection loss - 1day or so. Other clients do it that way and it's certainly more efficient and private.

New relays pull "{}" from other relays to get started. I did and others do. [nostr.info](https://nostr.info) will soon have metrics on which relay delivers which events on that query without limits.

Reply to this note

Please Login to reply.

Discussion

At some point expecting relays to hold, and transmit, all messages since the beginning of time might become unreasonable. In any case, why would we want that? We, users, can simply retransmit our kind:0 profiles periodically. I'll admit that more-speech is a bit aggressive about this; but that would be easy enough to moderate.

>From: Giszmo47 at 07/29/22 10:52:01 on wss://wlvs.space

>---------------

>New relays pull "{}" from other relays to get started. I did and others do. [nostr.info](https://nostr.info) will soon have metrics on which relay delivers which events on that query without limits.

The distinction here is replaceable events vs. non-replaceable ones. Please look into nip-16.

I really dislike HIP-16. Again, changing or failing to record history is probably not a good precedent to set. I'm also unclear as to where the 'supported_nips' field is to be found. Perhaps #[6] can clarify.

>From: Giszmo47 at 07/29/22 12:20:57 on wss://relay.nostr.info

>---------------

>The distinction here is replaceable events vs. non-replaceable ones. Please look into nip-16.

The range 10k-30k is occupied by nip-16. So what? Make your client use other kinds. (How many events with negative kind are out there?) There are data hoarders that store even the ephemeral events. Relays should just not send them out on a "REQ". nip-11 defines a supported_nip.

My PR for nip-23 also defines supported_nips.