With Meta starting to actually implement ActivityPub, I think it would be a good idea to remind everyone of what they are most likely going to do.
With Meta starting to actually implement ActivityPub, I think it would be a good idea to remind everyone of what they are most likely going to do.
Oh, I read it when it came out back in June. Many times, as it kept being shared as an explanation of the first Threads backlash.
It’s full of incorrect assessments and false equivalences.
Threads doesn’t really have the volume (yet) to subsume ActivityPub. The process it describes for standards drifting towards the corporate actor doesn’t apply to ActivityPub, which is engineered from the ground up to support multiple apps with differnent functionality (hence me writing this in Kbin and others reading it in Lemmy and being able to link it and follow it from Mastodon), the article only acknowledges that XMPP survived and kept on going at the very end as a throwaway and doesn’t justify how it “never recovered” and, like I said, it doesn’t acknowledge the real reasons Talk and every Google successor to Talk struggled and collapsed.
So yes, I read it. Past the headline and everything. I just didn’t take it at face value. This piece keeps getting shared because XMPP wasn’t ever that big to begin with, so this sounds erudite and informed while the similar arguments being made at the time about SMTP and RSS were more obviously identifiable as being wrong for the same reasons.
I mean that’s basically what every protocol is. ActivityPub abstracts concepts, that apps implement in their own way (for example the concept of group). If you manage to deliver changes, even improvements, to the protocol, apps need to keep up and comply with it. This is what means “drifting towards the corporate actor”. I propose changes to the protocol to a rate that only me (the corporate actor) can keep up with. This way only my users will have certain features and eventually some apps will become incompatible with the recent version(s) of the protocol.
That is already how ActivityPub apps work.
It’s also not what happened to XMPP and, interestingly, not what the article claims happened to XMPP, even. You’ll note in the postmortem about it the recollection is that Google was too slow to adopt features and fix bugs, not the other way around.
I guess once you get enough confirmation bias in play you can embrace, expand and extinguish both by doing that and the opposite of that.
You still fall behind on compatibility with the original protocol. Doesn’t matter if you pull up or down, it still breaks compatibilty.
It absolutely matters under ActivityPub because, as I said earlier, it comes down to the client to manage the incoming packets. If Meta is out of date with the protocol but the rest of the federation is not (and retains backwards compatibility at all), then everybody else gets nicely formatted but feature-limited Meta content and they get garbled stuff.
It’s only relevant if we get garbled stuff and they get nicely formatted content. Which should be entirely avoidable if they “pull down”.
So no, not the same. And crucially people are still misquoting the article and the article is still misrepresenting the so-called “EEE” strategy.
The difference here is that, one, people are more aware now than they were back then (privacy wasn’t as big an issue then as it is now, thus people are more aware and are on the Fediverse for a reason), two, now the Fediverse has the upper hand (because of Mastodon mostly… they are somewhat of a player in the social media market), three, devs won’t allign with Meta’s moral compass just because it’s Meta (like it was with Google back then… people actually believed that company’s slogan back then).
So, what might have worked back then, probably won’t now, but it’s still good to approach Meta with caution.
Huh. I was just saying up here that I don’t think anybody genuinely believes the fediverse is a Meta competitor, but… guess I was wrong.
Mastodon does not have the upper hand by any metric. Threads alone has an order of magnitude more active users than the entire fediverse and Meta has multiple platforms with billions of users (and have signaled that they want Threads to reach that size).
You can absolutely argue that ActivityPub is a tech trendsetter and has an edge over BlueSky in that it’s already up and running. You can’t seriously argue that Mastodon or the fediverse are a threat, a competitor or have an advantage over Threads or Meta. One of the biggest hints that Meta isn’t going for “EEE” here is that it’s probably not worth the effort.
Not a competitor, that’s the corps view on things (the fediverse taking a piece of it’s cake, us not looking at ads and not playing stupid games on their platforms).
It still shows up in metrics and market share (not on every chart/pie, but still). What I meant was that it can be taken as a serious player by some. I don’t think it really is, but some people do.
And by having the upper hand, I meant as in being more advanced and in it’s adolescent stage, not in it’s infancy (which wasn’t the case with XMPP… maybe it wasn’t in it’s infancy, but it barely reached puberty). My point was that people on Mastodon, devs and admins, know exactly what they like and you can’t really push them around or try and lour them into some scheme, like flushing down millions into Mastodon development (which will put them in their pocket). We’ve seen this tactic with other companies (Mozilla as the most prominent example) and we know exactly where it leads. This wasn’t the case back then, people generally trusted IT companies, they really thought most of them cared about the users. Sure, make a few bucks here and there, but in general, just take care of the users and business as a second thing. Of course, we learned later on that that was never the plan, at all, but it was too late by then.
They do the integration for a reason… what that reason might be, I have no idea… might be malicious, might not be. In any case, even if they truly have the best intents for their users (which I seriously doubt) and the Fediverse (which I also seriously doubt), that doesn’t mean that the product of those good willed intentions can’t be taken to another level, i.e. used to do bad things. Remember, the dynamite wasn’t invented to be used in bombs.
I swear, I’m so tired of naive takes about “good” and “bad” corporations.
Corporations are corporations. They are groups of people legally mandated to make money for their shareholders. They’re not individuals.
So yeah, I’m fairly confident that them taking steps towards joining ActivityPub is some mix of high ranking people thnking interoperability is cool, some other high ranking people thinking that may smooth over what seems like an immediate future full of legal challenges, particularly in Europe and some other people thinking that as long as all the newcomers to the Twitter corpse party are interoperable they can flex their superior resources and development.
Because that’s how groups of people behave.
But I’m also very confident that nobody looked at the rounding error that is the fediverse userbase, disproportionally made up of FOSS true believers and fringe infosec nerds and went “we need to plot their demise”. That’s not a thing that groups of people concerned with building userbases in the billions talk about.
This is a core problem of distributed systems though. Signal even cites this as their reason to not federate with anyone.
Once you get decentralization going you need everyone to stay kind of up to date or stuff will just not work.
It is not. Discord’s protocol has been tailormade to suit Discord and the developers will not give a single thought about keeping it stable because only the Discord server&client are meant to use it.
This misses the point in my opinion. The point of a protocol is to establish a set of rules that need to be followed, that’s it. After this, it can be managed in many ways, it can be open or it can be closed, etc. The fact that ActivityPub is “engineered from the ground up to support multiple apps with different functionality” it’s because ActivityPub is an open protocol. Every protocol is designed to support whoever implements it. This doesn’t have any inherent “the protocol (changes) will suit everyone” or “everyone will be able to keep up with it” property, though. If changes to a protocol happen very fast, apps that are compatible today - and can be compatible tomorrow too - still need to implemented those changes, or at some point they will not be compliant anymore. This is not because the protocol loses the property of supporting multiple apps, but because a protocol still needs to be implemented, which is responsibility of the consumers, which requires time.
So my point was to challenge OC perspective that since ActivityPub is designed to support multiple apps, then there is no risk that it gets messed up and breaks compatibility with those apps (because it’s generic) due to - in this case -Threads influence. This is just nonsense, in my opinion.