NIP Bloat. - Implementation possibilities are specd with less and less consideration for each other. - many overlap in functionality but none are removed or deprecated for “backwards compatibility”. - Some old school devs pull weight and don’t wanna change. - some younger devs have no patience for discussion and “patient” integration of “good” ideas. - devs are burnt out with the “bureaucracy” of maintaining a swamp of standards. - nips are treated as standalone “islands” serving single use cases. - inconsistency and inoperability creep across clients and relays, as gate keepers “give up”. - Users become disillusioned with “the dream” of decentralized cooperation, as nostr dies a slow death due to dwindling adoption.

Replies (8)

I understand your points but I don't think to a user, interoperability is that big a concern, unless it messes up basic TL big time. Even now, threads are a mess across clients & NIP 94 images created on Amethyst are not seen on many clients & it's not caused a hullabaloo 🤷 I'm guessing most people will try out maybe 2-3 clients & stick with the ones they like.
STERRY's avatar
STERRY 2 years ago
If you are honestly concerned, take a look at the proposal below to define a process. I have some experience here as an early editor in the fediverse's FEP process. There FEP-a4ed defined a process that handles proposals from submission to deprecation. It might be interesting to collaborate on a submission process tailored to issues and challenges of the current NIP space. Issue (which looking at all the NIP-XXs in the repo seems to have uptake): Pull request: