How long before Nostr gets too big for lone wolf developers?
Most devs can hack together a relay or a simple client in a weekend...for now. As the number of NIPs increases—as does the userbase—the bar for quality Nostr software will just keep getting higher. Code quality and design will matter a lot more.
At that point, we'll need teams of developers and clear paths to monetization to make it worth their while.
Feature bloat kills so many projects.
Is there a process for de-authorising NIPs?
NIP itself is pretty hackish, it's going to have to give way to something more organised and meritocratic at some point
being that I'm implementing a base set of parsers for them I can attest that the specifications have many missing stipulations that are assumed into existence by common JSON encoders that defy expectations from someone not experienced with JSON especially javascript JSON and the most popular encoders for C++, Rust, etc, and many of those are outside of the expectations of Go programers who are used to stringently static typing and no wibbly wobbly union and underspecified variadic structures
Not that I'm aware of. I think NIP-04 has been deprecated, but not by any formal process. It fell out of use and clients started to replace it with a new standard.
But NIP support is entirely voluntary, and there's no guarantee all clients support them equally, or even correctly.
"hack" being the operative word
my current task, that i set for myself as leader of a project development, i have one underling, is to clean up the base of the Go toolkit for relay building before we proceed to plug it into other things
by the time i finish this one i'll be ready for something even more meaty, it helps a lot to build a good toolkit, everything gets easier when your tools are higher quality and you have some experience with the complet assembly
Nostr is quickly reaching the Lone Wolf Horizon. Pretty soon it'll take a whole team of developers just to understand and implement all the relevant NIPs.
It's not hard to add to an existing client, but if you're trying to create a new one, ensuring compatibility with existing clients is a hefty piece of work.
More NIPs isn't the problem, it's adding complexity to existing ones (a tags, for example)
Can you elaborate on that? Are you referring to NIPs that redefine or expand functionality first defined in an earlier NIP?
Another problem is NIPs getting changed from under you. Ideally, once it is merged, it shouldn't change.
I distinctly recall looking at NIP-07, then returning to it a few weeks later and noticing a new optional method had been defined. It's optional, so not a huge deal, but something like that can affect existing client implementations.
