GM @fiatjaf 

 That's what I use as class name on Amethyst :) 

 I think that settles it then. 

 I had to read the NIP about 100 times to understand what a ‘parameterized replaceable event’ was. I think I understand. I like ‘addressable event’ better because it implies that it has a unique address - pubkey/kind/descriptor. I presume it is ‘updateable’ or ‘replaceable’? 

 The address stays the same, but you can send a new event which will have the same address.
It is assumed that the most recent one is the valid one.

(Of course, there is no guarantee that clients will actually receive the most recent one, so outdated information might be displayed). 

 All events are addressable by their ids. Parameterized replaceable events are replaceable by their parameters.

The current naming convention is more clear. 

 You are wrong. 

 Wait events are replaceable now? 😔 

 Some are. It depends on the kind number.

Each event (note) has a kind number. Kind=1 notes are regular text like this message to you. Kind=7 is a reaction. Kind=5 is a deletion, and so on.

Every event has a unique ID, and so they can’t be replaced by ID alone. Replaceable events have kind numbers in specific ranges. Based on the author’s npub, kind number, and tags (parameters) some events can be replaced by later events.

So for example, if you write a long-form article and want to be able to update it, you could publish it as a parameterized, replaceable event so that later if you want to make edits, relays will accept your replacement event. 

 Thank you 🙏 for the understandable explanation you must have a talent for relaying information 

Is there any way to stop a client from auto creating your event as parameterized or ensure as poster you only want type 1? 

 That depends on the client.

However, note that kind 0 events are also, effectively, replaceable. Those contain the information on your profile. You wouldn't want that to be irreplaceable. 

 Once you give a client your nsec, technically, the client can sign whatever notes it wants. So if you’re serious about stopping replaceable notes, you’d want to individually inspect and approve each event JSON before signing. For example, you could use an extension (like nostore, the Safari plugin) with a web client.

In general you don’t need to worry about it. Clients that are for regular messaging will make regular kind=1 events for text, kind=7 events for reactions, kind=0 events to update your profile, kind=3 events for your follow list, kind=4 for DMs etc. You can browse a list of known kind number meanings here: https://github.com/nostr-protocol/nips?tab=readme-ov-file#event-kinds

In addition, clients tend to ignore events of kinds they don’t recognize. When your client subscribes to events from a relay, it sends a REQ message, which can include filters. It’s common to filter the events returned to just known, necessary event kinds. This reduces network traffic and bandwidth usage. 

 Not an argument. 

 From a very SMPLTN point of view FJ. Is it a trade off for the NOSTR protocol to have append/update/delete options for notes? 

 I would drop "parametrized", just "Replaceable Event", it's cleaner 😉😅. All replaceable events should be parametrizable, current non-parametrizable events could just be viewed as parametrized with a null parameter. 

 I don’t understand what the “parameterized” part means. In the Nos code we call them replaceable events.  

 There’s parameterized and non-parameterized replaceable events. The former has a “d” tag that stays constant over replacements, which is useful when you can have multiple events of a given kind. The latter does not have the “d” tag, which means only one event for a given kind should exist, in theory. 

 Maybe I just don’t know what “parameter” actually means. I think of it as a variable that can change on each invocation of a function. So from that perspective both “parameterized replaceable events” and “replaceable events” can be thought of as outputs of a function where the parameters are content, tags, pubkey, etc. So it kind of confuses me that one is called parameterized and one isn’t. I would say one has a stable address and one doesn’t. 

 This is interesting when only one possible value of "d" is documented.
It's effectively non-parameterized, but still parameterized according to the spec. 

 This would maybe help clarify that the reference to the event can be called "address", something which seems part of the Nostr jargon but not really consistently specified (although consistent with the tag name for such a reference being "a").

However, I'm not convinced it's a good name. "Addressable event" merely suggests that you can refer to it, which is true for all events. "Replaceable" gives more information about what they actually are. 

 whatever any of that means, anyways, post some music.