Honestly one needs to look at the economic ensentives in order to understand metas goals.
Meta does not make any money from content on the federverse. Therefore, they have no reason to support its growth or future. In fact I would go as far as to say that they actually are going to try and EEE.
They aren’t going to try to EEE. ActivityPub was just an easy protocall to build off of quickly. They don’t care about the fediverse. They have almost zero incentive to waste effort trying to destroy it, plus it’s open source, so worst case we just fork it and move on.
EEE means embrace, extend, extenguish. It’s to say they’ll start using it, extend it so they are required to continue using it, then stop supporting it or actively kill it. It has nothing to do with federation, whether they do or don’t.
I know that, but if that’s not the goal, then what else do they hope to achieve by implementing ActivityPub? It means they plan to federate with the larger fediverse, and you can bet that there’s a carefully calculated business reasoning behind it.
They likely used it because most of the work is already done. They could quickly turn around a new app as they notice Twitter fucking up, rather than starting from scratch. It already exists, works, and is tested.
You’re not getting my point - if federation wasn’t the goal, they wouldn’t even need anything like ActivityPub. It’s a protocol to allow different servers to talk to each other in a way that is just not necessary and way too much overhead if you’re planning to have an insular solution controlled by just a single entity anyway. Picking it as the protocol for internal-only communication between your own servers would simply be a very questionable architectural choice, Meta’s Engineers know better than that. Threads already works without supporting ActivityPub, so it’s obviously not needed for making the app run. Them also working on supporting ActivityPub is just creating an additional, public interface in order to connect to the fediverse, which they otherwise simply wouldn’t need to do.
Just noticed another possible confusion: ActivityPub is just a protocol, a definition of how servers can talk to each other. There’s no ready-made implementation that Meta could be using to get a headstart, they are most definitely developing their own implementation of it. So even if they were actually using it without wanting to federate, the only thing they’d be saving on is designing their own protocol, but that’s not really beneficial because then they’ll have to deal with a protocol that wasn’t actually made for their use case and according to their specific needs.
Honestly one needs to look at the economic ensentives in order to understand metas goals.
Meta does not make any money from content on the federverse. Therefore, they have no reason to support its growth or future. In fact I would go as far as to say that they actually are going to try and EEE.
What do you mean by EEE?
https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
They aren’t going to try to EEE. ActivityPub was just an easy protocall to build off of quickly. They don’t care about the fediverse. They have almost zero incentive to waste effort trying to destroy it, plus it’s open source, so worst case we just fork it and move on.
If they didn’t want to federate, they wouldnt have a need for ActivityPub or any kind of similar protocol.
EEE means embrace, extend, extenguish. It’s to say they’ll start using it, extend it so they are required to continue using it, then stop supporting it or actively kill it. It has nothing to do with federation, whether they do or don’t.
I know that, but if that’s not the goal, then what else do they hope to achieve by implementing ActivityPub? It means they plan to federate with the larger fediverse, and you can bet that there’s a carefully calculated business reasoning behind it.
They likely used it because most of the work is already done. They could quickly turn around a new app as they notice Twitter fucking up, rather than starting from scratch. It already exists, works, and is tested.
You’re not getting my point - if federation wasn’t the goal, they wouldn’t even need anything like ActivityPub. It’s a protocol to allow different servers to talk to each other in a way that is just not necessary and way too much overhead if you’re planning to have an insular solution controlled by just a single entity anyway. Picking it as the protocol for internal-only communication between your own servers would simply be a very questionable architectural choice, Meta’s Engineers know better than that. Threads already works without supporting ActivityPub, so it’s obviously not needed for making the app run. Them also working on supporting ActivityPub is just creating an additional, public interface in order to connect to the fediverse, which they otherwise simply wouldn’t need to do.
Just noticed another possible confusion: ActivityPub is just a protocol, a definition of how servers can talk to each other. There’s no ready-made implementation that Meta could be using to get a headstart, they are most definitely developing their own implementation of it. So even if they were actually using it without wanting to federate, the only thing they’d be saving on is designing their own protocol, but that’s not really beneficial because then they’ll have to deal with a protocol that wasn’t actually made for their use case and according to their specific needs.