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)

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.

[–] MudMan@kbin.social 10 points 11 months ago (8 children)

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.

[–] 0x4E4F@sh.itjust.works 1 points 11 months ago (7 children)

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.

You still fall behind on compatibility with the original protocol. Doesn't matter if you pull up or down, it still breaks compatibilty.

[–] amki@feddit.de 2 points 11 months ago

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.

load more comments (6 replies)

load more comments (8 replies)