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.
Discussion
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.
Your posts are too long. I'd like to reply to one argument at a time ...
>From: Giszmo47 at 07/29/22 10:45:40 on wss://nostr-relay.wlvs.space
>---------------
>Your posts are too long. I'd like to reply to one argument at a time ...
agreed! just because damus optimizes for twitter workflows doesn't mean other clients need to do the same for kind1
>From: unclebobmartin at 07/29/22 11:16:57 on wss://nostr-pub.wellorder.net
>---------------
>
long messages for the win. I love the idea of nostr as a viable replacement for RSS feeds. one can imagine kind 1 messages with markdown formatted articles, with the kind 0 message pointing to formatting, a message kind for enclosures to support podcasts, etc. but it doesn't need to be shoe-horned into the RSS mold, that's just the closest functioning analog, and an obvious crossover point. @fiatjaf has rsslayer in this space, which does RSS->nostr. I've roughed in some code that does nostr->RSS. but in the long run, I'd much rather receive new reading content/notifications and podcast updates via nostr.
You never trust relays. That's why you connect to multiple. DB insert is more costly than DB query, especially for replaceable events. Relays will certainly not give you an incentive to spam them with those. Deleting in-demand events after a day would create such an incentive.
>From: Giszmo47 at 07/29/22 10:49:23 on wss://wlvs.space
>---------------
>You never trust relays.
True.
>That's why you connect to multiple.
True.
>DB insert is more costly than DB query, especially for replaceable events.
That depends entirely upon your DB. more-speech, for example, keeps everything in RAM and simply writes to flat-files upon shutdown. Inserts don't cost much at all. Indeed, the concept of "insert" doesn't really exist. (sigh) Databases are just so 1990s.
>Relays will certainly not give you an incentive to spam them with those.
I've recieved no objections so far. Indeed, what are the relays doing other than saving and fowarding events. kind:0 is an event like any other. There's nothing special about it from the relay's point of view.
>Deleting in-demand events after a day would create such an incentive.
I don't understand that statement. What is an "in-demand" event?
By the way, this particular message is one of the reasons that I like long messages.
I'll stick to short form as Astral has a limit but also find long form hard to follow. If you are interested in only one aspect of the discussion, it's easier if it splits up.
Relays use DBs and kind-0 is special in that it is replaceable. Relays are supposed to only share the last received, so they have to filter out or delete older ones.
>From: Giszmo47 at 07/29/22 12:19:07 on wss://nostr-relay.wlvs.space
>---------------
>Relays use DBs and kind-0 is special in that it is replaceable. Relays are supposed to only share the last received, so they have to filter out or delete older ones.
NIP-01 is not quite that demanding. It says: "A relay may delete past set_metadata events once it gets a new one for the same pubkey." I had previously missed the fact that a relay MIGHT only send the latest metadata.
Honestly, I think that's a mistake. Deleting history is a dangerous precedent IMHO. I wonder what #[6] thinks about that?
In NostrPostr I copied what I found in another relay implementation: Set older entries to "hidden". As I find the evolving follows graph highly interesting, I do not intend to delete that data any soon. There is also people offering historic data that I missed.
>From: unclebobmartin at 07/29/22 18:44:08 on wss://wlvs.space
>---------------
>>From: Giszmo47 at 07/29/22 12:19:07 on wss://nostr-relay.wlvs.space
>>---------------
>>Relays use DBs and kind-0 is special in that it is replaceable. Relays are supposed to only share the last received, so they have to filter out or delete older ones.
>
>NIP-01 is not quite that demanding. It says: "A relay may delete past set_metadata events once it gets a new one for the same pubkey." I had previously missed the fact that a relay MIGHT only send the latest metadata.
>
>Honestly, I think that's a mistake. Deleting history is a dangerous precedent IMHO. I wonder what #[7] thinks about that?
And now I'll use the correct pubkey for #[8]. At least I think it's the correct one. There are five profiles out there that claim to be fiatjaf.
querying kind3 helps with this a bit
This bothers me on two fronts.
1. As I stated before I don't like the idea that relays can delete old data -- it's a kind of temporal censorship.
2. I don't like the idea that relays are a kind of personal database that allow users to squirrel away their private data. There are plenty of other options for that.
>From: jb55 at 07/30/22 09:43:19 on wss://nostr-relay.wlvs.space
>---------------
>querying kind3 helps with this a bit
>
>
>
>
I find it's useful for building a web of trust, and seeing followers for discoverability. but yeah it's optional I guess... can't imagine using a twitter-like client without it though.
I definitely want the web of trust. So perhaps you can descibe how kind-3 serves that purpose. The way I look at it, it's no better than a file containing pubkeys and petnames that I keep on my laptop.
>From: jb55 at 07/30/22 09:54:31 on wss://relay.nostr.info
>---------------
>I find it's useful for building a web of trust, and seeing followers for discoverability. but yeah it's optional I guess... can't imagine using a twitter-like client without it though.
metadata and follows (kind 0 and 3) are not only private data. Both are vitally important to build a social network.
I understand why kind:0 is vital to a social network (although there are challenges such as the five fiatjafs).
I do not understand why kind:3 is vital. As far as I can see kind:3 is equivalent to a file on my laptop. Unless, of course, I can query your kind:3. If the latter is the case, then #[8]'s web of trust starts to make sense.
>From: Giszmo at 07/30/22 19:42:04 on wss://nostr-pub.wellorder.net
>---------------
>metadata and follows (kind 0 and 3) are not only private data. Both are vitally important to build a social network.
Of course you can query kinds:[3] of other authors:[32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245].
That gives me something new to think about. Thanks!
>From: Giszmo at 07/30/22 20:10:28 on wss://relay.nostr.info
>---------------
>Of course you can query kinds:[3] of other authors:[32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245].
The client db is never the expensive part. Relays will handle the data of millions of clients. They will eventually not be for free.
>From: Giszmo47 at 07/29/22 12:19:51 on wss://relay.nostr.info
>---------------
>The client db is never the expensive part. Relays will handle the data of millions of clients. They will eventually not be for free.
Perhaps. A wise man once advised me that, when it comes to software, focus first on the here and now; tomorrows problems will come soon enough. In any case it seems to me that appending metadata events is no more expensive than appending any other kind of event; and that UPDATING metadata is the more expensive of the options.
The current situation is that you can spam relays and download a full DB dump trice a minute without penalty. Lets hope it does not stay like that for long.
nips for events consider kind-0 replaceable, so relays will only give you one per pubkey.
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.
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.
What does privacy have to do with this??
You currently query
```
[REQ,,{since:x,pubkeys:[follows()]}]
```
Other clients do
```
[REQ,,{kinds:[1,4],since:x,pubkeys:[follows()]},{kinds:[0,3],pubkeys:[follows()]}]
```
It's only about getting what you need.
>From: Giszmo47 at 07/29/22 10:57:22 on wss://wlvs.space
>---------------
>What does privacy have to do with this??
>
>You currently query
>
>```
>[REQ,,{since:x,pubkeys:[follows()]}]
Actually, I just send this: ["REQ","more-speech",{"since":1659052700}] (taken from a recent invocation).
>```
>
>Other clients do
>
>```
>[REQ,,{kinds:[1,4],since:x,pubkeys:[follows()]},{kinds:[0,3],pubkeys:[follows()]}]
>```
>
>It's only about getting what you need.
I need it all.
Yet you worry **others** might miss your metadata if you stopped constantly spamming it out? Try it out. No client apart from yours ignores what happened before the user first started it.
>From: Giszmo47 at 07/29/22 12:22:11 on wss://relay.nostr.info
>---------------
>Yet you worry **others** might miss your metadata if you stopped constantly spamming it out? Try it out. No client apart from yours ignores what happened before the user first started it.
I think you make a good point. I should change more-speech to send metatadata at a configuration dependent frequency which includes "only once", and "not at all". I should also, at minimum, have more-speech do a query for all the kind:0 events the very first time it starts up. Or, perhaps at a configuration dependent frequency (like every-friday).
The most disruptive property of more-speech is that it disregards what's on relays and just blindly overwrites it with its own idea of how the metadata should look. That removes Damus' screen_name and Branle/Astral/... nip05.
That's a fair criticism. I'll modify more-speech to allow the user to add profile fields as part of the configuration. I'll also sllow the user to specify a frequency of metadata transmission, and a frequency of kind:0 queries from relays.
I remain convinced of the following points.
1. The user must have absolute control over their profile; and therefore that profile must be specified by the user on a client by client basis. e.g. each client should be configured with the profile the user desires to transmit.
2. nostr is a censorship free protocol. Ephemeral or replaceable events are a form of censorship. i.e. They censor the past. As such I have a philosophical problem with relays that delete old kind:0 and/or support other replaceable events.
The lastest version of more-speech (202207301434) has a user configurable option to schedule the sending of kind:0 metadata profiles every N days, or :never. You can set this in private/user-configuration. See the wiki page (https://github.com/unclebob/more-speech/wiki/user_configuration)
1. If you reject interoperability, use some different kind and not kind-0, the one other clients use kindly, without nuking each other's config.
When the client uses an ephemeral event and the relay deletes it, then that is not censorship. The point of ephemeral events is to not be delivered from storage.
When clients edit their metadata and relays delete prior versions, then that is not censorship. This is the point of having it editable or "replaceable". Use a different kind. But even then, relays may delete your events at any time or reject them. Not censorship neither.
You learn a lot by doing a query for all kind:0 events. Lots of identity issues. There are two or three Giszmos, several fiatjafs etc. In more-speech I disambiguate them with random numbers. As it happens, when I run more-speech, you show up as Giszmo47.
BTW, @Gizmo47, I appreciate the dialog. I think you can tell that I enjoy a good debate, and will sometimes take a strong position for the sake of the argument. I've found it a good way to learn. This dialog has been very informative so far. Moreover, it is one of the first real tests of a dialog like this, on nostr, that I have participated in.
And it probably looks nicer on more-speech than on Branle/Astral. 
)
hmm this sounds cool, I need to try more-speech...
;-)
It's pretty bare bones at the moment. There's a huge to-do list (which I know you understand :-)
You can download the executable jar at https://www.dropbox.com/s/8r23ufbcyho5jwx/more-speech-0.1.0-SNAPSHOT-standalone.jar?dl=0
You can execute with java -jar more-speech-0.1.0-SNAPSHOT-standalone.jar
I should start up and give you a new id and user name, which you can change later.
You can download the source from github.com/unclebob/more-speech, and read though the wiki for basic operating instructions.
Organizing stuff in tabs doesn't preclude you from querying kind 0 and 3 without limit for accounts of interest.
>From: Giszmo47 at 07/29/22 10:59:39 on wss://nostr-relay.wlvs.space
>---------------
>Organizing stuff in tabs doesn't preclude you from querying kind 0 and 3 without limit for accounts of interest.
True enough, but separately querying kind 0 and 3 doesn't help me much either. In more-speech I keep my own list of profiles. Once I see a metadata event, I record that profile and never forget it. So I never need to explicitly ask for kind 0.
Having said that, I can see an advantage to allowing the user to asks for all the kind:0 from the beginning of time to gather up all the users that the relays know. I may have to implement that at some point.
As for kind:3, I really don't know what to do with that. I mean, why do I want to have some relay hold my contacts and pet names for me. I keep all that in flat files on my machine. Yes, I suppose it would be convenient to pull that down into a new client but I'm so far away from needing that kind of ability that it's not real high on my priority list.
People change their metadata and querying all kind-0 of all users you know costs the client 1s and maybe 100ms CPU time.