Nostr Web Client

https://nips.nostr.com/1

Correct answer. Don’t need to overcomplicate it. I was able to build a client just by reading nip01. nip10 didn’t exist, so I copied what other clients were doing and I just added stuff that I needed like filter limits and command results.

I am not a fan of generic replaceable events/atags and am fighting against implementing that for as long as possible, so you can ignore that if you want basic event sourcing (outside of profiles and contact lists). Luckily nostrdb ignores that so you have a proper versioned history of all your profiles and contact lists.

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 1y ago

> I am not a fan of generic replaceable events/atags and am fighting against implementing that for as long as possible

Are you fighting against replaceables in general or just with the idea of deleting past versions of them? Would you be ok if past versions were kept in the database but not indexed? Or is there something else that bugs you?

jb55 1y ago

i would prefer versioned events with pruning. I don’t like the concept of replaceable events or information destruction as a core protocol feature.

Vitor Pamplona 1y ago

That makes sense. But the text does not require events to be deleted. It says:

> for kind n such that 10000 <= n < 20000 || n == 0 || n == 3, events are replaceable, which means that, for each combination of pubkey and kind, only the latest event MUST be stored by relays, older versions MAY be discarded.

Which basically says that both pruning and deletion are acceptable implementations. Do you think the text should push more clearly for pruning?

We could change to this:

> for kind n such that 10000 <= n < 20000 || n == 0 || n == 3, events are replaceable, which means that, for each combination of pubkey and kind, the latest event MUST be stored and previous versions SHOULD be stored. Past versions MAY be pruned.

Basically the same thing, but adding a preference for pruning.