upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md31
1 files changed, 19 insertions, 12 deletions
diff --git a/README.md b/README.md
index 790f0b6..b8b98d9 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,7 @@
1# NIPs 1# NIPs
2 2
3NIPs stand for **Nostr Implementation Possibilities**. 3NIPs stand for **Nostr Implementation Possibilities**.
4
4They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software. 5They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software.
5 6
6--- 7---
@@ -12,7 +13,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
12 - [Relay to Client](#relay-to-client) 13 - [Relay to Client](#relay-to-client)
13- [Standardized Tags](#standardized-tags) 14- [Standardized Tags](#standardized-tags)
14- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips) 15- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
15- [Mailing Lists](#mailing-lists) 16- [Is this repository a centralizing factor?](#is-this-repository-a-centralizing-factor)
17- [How this repository works](#how-this-repository-works)
16- [License](#license) 18- [License](#license)
17 19
18--- 20---
@@ -226,21 +228,26 @@ Please update these lists when proposing NIPs introducing new event kinds.
2264. There should be no more than one way of doing the same thing. 2284. There should be no more than one way of doing the same thing.
2275. Other rules will be made up when necessary. 2295. Other rules will be made up when necessary.
228 230
229## Mailing Lists 231## Is this repository a centralizing factor?
232
233To promote interoperability, we standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
234
235It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
230 236
231The nostr ecosystem is getting large with many different organizations, relays 237There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.
232and clients. Following the nips repo on github is becoming more difficult and
233noisy. To coordinate on protocol development outside of github, there are
234mailing lists where you can work on NIPs before submitting them here:
235 238
236* [w3c nostr community group][w3-nostr] - [public-nostr@w3.org][mailto-w3] - requires signup 239## How this repository works
237* [nostr-protocol google group][nostr-google-group] - [nostr-protocol@googlegroups.com][mailto-google] - no signup required
238 240
239[w3-nostr]: https://www.w3.org/community/nostr/ 241Standards may emerge in two ways: the first way is that someone starts doing something, then others copy it; the second way is that someone has an idea of a new standard that could benefit multiple clients and the protocol in general without breaking **backwards-compatibility** and the principle of having **a single way of doing things**, then they write that idea and submit it to this repository, other interested parties read it and give their feedback, then once most people reasonably agree we codify that in a NIP which client and relay developers that are interested in the feature can proceed to implement.
240[mailto-w3]: mailto:public-nostr@w3.org 242
241[nostr-google-group]: https://groups.google.com/g/nostr-protocol 243These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.
242[mailto-google]: mailto:nostr-protocol@googlegroups.com
243 244
244## License 245## License
245 246
246All NIPs are public domain. 247All NIPs are public domain.
248
249## Contributors
250
251<a align="center" href="https://github.com/nostr-protocol/nips/graphs/contributors">
252 <img src="https://contrib.rocks/image?repo=nostr-protocol/nips" />
253</a>