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. 
)
