It’s excruciatingly obnoxious to have to rely on third party sources for what should be a first-party feature.
Like, I select all and then search a query. “Oh no, nobody on your server used a third party service to find it, so you won’t see it here.”
Like, how short-sighted is that, really? If I search for a string in the ‘all’ servers, I should have a list of ‘all’ the servers containing that string.
It’s a really simple concept. Not sure why this post even has to be made, but I’m wondering if there’s something I can do to make these ‘features’ more intuitive.
Federation isn’t opt-in though. It would be VERY easy to spin up a bunch of instances with millions or billions of fake communities and use them to DDOS a server’s search function.
Searching current active subscriptions helps mitigate that vector a little.
I would suggest that instances should have settings that allow them to decide whether to “advertise” a community list. With configurable settings like "all, “most active”, “top X”, or even a manually maintained list depending on the admins and instances preferences.
Then your home instance, when searching, should have it’s own settings to decide what results it’s going to ping other servers for. Big/popular/high confidence instances can have an open all/all relationship, while you might query only the top 10 communities from unknown or new instances to handle the scenario you describe.
Federation can be binary yes/no but there should be room to add more logic around enabling search on communities from your instance and controlling the search results from other instances. I don’t think the two are mutually exclusive, unless I fundamentally misunderstand how federation works!
I… don’t think you know what ddossing means but okay.
Would it really be very easy? Especially considering once instances find your doing that, they just block you? Would it be worth people’s time?
Is there any way around this, perhaps querying a global repository of federated instances and sorting them by popularity?
In all honesty, you don’t have a point. If you did, third-party services already wouldn’t offer this. Seeing as they can, it’s clearly possible.
Sorry you’re right that I wasn’t being precise with my terminology. It’s not a DDOS but it could be used to slow down targeted features, take up some HTTP connections, inflate the target’s DB, and waste CPU cycles, so it shares some characteristics of one.
In general, you want to be very very careful of implementing features that allow untrusted parties to supply potentially unbounded resources to your server.
And yeah, it would be trivial to write a set of scripts that pretend to be a lemmy instance and supply an endless number of fake communities to the target server. The nice thing about this attack vector is that it’s also not bound by the normal rate limiting since it’s the target server making the requests. There are definitely a bunch of ways lemmy could mitigate such an attack, but the current approach of “list communities current users are subscribed to” seems like a decent first approach.