- cross-posted to:
- fediverse@lemmy.world
- cross-posted to:
- fediverse@lemmy.world
“Threads is deepening its ties to the fediverse, also known as the open social web, which powers services like X alternative Mastodon, Pixelfed, PeerTube, Flipboard and other apps. On Wednesday, Meta announced that users on Threads will be able to see fediverse replies on other posts besides their own. In addition, posts that originated through the Threads API, like those created via third-party apps and scheduling services, will now be syndicated to the fediverse. The latter had previously been announced via an in-app message informing users that API posts would be shared to the fediverse starting on August 28.”
I don’t think that’s how it works and it would likely not be legal. By explicitly blocking Threads, you make a big statement about not wanting your instance’s posts to show up there. Also from a technical standpoint, I don’t think a “middle-man” instance will push posts from another instance to a third one. You’d have to explicitly scrape data that’s not available via the API. Please correct me if I’m wrong.
@copygirl @Dirk yes, I also get the feeling this would not work in a compliant setup but it seems like a good idea to test this in e.g. a federation test suite.
Maybe @evanprodromou would know how this should work, or would know of someone who might be testing this kind of scenario.
The fediverse is too new and niche to say that with certainty.
The legality is likely untested and certainly not enforced by pubspec yet.
I don’t know enough to speak to the technicalities with certainty, but my surface level understanding is that that is exactly how it works, and it is one of the known flaws of the fediverse as it currently exists.
You might be making a statement, but server B is just a node and, frankly, doesn’t care. If you federate with them, you federate with everyone they federate with as well.
It’s uncomfortably like an STD in that regard.