@Ads20000 Your interest and collaboration towards making people understand the proposal and the constraints we live under is certainly appreciated. The many exchanges here including the first few messages that go into some more depth about what we’re trying to achieve, should provide a good basis for conversations around the topic.
It’s also worth keeping in mind that this is not a one way avenue. Our plans are dynamic and we’re listening to feedback and doing our best to make sure we’re working on the most important problems, which means these plans can always change if other problems become more important, and we may end up working on federation sooner than I expect right now.
The main issue with federation, though, is that it’s not even a single time cost. It will slow us down significantly when doing many of the upcoming features which are on the pipeline. As you know since you’ve around for a while, there are so many things we’re working on right now, and so many other interesting features coming as soon as we can get a moment to work on them… We literally have multiple software vendors waiting for specific features to land so that they can transition their users to snaps. Meanwhile, federation wouldn’t change much the experience of any of the parties involved in the process… not for users, not for developers, and not even for the distributions that choose to ship snapd. It’s mainly about trust on who hosts the service, as you point out. That’s why our choice right now is to focus on that and push the federation problem to the future.
We won’t get everybody to agree with that view for sure, because perspectives are different, and everyone is entitled to a choice on how the future should look like, but I think we’re doing what’s best for the project and for the majority of people that care about such problems.