I want to clean up NIP-01 a little more, remove the things no one uses, like kind2, and merge in NIPs 12, 16 and 20. Is that a bad idea?

Reply to this note

Please Login to reply.

Discussion

Good idea. Nip 01 is nostr

Which begs the question: what the fuck of the rest?

Oh I know, nostr layer 2 😂😂

Good idea. I reference nip01 all the time, it would be nice if it was updated.

I don’t know about 12 & 16 tho

20 is a must

is that allowed? did you check with the boss?

clean up nip 1 ✅ was wondering what happened to 02

Came crossed this video, hard to tell how much is said in good faith, might not be worth your time to consume, but at some point an update to the read me to reflect where we are at now. I came across some new users 2 weeks ago who clearly by the clients they were asking about were working through the linked vishalxl guides and comparison lists which were a+ in December, don’t have nip 07 login now. if I think of revision or draft some addendum I’ll certainly submit a pr 😉

nostr:note12ukjfp50k987y67380zq5ew2lsvvsey9acnjr2rqwwkh0r8ghxpqupqu06

Who is this guy? I remember a Nostr hater that was on the chats an year ago complaining about my claims of decentralization.

his name is “weird unimportant guy”

idk Ignacio does a great job at finding every link that mentions nostr on the internet, that’s where I found that.

I watched about half and started skimming through, a couple of things he twisted from the read me made me think, maybe someone else in confused good faith understood it that way.

Yes, you're right. I'll watch and keep this video in mind and try to address it.

it’s definitely not worth an hour of your time, it’s more just, dude did an hour of content on the readme, and good faith non technical people will spend considerable time there before going to nip 1, even if they should just go to nip 1.

Go for it. Outdated laws and regulations are a pain in the ass. NIPs are no different. Get rid of everything that doesn't work. They are guidance, not specs after all.

💯

Having recently implemented it, a few real test vectors demonstrating id calculation and sig verification would be nice.

In particular some json encoders and decoders can modify strings silently by default (escape backlashes and emoji). I found out by trial and error.

This.

I passed the same troubles months ago.

Is there a mail list?

People who implemented theNIPss would get an notification

I would add NIP-27 to the merge.

Good idea.

Would be great to tune 12 and actually make 20 more usable before imo

Great question. The beauty of Nostr is that is so simple, it is basically only NIP-01, so any change must keep that in mind. Going by parts:

1) kind 2: recommend_server. This seems to be an optional feature, and optional features are bad to begin with in any spec (imo).

This one seems not to have a good chance to be "correctly" implemented.

If a relay is behaving good or badly, we can just advertize that in the community?

No need to be written in spec. And if no one uses it, then yes, get rid of it (that's the first thing I do when a function

is depecretated, remove it from the code base).

2) NIP-12. when adding new features to a spec, we should ask. What are the pros and cons? Does it make the spec more complex?

With complexity, we loose adopters. But by adding useful but not essentially required features to a functional spec, we gain

adopters. So, it's a trade-off. In this case, NIP-12 seems to have *very* good use cases, like the

#g ("geohash") tag to associate a post with a physical location (See Leaflet of Google Maps). Maye an alternative in the middle between

putting this NIP and others into the main NIP and leaving it alone, could be to do a "Core NIPS" or "Top 5" kind of thing. Don't know.

3) NIP-20. This one seems super important too, an acknowledgement reponse (just noticed that is not required in Nostr).

I think most Internet protocols, like HTTP or FTP, have a response built in, which seems critical in life saving missions

or money transactions (but not posting cat pictues to a relay). So, same answer as 2) , either in main NIP or "top 3".

** Inserting an idea for NIP-01 here **. Add a boolean key/pair "response": true/false that says , I do require a response or not. This

fits nicely into JSON, boolean types (it seems Nostr has none) . Is this a good idea? If yes, I'll write a proposed change to NIP-01.

4) NIP-16 replaceable events. Maybe not a Top one, don't know.

Also 💜 that I can write all the stuff above without having to pay $8/month 🙃

Add a binary format too. This helps scaling from now forward. Simple header, a byte or two for flags, and a checksum.

Maybe CBOR?