Damus
SondreB · 1w
This is a wrong take. It takes a lot of effort to build good libraries, even when using AI. Letting loose random developers to use AI to do the protocol implementation of Nostr is a very bad idea. Th...
Vitor Pamplona profile picture
Nostr-tools has a lot of bloatware nobody needs in a library architecture (everything in one repo) that doesn't make any sense. Of all the libraries, that one needs to die first.

On the NIPs, we already migrated to http://nostrhub.io to help manage all the NIP forks out there.

The least amount of since source of truth, the better.
freemymind 🇨🇭 · 1w
> The least amount of since source of truth, the better. I totally agree on this one. It is great to keep the shared resources minimal.
SondreB · 1w
There is no problem having all the NIPs implemented in the same repo, why is that a problem? The opposite is a disaster, I know how horrible it is when developers goes nuts with "microservice" repos. Any app that needs NIP-19 encoding in their web app, will only load a minimal set of code into thei...
cloud fodder · 1w
I can tell you have never used nostrhub.io because it doesn't show the nips. It's just another vibe left in the wild with no maintainers only influencoors propping it up. At least I can still go find the nips with nak, but I won't use it for anything real, knowing it is a dead end, and being annoy...
mleku · 1w
neither NPM nor the current architecture of git are really appropriate for decentralization. what's needed is a nostr-based NPM, and then store the git logs as blobs on blossom with nostr events providing the map of their hashes. having just done a lot of work today on making use of NIP-94 to crea...