ActivityPub perfectly suits Meta’s goals, I suspect, and here’s why:
With ActivityPub, the server manages your identity and data. So when you join Mastodon, for example, you are essentially entrusting management of your data to the server (“instance”) you join. As fediverse developer Ryan Barrett put it in a post this week, your ActivityPub “identity, data, and administration are all tied to your instance, for both technical and cultural reasons.” Among other things, this architecture enables your instance to make moderation decisions on your behalf. You’re still free to move to another instance, at any time and for whatever reason, but you can’t port your data (your posts and media) from one instance to another.
I mention all this because it plays right into Meta’s strengths. Meta will still control the identity layer even when it integrates with ActivityPub — and that’s immensely valuable when you’re the owner of Instagram’s social graph. Since Threads is also hosted on Meta’s servers, all your data is managed by Meta too.
There’s no way Meta would’ve wanted to join the AT Protocol or Solid, because in both cases they would potentially be handing over control of identity and at least some data to their users. As Barrett put it in a separate post: “One core difference between the fediverse and the AT Protocol seems to be that AT decouples many key building blocks — identity, moderation, ranking algorithms, even your own data to some degree — from your server.”
Threads will not be compelled to implement nomad-id, but as long as it exists in alternative AP instances it applies pressure.
+1 to wiki-fying / pulling in those items into here at least.
I also highly agree that Account Portability / Nomadic Identity / Export feature (and I know there’s some overlap with all three) would be incredibly important in the Fediverse’s relationship with Meta. Possibly the most important feature, honestly.
I propose that we approach this from two directions:
Lobby Threads to commit to providing Export functionality (specifically, exporting the profile, social graph, and posts), as well as supporting any relevant redirects (“this user has moved over there”…).
Focus on getting Export/Import/portability working on as many implementations in the Fediverse as possible, as a leverage for the above (and to set a good example).
Content licensing seems relevant. If not a hard protection, it’s at the very least a form of activism by giving me a way to explicitly say my content is not allowed for use in day farms, closed AI etc.
I think a good analogy for “reply control” is quote posts. It’s easy to implement quote posts in a client. So people have done it.
Comment control on apps is kind of “nasty” as it wouldn’t work across different apps.
People seem to lack the imagination necessary to just use a “#DonTComment” hashtag in the base post to indicate that comments should not be displayed.
This would work nicely across apps and not require any slow Mastodon changes.
I’m probably an awful person for suggesting the quick fix. The ActivityPub tech stack is just not ready for hard soluitons.
Also note that I think #NoReply is superior to #DonTComment. This is a dirty solution, in the sense that it adds technical debt. However, it is a solution that can be implemented without creating too much technical debt. It is clear that this is a “hack” of a “hack”, i.e. hashtags, and thus should be removed once better solutions are available.
Exactly: to get focus one these collective set of potential additions - that all solve for one very big use case of being a tighter ship for when Threads federates in with what I assume by that point will be 300 million users or more by that point - many of whom will be moderation issues. How to prevent abuse, how to empower users to fortify their own accounts and how to give admins a few more tools in the toolbox.