>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.
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.
>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.
>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 ...
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.
One of the benefits of more-speech is that I can right click on a message and choose 'add article to tab'. That tab will then contain all messages in the reply thread of the chosen message. This is a great way to follow a particular topic.
Proposing a new nip: [NIP-24: Prevent Data Deletion in Replaceable Events](https://github.com/Giszmo/nips/blob/protectTheUnknown/24.md)
At first I thought it was reasonable that clients should merge the fields within metadata (kind:0) messages. For example, if user XYZ uses a client that supports `display_name`, and transmits that in a metadata message, then any client recieving that metadata message should include the `display_name` in the profile it keeps for user XYZ. If user XYZ switches to a new client that does not support the `display_name` field, and if that client sends out a metadata message, clients receiving that metadata should not erase the `display_name` field from their saved profiles.
But then I tried to imagine why this was useful. What is a client supposed to do with a field that it does not understand? It's not going to retransmit it to anyone else. It's just junk data serving no purpose as far as that client is concerned.
It seems to me that the problem you are trying to solve is a very different one. You have a particular configuration associated with your user identity. You want every client that you use to transmit that configuration whenever it sends out metadata. It seems to me that this is a configuration problem that you, as the user of a client, must solve; and for which the clients you use must provide affordances.
For example, more-speech sends out NIP-01 standard metadata every time it starts up. As I understand it, you are concerned that this "erases" configuration that other clients are depending upon. So more-speech (and presumably other clients) should allow you a few options.
1. Allow you to add fields to the metadata profile that it will reliably send when it transmits metadata messages.
2. Allow you to stop the transmission of metadata messages.
>From: Giszmo47 at 07/28/22 21:08:53 on wss://wlvs.space
>---------------
>Proposing a new nip: [NIP-24: Prevent Data Deletion in Replaceable Events](https://github.com/Giszmo/nips/blob/protectTheUnknown/24.md)
Proposing a new nip: [NIP-23: "Supported Feature" Signaling](https://github.com/Giszmo/nips/blob/featureSignalling/23.md)
At first I thought that advertizing supported NIPS was a good idea, and that even advertizing informally named features could be useful. However, this sentence gave me pause:
"Switching from a client that supports feature X to one that does not, should not trigger an update of the feature list except with the user's explicit approval."
How is the new client, which does not support feature X, supposed to know that the the client previously used by that user did support feature X? Moreover, even if the client could detect this, wouldn't it be a mistake for the new client to advertise a feature that it does not support?
Profiles are about users. Supported features are about clients. Mixing them together in the kind:0 metadata is likely to cause difficulties down the road. For example: as a client, I don't know what client user XYZ is using at any given moment. User XYZ's metadata might say that NIP-X is supported, but XYZ might not be using that client at the moment.
In other words, features don't stay with users. Users will move from one feature environment to another as they switch between clients. Therefore I don't think advertizing client features makes sense.
>From: Giszmo47 at 07/28/22 21:08:12 on wss://wlvs.space
>---------------
>Proposing a new nip: [NIP-23: "Supported Feature" Signaling](https://github.com/Giszmo/nips/blob/featureSignalling/23.md)
Some clients, like more-speech, send out queries for messages using the "since" filter, and set the "since" time to be the time of the last message they stored during a previous run. So, in effect, more-speech pops into the message stream for awhile, gathers up some messages, stores them, and then exits. Upon restarting, it asks the relays for messages with dates later than the last message it saved.
If a metadata message is sent by user xyz once, say, on January 1st, 2022; and then never again; and if a client, like more-speech, starts up for the first time on February 1st, and asks for all the messages that are one week old, it will never see the metadata for xyz.
It seems unlikely to me that the first time a client runs, it will pull back all messages since the beginning of time. Thus, it seems to me, that metadata should be transmitted on a fairly regular basis.
>From: Giszmo47 at 07/28/22 20:43:48 on wss://wlvs.space
>---------------
>Why does it matter when kind-0 metadata is sent?
>"Clients pop into the message stream"???
>
>Clients query it and get whatever was sent last regardless of this being minutes ago or months ago. Relays store (sort of forever) and forward.
OK, I think I'm starting to understand. What we want is for clients to integrate profiles, not overwrite them. So if damus sends `display_name` for user in the metadata for user xyz then more-speech should add that field to it's profile for xyz. If all clients did that then, over time, all clients would accumulate all the fields.
Another way to work it would be for each user to assign a particular client to be responsible for transmitting metadata and have all other clients that they use NOT send metadata. The transmitting client would be the master of the metadata for that user, and all other clients would be slaves.
One thing that the NIPs don't specify is WHEN metadata should be sent. Once is not enough since clients pop into the message stream at different times. If they miss the metadata then they never see it. That's why more-speech sends it out at startup. It seems to me that metadata should be sent at least once per day.
Although I STILL don't understand NIP-05.
>From: Giszmo47 at 07/28/22 16:17:58 on wss://wlvs.space
>---------------
>Damus stores display_name in **kind-0** events. Astral stores nip_5 something something in **kind-0** events. Clients that write **kind-0** events without preserving what others write there, "nuke" the config of other clients.
Does damus transmit the `display_name` in the kind 0 metadata? And when does damus send metadata?
>From: jb55 at 07/28/22 16:06:49 on wss://wlvs.space
>---------------
>Yes damus has 1 additional field in the profile: display_name which is meant to be used like a full name:
>
>display_name: William Casarin
>name: jb55
>
>but yeah I don't see what nip05 has anything to do with this, other than branle which uses nip05 like a display name I guess?
#[6] #[7] I'm still not getting it. What problem is NIP-05 trying to solve? What problem happens when more-speech sends out the user's meta-data? In what sense is that message "nuking" anything? Isn't it the client's responsibility to interpret the message and integrate it with any other variables? Are there clients that use other parameters in the profile beside the NIP-01 metadata parameters (name, about, picture)?
I'm struggling to understand the point of NIP-05. What does it accomplish?
more-speech spams out the metadata of the user at every startup. I could easily make that a configuration option, but why is that a problem, and how does NIP-05 solve that problem?
>From: Giszmo47 at 07/28/22 13:24:07 on wss://nostr-pub.wellorder.net
>---------------
>Formulating the spec I'm struggling with exactly this. more-speech spams out your kind-0, removing your nip5 and stuff with every start. This is not sustainable and switching from a client that supports DM to one that doesn't shouldn't advertise this if you also use the other.
37-dev your e tags are still malformed. Should be:
["e" "3f649b000d819dee2bd2d1fdafb5ba3fcbcf6b3e0de8b491d2897a104ce17b8b" "wss://nostr.drss.io" "reply"]
#[2], I expect you'll "like" this.
"boltfun Story_comment 37dev" pubkey:57f03..., Your e tags are malformed.
You: (:e "ee214... wss://nostr.drss.io reply")
Should be: (:e "ee214..." "wss://nostr.drss.io" "reply")
Hello!