3 ms·
As I understand it, the "federate and slurp data" isn't something that can be prevented. Deciding to federate means accepting content from that other site. A
by shagie 3y ago
As I understand it, the "federate and slurp data" isn't something that can be prevented.
Deciding to federate means accepting content from that other site. A mastodon instance federating with Threads would mean that Threads content would be visible on that instance.
However, if an instance decides to not federate with Threads, Threads can still get the data from the instance.
With the permisivity of the protocol, Meta (and anyone) can consume any ActivityPub data they want.
Compare this to email. A mail server can block incoming mail from some other mail server (e.g. a known spam farm). However, mail servers don't block people who have email accounts on their servers from sending mail to abuse@spammy.mail.server
Trying to change it so that federated content only goes out to pre-approved sites (because face it - if threads.meta.com is blocked it is would be trivial to spin up notthreads.notmeta.com and consume the same data) would fracture the fediverse and make small sites difficult to federate with... and lead to very much what we currently see with email - you can't stand up your own email server and send mail to gmail... which is very much what federation is supposed to not be about.
- nightpool 3y ago> With the permisivity of the protocol, Meta (and anyone) can consume any ActivityPub data they want. Well, in practice it's pretty easy to block Facebook-range IP addresses at the firewall level, and then there's no other way for Facebook to get (authenticated) information about posts/users. "Will admins end up going that far" is an open question, but it's not like Facebook is going to be renting out residential IPs and forging user-agents to get around these types of bans.
- shagie 3y agoIf all they are after is the data inbound, spinning up something to federate, consume, and forward as a relay on AWS or another cloud host is similarly easy and anonymous - it is exactly the same way that many small instances are hosted. Trying to prevent Meta from being able to consume ActivityPub content is an arms race that Meta would win with the collateral damage being every small instance of an ActivityPub application. That collateral damage would be inflicted by other ActivityPub instances rather than Meta itself.
- jeromegv 3y agoI don't quite understand your point. Is that within the context of Meta wanting to ingest data from Mastodon in order to train their AI or whatever data they want to ingest? Of course they can do that, setup their own instance or their own cloud, and ingest a lot of the posts coming out of the main Mastodon instances. Any company can do it, and it has nothing to do with Threads being on ActivityPub. You don't even need to go that far! You can add .rss to any user on Mastodon and get a fully public feed of their activity (if they didn't put their profile private) Or are you arguing that Meta can ingest Mastodon posts within Threads without the consent of Mastodon instances? Because that's quite unlikely, they said they want to be good citizen of the federation. If a server is not federating with them, then they will just obey the block and won't go around those blocks to show content in Threads even if the users/instances decided not to be federated with Threads
- dustyharddrive 3y ago> With the permisivity of the protocol, Meta (and anyone) can consume any ActivityPub data they want. This is the common case but AFAIK doesn’t have to be true. Mastodon lets users make their AP outboxes private. Followers can be screened before posts are sent to their instances.