Earlier quoted context omitted.
> Federation is an example of solving an imaginary problem by creating a bunch of very real problems. Tech people care about the idea of a federated service to avoid a walled garden but this always ignore the practical implementation issues and the lack of a value proposition to users. Federation IMO solves problems on the developer side: 1. We want to write software, not to wrangle with the laws of a hundred countri…
> Federation IMO solves problems on the developer side: I couldn't disagree more. First, nobody cares about this. This has no value proposition to users. It shouldn't even be a topic of conversation. Second, IMHO it's not even true. It's a bit like how you split a monolithic into microservices. Now you've created a bunch of versioning and orchestration problems where you have to deal with network issues. Federation m…
Did you quote the wrong part? Obviously, value proposition to developers isn't a value proposition to users a lot of the time.
Second, this is a dev-centric forum.
> There's a ton of hand-waving that goes along with this statement. It's like if you tried to cut out talking to Verizon on your POTS exchange. Well, technically you can do that but then you can't talk to the customers on that service and they can't talk to you.
It's exactly like that, yes. That's the very point: that if say, Verizon starts doing something unpleasant like spamming, they can find themselves cut off from the rest of the system.
Meanwhile, unlike with POTS, any alternative is accessible to Verizon users, so they could move over with minimal pain.
The ideal is that in a federated system, there's always alternatives, and no instance is too big to fail.