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