Discussion: consider removing libraries' links from spec readme #81

New issue

Open

opened 2024-02-06 21:16:48 +00:00 by thunderbiscuit · 1 comment

thunderbiscuit commented

2024-02-06 21:16:48 +00:00

(Migrated from github.com)

After speaking with @ngutech21 over a dev call last week, I decided to open an issue to discuss the value of the links to the libraries that implement the NUTs in the README.

My thinking is the following: links to individual libraries that implement the cashu protocol are important, but belong elsewhere than the spec (main website? awesome list? other places?). Here are a few reasons why I think over time it gets harder and harder to keep those in sync, and how they somehow complicate the commit history of the spec repo without reason.

It used to be just a few libraries, but now there are a lot more! It's a lot of links. Keeping them up to date is messy and likely to always be slightly behind.
Some of the libraries in the list did implement certain NUTs, but might not have updated to the v1 endpoints. What does that mean for the links? Should we remove them? Until they implement them, and then bring them back?
What happens when libraries become unmaintained?
There is a feeling (for me at least) that the spec is a rather static document(s) that moves slowly and cautiously. For the links in the readme to be valuable, they need to be quite opposite this, and be evergreen/changing. The two might be better if they are separated.
Reading the commit history of the spec is partially "polluted" by commits that simply add/remove links to new or outdated libraries in the readme. These commits don't impact the spec itself; it'd be good to have few of them.

Now I think the readme should point to locations where developers would be able to find that sort of information, but that could be just a new section with some meta links, or maybe just a sentence like You can find a list of libraries that implement the various NUTs in this spec at [this link] and [this link].

Anyway just a thought as the spec matures.

After speaking with @ngutech21 over a dev call last week, I decided to open an issue to discuss the value of the links to the libraries that implement the NUTs in the README. My thinking is the following: links to individual libraries that implement the cashu protocol are important, but belong elsewhere than the spec (main website? awesome list? other places?). Here are a few reasons why I think over time it gets harder and harder to keep those in sync, and how they somehow complicate the commit history of the spec repo without reason. 1. It used to be just a few libraries, but now there are a lot more! It's a lot of links. Keeping them up to date is messy and likely to always be slightly behind. 2. Some of the libraries in the list _did_ implement certain NUTs, but might not have updated to the v1 endpoints. What does that mean for the links? Should we remove them? Until they implement them, and then bring them back? 3. What happens when libraries become unmaintained? 4. There is a feeling (for me at least) that the spec is a rather static document(s) that moves slowly and cautiously. For the links in the readme to be valuable, they need to be quite opposite this, and be evergreen/changing. The two might be better if they are separated. 5. Reading the commit history of the spec is partially "polluted" by commits that simply add/remove links to new or outdated libraries in the readme. These commits don't impact the spec itself; it'd be good to have few of them. Now I think the readme should point to locations where developers would be able to find that sort of information, but that could be just a new section with some meta links, or maybe just a sentence like `You can find a list of libraries that implement the various NUTs in this spec at [this link] and [this link].` Anyway just a thought as the spec matures.

thesimplekid commented

2024-02-13 23:54:35 +00:00

(Migrated from github.com)

Agree, think it makes sense to move them to https://github.com/cashubtc/awesome-cashu or similar and remove them from the spec repo.

👍 1