What are the best nostr overview and getting started resources for developers?

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr

Reply to this note

Please Login to reply.

Discussion

thanks for that

Definitely outdated. Going to be updating it soon though.

Unfortunately, it is missing

What must this new to nostr resource for devs include nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk ?

What are nice-to-haves?

General overview

Specs (NIPs)

Curated list of languages' libs

Code examples

It’s not really for getting started with development.

npm create osty@latest 👀

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.

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

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

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.