All the posts about Reddit blocking everyone except Google and Brave got me thinking: What if SearNGX was federated? I.E. when data is retrieved via a providers API, that data is then federated to all other instances.
It would spread the API load out amongst instances, removing the API bottlenecks that come from search providers.
It would allow for more anonymous search, since users could cycle between instances and get the same results.
Geographic bias would be a thing of the past.
Other than ActivityPub overhead and storage, which could be reduced by federating text-only content, I fail to see any downside.
Thoughts?
I think you are not a computer programmer. Trying to build an index of the web by querying other search engines is not an efficient or sensible way to do things. Using ActivityPub for it is insane. Sharing query results in the obvious way might help a little during events where everyone searches for the same thing all at once, but in a relatively small pool of relatively sophisticated Internet users I don’t think that happens often enough to justify the enormous amount of work and complexity.
On the other hand a distributed web crawler that puts its results in a free and decentralized database (one appropriate to the task; not blockchain) might be interesting. If the load on each node could be made light enough and the software simple enough that millions of people could run it at home, maybe it could be one way to build a new search engine. If that needs doing and someone has several hundred hours of free time to get it started.
If you’re looking for a distributed crawler and index:
https://en.wikipedia.org/wiki/YaCy
Yacy already exists and has been around for 2 decades.
This is close to what I was thinking, but rather than crawling independently, leverage the API results from queries to build a list of sites (and then perhaps crawl). Potentialy a tag index of sorts. I’m not solid on any idea as I haven’t investigated SearNGX enough to see how it works under the hood, but yes, on the same plane of thought.
I ran a YaCy instance for a while like a decade ago. It does federate index requests, and when you search it propagates the search request across a bunch of nodes. When my node came online it almost immediately started crawling stuff and it did get a bunch of search queries. But the network was still pretty small back then and the search results were… not great. That’s the price of independence from Google’s and Microsoft’s giant server farms, it’s hard to compete with that size.
But at the rate Google and Bing are enshittifying, I think it’s worth revisiting.
Using ActivityPub for this would be immensely wasteful. It’s just not feasable that all instances would have the whole index because it’s so large. Back when I tried it, the network still had several TBs worth of indexed pages. This is firmly in the realm of distributed P2P systems. One could have an ActivityPub plugin however to receive updates from social media near instantly and index those immediately with less overhead. But you still want to index wikipedia, forums, blogs, whatever the crawlers can find.
Sure. SearX is a meta-search engine. It does (only) queries to other search engines to get results. YaCy on the other hand is itself a search engine. It has the data available and doesn’t do queries to other engines. In theory you could combine the two concepts. Have a software that does both. But that requires some clever thinking. The returned (Google) ranking only applies to the exact search term. And it’s questionable if you can store it and do anything useful with it except for when some other user searches for the exact same thing. And also the returned teaser texts are very short and tailored to the search query. So maybe also useless. It’d be hard.
One thing you could do is crawl the results that users actually click on. And I think YaCy already does that. AFAIK they had an browser add-on or a proxy or something to intercept visited pages (and hence search results).
I really want to use this, but from what I read it basically requires a minimum of 20-30GB of RAM to be performant. Also the documentation appears to be a mess and highly outdated. I’d also want to cluster it internally and connect with outside peers still which seems possible, but with the large resource requirement not as feasible with my setup.
That’s odd, the project page states 256 Megabytes and practically speaking that’s nothing. Where did you find 20-30G? Are you sure you’re not confusing the memory requirement with the suggested free hard drive space?
Even if it does need 32G of RAM to perform well it’s not a very high hurdle. 32G of DDR4 can be had used for less than $75. Toss that in an old Core8/9 I5 Desktop, install your preferred flavor of Linux, add Docker, and you’re off to the races.
Like I said documentation is out of date, reading their forums you see quite a few posts about it. The yacy grid sounds perfect for me since it runs a bunch of microservices and I have a cluster of mini PCs. Only problem is the yacy grid is unfortunately lacks the distributed P2P part.
I’ve run it in containers, never used that many resources. The whole server (running a few dozen containers) was 32gb, and it wasn’t impacted in any sensible way.
That is misinformation. It doesn’t need anywhere close to that amount of RAM. It’s pretty much like other webapps and I used to run it on an old computer. It’ll fill up your harddisk, though. If you allow it to do that.
There also seems to be a lot of settings so perhaps they had it misconfigured. It also is Java so I wouldn’t put it past it for such a monolith of a Java program to require so much to be performant. Perhaps I’ll try a cluster of them then and see how it fares.
Well initial setup was definitely interesting. I didn’t want to expose 8090 and wanted it behind a web proxy and I finally got that working and actually received my first remote crawl overnight. I had to change to 80/443 internally so it would map correctly for p2p connections, public port setting doesn’t apparently cut it. I kinda dislike the whole setup with it micromanaging CPU load, but otherwise it doesn’t seem atrocious for a new peer at least, I guess this and the web proxy problems are likely awkward due to the age of the software.
Well, I am, including products in the Fediverse. And I never said federate the search queries.
Never made this suggestion.
Now you’re getting there.
Okay, sorry! Still a long way to go before the idea becomes sufficiently well-specified to make much sense to me though. Perhaps an examination of yacy could provide you a concrete example of the ways in which such things are complicated. One would need to do much better to end up with a suitable replacement for the ways many of us use searx.
It was wanting to use ActivityPub and the “I fail to see any downside” which led me to read the rest of your post in a way that might’ve been overly pessimistic about its merits.
Yea, another user has suggested passing along the request to other instances when API limits are hit. That sounds like a better model for SearXNG specifically.
One of the things that can get annoying about searxng is that often search engines will rate limit if a lot of people are using one searxng instance. Maybe a “federated” approach would be, if results are rate limited -> send query to another trusted searx instance -> receive the results and send back to user. That way, people can stick to their favorite searxng instance without having to manually change their instance if the search engines were rate limiting.