I really don’t like the tone of some parts of this. Some of it is good, like reassurances around the privacy measures that Mastodon instances take to protect user IPs.
The bit I most have an issue with specifically is the section on Embrace, Extend, Extinguish.
Well, even if Threads abandoned ActivityPub down the line, where we would end up is exactly where we are now. XMPP did not exist on its own outside of nerd circles, while ActivityPub enjoys the support and brand recognition of Mastodon.
I think this misses the point or dismisses of some of the fears around Embrace, Extend, Extinguish and jumps straight to the idea that Threads may abandon ActivityPub. I don’t think this is the concern, and my major concern is around the Extend part of the strategy.
Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the “simple” standard.
Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
ActivityPub implementation is already pretty heterogeneous which is both a strength and introduces some fragility into “The Federation”. We see this even between fediverse-centric platforms where certain interactions are supported or not supported. Right now, I can see a Mastodon account from a Lemmy interface but none of its posts. This is fine, because Lemmy is not Mastodon and its concerns are different and built around participation in communities; but it is a crack in the ActivityPub standard that’s exploitable.
Following the strategy, Meta can start developing its own Threads-specific features which Fediverse implementors can choose to implement or not. Different Fediverse software implementations will need to make a decision as to whether they implement certain features, just as they do now. Some may refuse point-blank, which is fine. But this "[creates] interoperability problems for customers who try to use the ‘simple’ standard.".
Recent posts from @[email protected] and the linked blog post from @[email protected] indicate that they are at least nominally on board with Meta’s involvement in the Fediverse and are devolving the responsibility of blocking interaction with Threads onto Admins and Users. It’s of course impossible to accurately predict the future, but to me that indicates that there may be willingness to develop Threads-friendly functionalities in the future, at least in Mastodon and Pixelfed codebases.
Certainly before the Reddit apocalypse, and arguably still now, Mastodon is seen as the flagship Fediverse platform. Eugene basically says it in his post:
while ActivityPub enjoys the support and brand recognition of Mastodon.
Again, fine. But that causes its own issues. This github issue highlights the concerns that diaspora* developers had over implementing ActivityPub as a federation protocol. In particular, this comment eloquently describes the heterogeneity of ActivityPub implementations. And also makes the following point, which I agree with:
The current modus operandi seems to be to just look at Mastodon and copy their implementation because that seems to be the only way to get something working. That, however, is not about supporting AP, it’s about supporting Mastodon’s dialect of AP, and their subset of that.
Mastodon is arguably a leader in the Fediverse space, and if Mastodon’s development trends towards supporting Meta’s extensions then everyone else may be inclined to keep up or risk losing some interoperability that users of their software have come to enjoy. Forking codebases doesn’t fix the issue; it just means there’s more implementations only supporting the “basic” implementation of the standard.
In terms of what it means for the average user on the Fediverse? Who knows. Joining instances not federated to Meta or refusing non-Meta features is definitely viable as a strategy.
For me personally, the major loss is the feeling that I’m in a space where there aren’t any major corporate players. I left those other platforms to seek community-run spaces where the software was a little janky and the servers sometimes crashed, but it was fine because They weren’t there. I feel that they’ve just barged back into my space now. I’ll probably get over it in time. I don’t use Mastodon and my Lemmy’ing is mostly limited to lemmygrad; but it’s still a little sad in the short-term.
I really don’t like the tone of some parts of this. Some of it is good, like reassurances around the privacy measures that Mastodon instances take to protect user IPs.
The bit I most have an issue with specifically is the section on Embrace, Extend, Extinguish.
I think this misses the point or dismisses of some of the fears around Embrace, Extend, Extinguish and jumps straight to the idea that Threads may abandon ActivityPub. I don’t think this is the concern, and my major concern is around the Extend part of the strategy.
Here’s the strategy, from the wikipedia page
ActivityPub implementation is already pretty heterogeneous which is both a strength and introduces some fragility into “The Federation”. We see this even between fediverse-centric platforms where certain interactions are supported or not supported. Right now, I can see a Mastodon account from a Lemmy interface but none of its posts. This is fine, because Lemmy is not Mastodon and its concerns are different and built around participation in communities; but it is a crack in the ActivityPub standard that’s exploitable.
Following the strategy, Meta can start developing its own Threads-specific features which Fediverse implementors can choose to implement or not. Different Fediverse software implementations will need to make a decision as to whether they implement certain features, just as they do now. Some may refuse point-blank, which is fine. But this "[creates] interoperability problems for customers who try to use the ‘simple’ standard.".
Recent posts from @[email protected] and the linked blog post from @[email protected] indicate that they are at least nominally on board with Meta’s involvement in the Fediverse and are devolving the responsibility of blocking interaction with Threads onto Admins and Users. It’s of course impossible to accurately predict the future, but to me that indicates that there may be willingness to develop Threads-friendly functionalities in the future, at least in Mastodon and Pixelfed codebases.
Certainly before the Reddit apocalypse, and arguably still now, Mastodon is seen as the flagship Fediverse platform. Eugene basically says it in his post:
Again, fine. But that causes its own issues. This github issue highlights the concerns that diaspora* developers had over implementing ActivityPub as a federation protocol. In particular, this comment eloquently describes the heterogeneity of ActivityPub implementations. And also makes the following point, which I agree with:
Mastodon is arguably a leader in the Fediverse space, and if Mastodon’s development trends towards supporting Meta’s extensions then everyone else may be inclined to keep up or risk losing some interoperability that users of their software have come to enjoy. Forking codebases doesn’t fix the issue; it just means there’s more implementations only supporting the “basic” implementation of the standard.
In terms of what it means for the average user on the Fediverse? Who knows. Joining instances not federated to Meta or refusing non-Meta features is definitely viable as a strategy.
For me personally, the major loss is the feeling that I’m in a space where there aren’t any major corporate players. I left those other platforms to seek community-run spaces where the software was a little janky and the servers sometimes crashed, but it was fine because They weren’t there. I feel that they’ve just barged back into my space now. I’ll probably get over it in time. I don’t use Mastodon and my Lemmy’ing is mostly limited to lemmygrad; but it’s still a little sad in the short-term.