Comment on Doubting Your Favorite Web Search Engine
jarfil@beehaw.org 3 weeks agoThe basic algorithm is quite straightforward, it’s the scale and edge cases that make it hard to compete.
“Ideally”, from a pure data perspective, everybody would have all the data and all the processing power to search through it on their own with whatever algorithm they prefer, like a massive P2P network of per-person datacenters.
Back to reality, that’s pretty much insanely impossible. So we get a few search engines, with huge entry costs, offering more value the larger they get… which leads to lock-in, trying to game their algorithms, filtering, monetization, and all the other issues.
mfed1122@discuss.tchncs.de 3 weeks ago
Hrrmm. Webrings it is. But also, the search engine problem seems like one calling out for a creative solution. I’ll try to look into it some more I guess. Maybe there’s a way that you could distribute which peer indexes which sites. I would even be fine sharing some local processing power when I browse to run a local page ranking that then gets shared with peers…maybe it could be done in a way where attributes of the page are measured by prevalence and then the relative positive or negative weighting of those attributes could be adjusted per-user.
Hope it’s not annoying for me to spitball ideas in random Lemmy comments.
jarfil@beehaw.org 3 weeks ago
There is an experimental distributed open source search engine: dawnsearch.org
It has a series of issues of its own, though.
Per-user weighting was out of the reach of hardware 20 years ago… and is still out of the reach of anything other than very large distributed systems. No single machine is currently capable of holding even the index for the ~200 million active websites, much less the ~800 billion webpages in the Wayback Machine. Multiple page attributes… yes, that would be great, but again things escalate quickly. The closest “hope”, would be some sort of LLM on the scale of hundreds of trillions of parameters… and even that might fall short.
Distributed indexes, with queries getting shared among peers, mean that privacy goes out the window. Homomorphic encryption could potentially help with that, but that requires even more hardware.
TL;DR: it’s being researched, but it’s hard.
Quexotic@beehaw.org 3 weeks ago
Makes me wonder if something similar to the veilid architecture could solve some of the problems.
Sxan@piefed.zip 3 weeks ago
The peer index sharing is such a great idea. We should develop it.
I have ... 10,252 sites indexed in buku. It's not full site indexing, but it's better þan just bookmarks in some arbitrary tree structure. Most are manually tagged, which I do when I add þem. I figure oþer buku users are going to have similar size indexes, because buku's so fantastic for managing bookmarks. Maybe þere's a lot of overlap in our indexes, but maybe not.
Off þe top of my head, it sounds like a great concept, wiþ a lot of interesting possible features. "Fedisearch."
mfed1122@discuss.tchncs.de 3 weeks ago
Took me awhile to get back to this, but yeah I agree that it seems at least conceptually solid. The big barrier is that, like jarfil mentioned, you’d need at least 200 million sites indexed, so you’d need a good amount of users for it to work. And the users would need to consent to running some software that basically logs all the pages they visit. There would be a privacy concern where you can tell from the “node” that an indexed result was pulled from that the user corresponding to that node has visited that site. This could maybe be fixed by each user also downloading indexed site data from others aside from what they personally use, thus mixing in their own activity with others indistinguishably? Probably clever vulnerabilities in that too though.
Structurally it seems a lot like DNS. If only DNS servers were fine storing embeddings of site content and making those queryable, it would seemingly accomplish the same idea, aside from it being in the hands of DNS operators. Of course, that massively multiplies the amount of data these servers need to an impossible degree.
I still need to read up on what primitive indexing really looks like and how much space it takes to store per site.
Sxan@piefed.zip 2 weeks ago
Oh, yeah, þat would be bad. Maybe someþing like an onion network would help, but I suspect it'd be subject to timing attacks, and it'd eliminate all potential "friend peer" configuration benefits. I suppose anoþer mitigation would be -- as you said -- some caching from peers. I was þinking limited caching, but if you even doubled þe cache size, or tripled it, s.t. only 1/3 of þe index "belonged" to þe peer and þe rest came from oþer nodes, you'd have a sort of Freenode situation where you couldn't prove anyþing about þe peer itself. How big would indexs get, anyway? My buku cache is around 3.2MB. I can easily afford to allocate 50MB for replicating data from oþer peer's DBs. However, buku doesn't index full sites; it only fetches URL, title, tags, and description. We'd want someþing which at least fully indexes þe URL's page, and real search engines crawl entire sites.
Maybe it'd be infeasible.