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.
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.