Policy for inclusion in the flake search

[ncfavier]

Basically a mirror of NixOS/flake-registry#25, triggered by #482.

I think the policies should be somewhat similar between the two repos (if not tied together by only indexing flakes in the registry), and moreover I don't think nixos-search is currently ready to include every flake in the universe.

[ysndr]

I think the issue the registry faces is not one we have in the search.
In the issue you mentioned it was brought about that the registry is a global namespace and therefore has quite a bit more influence.

Only indexing the registry defeats in my opinion the purpose of the search.

A) the search should make projects more discoverable, that includes small projects that are not yet popular enough to be in the registry.
B) As mentioned in the issue, the registry is not really necessary and just a shorthand for a selected set of packages. I don't see why we should bind us to something "unnecessary"

The registry also has to maintain a certain standard of quality and security as packages in there could be considered "officially approved".
Yet, neither us search people nor the maintainers of the registry have the capacity to QA every flake added (and track it over time).
Options to face this are either putting up extensive rules that narrow the amount of flakes that need to be considered/screened or providing a somewhat neutral index.
Considering the goal to improve discoverability I think we should lean more towards the latter although.
Still we should come up with some rules that filter out flakes with no public benefit (such as completely personal configs, or false flag flakes)

Regarding nixos-search, I think indexing more flakes (within limits) is not too much of an issue since most flakes are relatively small.
There are also efforts to include whole organisations into the search.

I agree however that in the current state flakes are quite disorganized and should be addressed in the current redoing.

These are my first thoughts on this
Let's discuss possible filters below or other options below!

[ysndr]

Some points of todays discussion on the topic:

Most indexes allow you to publish your work on your own account. Cargo, for instance is famously indifferent about the packages listed there.

In contrast, we have a whole PR process for this which may be good to prevent spamming but also makes us discuss the same issues over again to the frustration of flake maintainers.

So what are the reasons we reject/block packages?

• Add nix-vscode-marketplace Source #530
  • incorrect flake definition
• Add home-manager to flake sources #481:
  • including may cause more confusion than clarity.
  • too many options?
• Add a new public flake to the list #482:
  • sparked a discussion in the registry repo Policy for inclusion in the flake registry flake-registry#25
    note: we dont have the namespace issue mentioned
  • not a "nix ecosystem app"
• flakes: add lnbits-legend #510
  • cryptocurreny middleware
  • monetary project?
• Add move.nix to flake manual #533
  • blockchain tools

Summarized that is:

• incorrect flakes, which should be blocked or even removed eventually if the indexed ones break regularly.
• "non nix tools" At which point does something become a nix tool then? and wouldnt that definition invalidate half of our existing catalog? most of the ngi-0 packages are not nix tools, their maintainers often dont even use nix
• Cryptocurrency
  Blockchain projects see an increasing use of nix, and start being interested in a spot in the ecosystem. IOHK, Tweag, Serokell, all are tightly entangles with both Nix and Crypto.
  I dont deny certain ideological concerns about crypto but I dont know why we should shut them out entirely, without reason.
  In the end these players could even help popularizing nix further which is a win
  Regardless we may need to discern "official" from "unofficial" flakes, we should neither endorse or hinder the usage of any particular tool over another.

In my option limits such as requiring the projects to be "non-profit" would make slightly more sense.

Additionally, I think we can do a better job enabling others to spin up their own search for their respective target audience.

Final note: nixos-search is not an advertisement platform, and if it was it did a very bad job.
However even more important is it to clearly state that all these projects are just public repositories that happen to be buildable using nix bun none of them are endorsed OR cherry picked by nixos.
The bar should be: can the package be evaluated (we can't check the build) and is it safe (in the eye of the reviewer).

[MatthewCroughan]

@ysndr lnbits-legend is not a cryptocurrency wallet. It is middleware like e-commerce plugins for wordpress, for facilitating transactions.

[ysndr]

Thanks @MatthewCroughan for correcting me.
Took that from https://legend.lnbits.com/ site which states:

free and open-source lightning wallet

[MatthewCroughan]

Yeah, it's probably bad that they say that, rather than being more clear. I will try to get that changed to be more representative of what the software actually does in practice. It has only existed for a year, so their descriptions are not 100% accurate. It does provide the functionality of a wallet, but that's not the main reason to use it, or what it does.

[hugosenari]

registry.json X manual.toml:

My concern related to usability. The user expectation when both Index, one with WebUI other with CLI, but one has more things indexed.

Also, the URL in the index page could be smaller if flake-registry is the source of truth, i.e.:
github:NixOS/nix#nix to nix#nix or nix.

# useless trick
nix run nix -- run nix -- run nix -- run nix -- run nix -- run nix -- run nix -- --help

TIL. We do not index github:NixOS/nix.

It is another issue, of having two different sources. Forget to add to both, making two PR, convincing two maintainers...

flakes-registry only have the issue of namespace, because they're registering single pkg flake, instead of sub registry list (like NUR). Doing same here would reduce the toml size and hopefully reduce time to process it.

A) the search should make projects more discoverable, that includes small projects.

Agree, for both search and registry. Flakes-registry could be the official version of NUR.

B) As mentioned in the issue, the registry is not really necessary and just a shorthand for a selected set of packages. I don't see why we should bind us to something "unnecessary"

We diminished the importance of usability for so many years that the first joke I learn about nix is about learning curve.

Then we tag usability features as 'unnecessary'.

---

Filtering by ideology

requiring the projects to be "non-profit"

Paraphrasing:

"I dont deny certain ideological concerns about crypto X but I dont know why we should shut them out entirely, without reason.
In the end these players could even help popularizing nix further which is a win."

---

Overall suggestion

Flakes brings decentralization, it is good, but we cannot expect all 'nodes' of this new decentralized schema to have the same quality, like we never know the quality of a npm, docker or pypi before use it.

I think we should blacklist offenders:

• Legal issues;
• Supply Chain Attacks (Dependency Confusion, Repojacking);
• Fail to match some SLA to be defined (i.e. broken for 1h, 1d, 1w, 1m, 1y).

Related: https://discourse.nixos.org/t/call-for-volunteers-curating-official-projects/45382