NIP-01 decomposition
p2w34 opened this issue · comments
I understand the idea behind NIP-01 was to constitute the complete basis of the whole protocol. One easy-to-grasp document to demonstrate the thing is straightforward. The cons are that a few things got mixed, limiting its potential.
One could consider splitting NIP-01 into smaller parts without sacrificing backward compatibility, at the same time gaining more flexibility:
- NIP-0: Decentralized registry (nostr-protocol/nips#162 although more discussions needed)
- NIP-1a: Base event format with well described types of fields.
a) Only value1: text_noteas the default one introduced here forkind—the rest of the values presented in other NIPs.
b)algofield added, with 'secp256k1' being the default. Signing is challenging, as done preferably by hardware wallets, hence more methods should be supported (future NIPs). The verification part is easy (no penalty for screwing it up), and done with any software.
c) The wayidandsigfields are computed should be changed. Instead of saying what fields should be included, one could specify which should not. This way the description stays precise even when new fields are added in future NIPs. - NIP-1b: Application protocol (filters/subscriptions). It should be presented in a way that is separated from the communication protocol. The websockets would stay as the default choice, but this would allow the introduction of other forms of communication protocol. I could easily imagine a future NIP with plain HTTP being an alternative - this way I could... store all my posts on any HTTP server.
- NIP-1c: Event types (
0:metadata,2:recommend_server).
For me NIP-0 (well, depends on the implementation), NIP-1a and NIP-1b should form the solid basis for the protocol.
This does makes sense, I agree, but is it really worth the trouble?
I am just sharing my observations. The current pace of development is fast, and for sure, some things will turn out to be exceptionally good, and some - on the contrary. Hence I am adding my two cents to the general discussion with the hope Nostr will have a firm basis so that the rest (which NIPs survive and which not) could happen in a form resembling natural selection.
An algo parameter would be good.
secp256k1 is doubted to be not safe enough as shown in https://safecurves.cr.yp.to/
Attack to secp256k1 has not happened yet. The weakness exists in theory only. But who knows.
We can switch once an attack happens.
The need for refactorings is often easy to spot. The hard parts are managing it and the right timing
(I learned it the hard way, working on enterprise backend projects, which development often spans multiple years).
I wrote a short text with a proposition about how one could decentralize the development process (i.e. decentralization of the NIPs registry). I thought about it during the past two weeks, and talked to a work colleague during lunch - the problem in general seems interesting and is for sure not easy to figure out :-) My thoughts are here: https://medium.com/@p2w34/decentralized-development-of-decentralized-protocols-d2fc5eee2492