Oddbean new post about login | logout People take the NIP repo way too seriously.
Interoperability and compatibility is good though.
That's what it is for. But people think it is a spec that is mandating the development of Nostr to be in certain ways.
Vitor quem é o dono do layer3.news? Uma coisa que estava pensando aqui é o Amesthyst começar com um start pack inicial de (do layer3.news) para o usuário inciantes.
Nao faco a menor idea :( But I don't trust them to be the initial pack. That's why new users get an empty feed. I don't trust any algo out there to bring things they truly want to see in an unbiased way.
How so?
People think it's a spec that mandates how Nostr must develop, blocking everyone from doing what they want. In practice, it's just a place for interoperability. Where devs throw ideas at each other in the hope that other clients implement their stuff as is. For instance, there are hundreds of kinds being used that we have no idea what they do. They are just not defined in the NIPs because their devs didn't care. But they still use Nostr.
Got to be careful though as it is all about balance. You may want the network to get stronger and one way to do that is to think about how other may leverage your content/kinds. You don’t want to just ignore outright the good work done by others and re-invent the wheel (but make it so it only fits on one vehicle). It takes a certain level of experience as well with the network to make the statements you have made (valid though they are). New folks (self included) may not be so confident, which is where having direction from NIP helps.
Interoperability goes both ways though, if you go off doing your own thing, you also won’t be as able to leverage content from other clients.
100%. Btw saw your comment about book reviews in the NIPs. I’ve settled on a similar rating structure (should be implemented soon). https://github.com/RydalWater/OpenLibrarian It will be great to see if we can get them interoperable for both our use cases. Looking forward to seeing your client.
Absolutely! Ping me if you want to discuss anything. I’m focused on getting something I can launch, but will participate more in the NIPs repo after that.
Minutes after reading this I heard in a podcast that @merryoscar is building book reviews in fountain too. 💪 https://fountain.fm/episode/vH67sscHX8ZvxATFOyi7
Awesome, yeah will have a listen. I know the fountain team are looking at audio books so it will be great to link in with them. My focus is books reading, tracking, challenges, reviews and maybe pointing folks to where they can find/read books since open library have a lot of books available to borrow. Further out I’d like to do more like allow books markets. If you are interested I have a rough roadmap on my GitHub readme. What is your client’s focus? A review app? I hear @LynAlden asking after something like that as it has some great benefits with nostr’s social graph for surfacing relevant reviews.
Similar, my initial focus is to be able to stop using Goodreads. Particularly discovering and reviewing books.
Great, yeah very similar ideas. Same, need to stop using Goodreads.
Dropped you a DM, sounds like we’re aligned to team up a little to take down Goodreads!
Why bother with a nip repo at all (specifically in light of your last paragraph)?
Interoperability is good for everyone. But you don't need to bother if you don't want to.
So if a nip is there it means "here's my spec in case anyone wants to implement this feature" not "this feature *should* be implemented". Does that seem right? Sorry for annoying questions, just trying to understand.
Pretty much. We use words like SHOULD, MUST etc in the text to simplify the writing and more precisely describe what to do to achieve the best interoperability, but in practice they are all optional. We code outputting the most compliant events we can while, at the same time, code defensively because you are going to receive a bunch of crap that doesn't follow the spec, either intentionally or as a bug. When that happens you have a choice of not showing things because they are not compliant or fixing them on the fly to make sure your users see it even if the payload is not right.
For newer nostr devs it is hard to know how to treat the NIP repo.
10,000 nips
If you ever used multiple clients you know that not all clients follow all Nips. Some clients are very basic in terms of Nips they support and that's actually fine. Some clients use Nips that haven't been merged. But if you want to do something and somebody else is also doing it, use a NIP and be interoperable with each other. I couldn't care less if pronouns are part of a nip or not. A client that wants to add pronouns could have done it before it's in the Nip and if a client doesn't want to add it, it doesn't have to. If two or more clients decide to add such a field (whatever field) it still makes sense they use the same name for it, doesn't it? nostr:nevent1qqsw5gf7f374976vwafw77xrmxus684am9mtvtu3vmgaxnqnamkk22cpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzgj9npk
The NIPS Repo sucks *Checks to see if there are any comments on my proposed nips* 😂 nostr:nevent1qqsw5gf7f374976vwafw77xrmxus684am9mtvtu3vmgaxnqnamkk22cpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczyprqcf0xst760qet2tglytfay2e3wmvh9asdehpjztkceyh0s5r9cqcyqqqqqqgkgydyj