Nostr Web Client

I think the concept of "layers" has been beaten to death and stretched way too thin, to the point of meaningless.

With that out of the way, random thought:

Most NIPs are not nostr but protocols on top of it (nostr = NIP-01)

NIP-04 (DM/encryption scheme), NIP-44 (DM/encryption scheme, NIP-46 (remote signing), NIP-47 (wallet protocol), NIP-90 (data vending machines), etc. All different protocols built on top of Nostr.

That's why we can end up with competing NIPs implementing the same functionality, and why worse NIPs with more network effects can prevail.

E.g. Should a new client that wants to implement DMs go with NIP-04 or NIP-44?

I agree with nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c that rewriting NIP-46 in a completely incompatible way was the wrong approach and it would have been better as an independent NIP that should have battled it out against NIP-46 in the market, just like NIP-44 is challenging NIP-04.

Seeing (some) NIPs as protocols, and not simply functionalities might be a good heuristic:

NIP-46 is not just "remote signing" it's "remote signing with this particular protocol", if we want to change the approach it makes sense to do it via a different NIP that needs to earn it's own and dethrone the competing protocol that provides the same functionality.

Reply to this note

Please Login to reply.

Discussion

Carman 1y ago

This is kinda what I was trying to get across about ecash zaps.

Leurico8 1y ago

great explanation mate

Cameri🐦‍🔥 1y ago

Let the best NIPs win 🏅

hodlbod 1y ago

This is a helpful model vs deprecations

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

i personally think that if you go look at my version of go-nostr

https://github.com/Hubmakerlabs/replicatr/tree/main/pkg/nostr

you will see that i am in the process of ordering the protocol by human readable concepts and far more clear than the existing shomozzle based on this stupid RFC derived number specification shit

i'm not against the numbering of the specifications, per se, so much as not having a cohesive map of the architecture of the system that keeps things related to each other

you will see as you dig through the code how i have reorganised go-nostr that the majority of the protocol fits into a set of simple concepts and some have branches on them, like envelopes, which are the nostr equivalent of API messages

i think that the protocol will advance a lot faster once people start to tie together the specification better and have an easy reference to work on

hell, after i'm finished my current assignment, i'd be very happy to write the documentation that ties everything together with lots of obsessive hyperlinks to the NIPs and even their historical state to help devs really wrap their heads around it because it really is a lot to learn and the structure is contrary to easy learning

Tim Bouma 1y ago

Maybe we should call them “Nostr Improvement Protocols”? They are all protocols (or subprotocols) that improve upon NIP-01. Also agree that trying to definitively organize things into “layers” is not really helpful.

Chris 1y ago

This totally makes sense. I like your approach.

mrclownworld 1y ago

Competing versions of the same feature could append with a letter

Eg NIP-46A, NIP-46B and so on.

Would be much more organized as this ecosystem grows

mrclownworld 1y ago

If you do it like film people do, you skip I and O and you go to double letters after you use Z

ManiMe 1y ago

Three kinds of Nostr Implementation Possibilities

- NIPs that add new possibilities to Nostr

- NIPs that compete to provide overlapping possibilities

- NIPs that extend existing possibilities.

We need a map.