Nostr Web Client

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.

Sasha 1y ago

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?

Reply to this note

Please Login to reply.

Discussion

Valentino Giudice 1y ago

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.

jimbocoin 🃏 1y ago

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.