The fact that I haven’t written a proposal doesn’t mean I don’t understand how the existing system works. And I’m not trying to fix it — a system like NXIP/NRC simply doesn’t exist today. The specs site is a documentation site. NXIP, NRC, and specs can and should coexist, they serve different purposes.
So every wallet needs to implement the same features as every other wallet? There’s no room for differences? I’m building features that the community has been requesting in Discord and Telegram — features that make sense for a wallet. Should I block community requests just because Wally does things differently?
And what if Wally’s approach isn’t the best one? Should every wallet repeat the same patterns without question?
Ironically, this is exactly the kind of problem that a proper NXIP/NRC process would solve — we’d have a shared, discussed standard before implementation, instead of discovering incompatibilities after the fact.
Nobody ever communicated such a request to me. If someone had asked me to pause a feature to discuss it, I would have. But that never happened. Assuming otherwise without checking with me directly is unfair.
Why retract? The specs site documents features after implementation with a technical focus. NXIP/NRC is about proposing and discussing features before implementation, with a proper review process. These are fundamentally different things. I can’t add something that doesn’t exist to a system that wasn’t designed for it.
How do you currently communicate to the ecosystem what’s been implemented and what hasn’t? How do apps signal “we support this standard but not that one”? There’s no mechanism for any of this today.
Let me give concrete examples. Tailstorm is already being worked on in the full node. The marketing team is promoting it. It requires a hard fork. Yet where is the Nexa-specific technical design? Where is the architecture document describing how Tailstorm is implemented in Nexa? Where should the community find information about this — from messages in Telegram?
Same with Falcon for post-quantum signatures. The algorithm itself has public documentation, but where are the Nexa-specific technical specs? How is Falcon integrated into Nexa’s transaction signing? What are the architectural decisions? These documents don’t exist.
We’ve accepted core protocol changes, yet there is no public place to find any information on the design decisions behind them. This is precisely the gap that NXIP/NRC would fill.
The specs site is a documentation site, not a proposal system. Using it as one doesn’t make it one.
I opened issues, which is a valid and standard way to contribute — especially when you’re working part-time with limited hours. For someone like you with deep knowledge of the C++ codebase and strong English, fixing a spec might take an hour. For me, it could take days. Opening an issue so the right person can address it efficiently is the responsible thing to do.
You yourself have opened issues on Rostrum rather than fixing them in Rust — for exactly the same reason. Dagur knows Rust better, so it’s more efficient for him to handle it. This is how teams work. You can’t expect everyone to “fix it yourself first” as a prerequisite for raising problems.
This is exactly the point. NXIPs/NRCs are written before implementation. Once they reach Final status, they don’t need ongoing maintenance — they’re a historical record of what was proposed, discussed, and decided. The specs site, on the other hand, is living documentation that needs frequent updates. These are two different things with two different maintenance models.
This proposal isn’t trying to replace the specs site. It’s trying to establish a proper framework for proposals before implementation — the same framework that virtually every other blockchain project uses. This benefits not just us as developers, but the entire community. When an NXIP is accepted, it can be announced publicly. The community can read, understand, and discuss upcoming changes before they go live. And once it’s Final, it serves as a permanent, clear reference.
The alternative is what we have today: important protocol decisions discussed privately, implemented without public review, and promoted to the community before anyone outside a small group has had a chance to weigh in.