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