The current Web UI search accept a single string that is used as list of tokens to search either in URLs or metadata.
We want to have a "[[ https://support.google.com/websearch/answer/2466433 | search engine-like" ]] sub-syntax that, without becoming too structured, allows to express specific facets.
Here are facets that come to mind as already useful today:
- loader: (or "visit type", not sure what would be the best name for this) to filter on which loader has been used (without this today we cannot easily select all pypi, debian, or cran packages, for instance)
- last_visited: (with some relational operator) to return only results that have been last visited in a given time frame
- metadata fields: our [[ https://www.softwareheritage.org/2019/05/28/mining-software-metadata-for-80-m-projects-and-even-more/ | metadata indexing ]] extract a bunch of properties that would be great to filter on, rather than lumping them all together into a single full-text search (this requires some care into avoiding clashes between the metadata key namespace and the search facet one)
Other stuff that might be added in the future, provided we have suitable backend indexing:
- project size: filter on number of, e.g., commits
- file content: filter on projects that contain a given substring. This one hints at the fact that we will probably want to have a selector determining which type of objects will be returned, e.g., origin (the only possibility today) v. a specific type of Merkle DAG node
Working on this requires a bit of language design before rushing into implementation, to make sure we come up with something consistent and intuitive to use. Sounds like a good topic for a collective brainstorming session !