External repositories

snapd
81

Those features upcoming look great. Be sure to get to federation at some point though. :slight_smile:

Another thing I would like to see would be a more detailed introduction to Snaps from a distribution owner’s (or team’s) perspective. Tell them the specific reasons why Snap is superior to Deb/RPM/Flatpak, give links to the pages which say how Snaps work, cover the issue of Federation as it stands right now and how it will (hopefully) be in the future, and also cover things like snap sizes and other now-known-to-be myths surrounding Snap.

In other words, an Introduction to Snap for a Distribution Team’s perspective.

82

Epochs, Base Snaps, Layouts, Multi-User, Multi-Versions, Snapshots, Statistics, Health Checks, Staged Deployments… they are all genius innovations I am proud to see Snap developing. Where exactly is the roadmap? Like, is there a public list somewhere of all that is coming (that I am not finding), or is it scattered all over the place?

1 Like
83

@Ads2000 Yeah, I haven’t managed to find the time to finish the proposal and writing it down here in the forum yet, but I think there’s a pretty convenient way to implement that both in terms of usability and coding which will allow us to have it pretty soon.

@G.S.1 It’s a bit scattered right now. The topic from the last design sprint linked above gives a hint of what’s coming, but we really need a more clear roadmap topic here in the forum. I’ll put that on my own TODO list as well.

2 Likes
84

Another aspect of the external repositories problem that AFAIK has not been addressed so far is the ability to run mirrors. As the collection of FOSS available in snap form grows, various organisations, ISPs or even individuals should be able to host their own mirrors, like they can do today for any distro archive. If the intention is to gradually move Ubuntu from relying mainly on debs to relying mainly on snaps, then not being able to mirror and cache the distro is a major roadblock.

85

From the Canonical/Ubuntu point of view, I’d be shocked if they weren’t using a commercial CDN like Akamai. The rest of us can’t afford such a thing, but that could be how content delivery is done for the store.

1 Like
86

This thread may be of interest, seems even Ubuntu developers would like the ability to run mirrors, as you put it :stuck_out_tongue:

87

Yes, all bulk content is delivered by CDNs.

88

This is going to be a recurring issue for snappy in the community :’( E.g. https://disqus.com/home/discussion/omgubuntu/ahoy_flathub_website_now_lets_you_install_apps/#comment-3506044938

(But yes of course Niemeyer is right there’s so much else to work on which app developers want snappy to work on, I just get sad when I see these comments around)

Apologies for bumping the thread, I realized afterwards that I should probably have not made this comment but you can’t really delete comments properly on Discourse. Argh and edits bump the thread too, really? :confused:

89

@niemeyer You repeatedly say that there is no such thing as the “Ubuntu Store”, just the “Snap Store”. However, everything I find suggests the opposite:

Technically, most of these are for Ubuntu Core, but that uses the same store anyway. Could you please clarify on how this is not a “Ubuntu Store”, just a “Snap Store”?

Also, the current Snap Store is proprietary. For the sake of extending Snap to other distributions, it would probably be a good idea to try to make the Snap Store back-end (the official one) open source. I am actually really surprised that KDE Neon chose to use Snap, because it says on their website that they refused to use GitHub (GitHub!!!) because it wasn’t open source and that conflicted with their philosophy.

90

Here is a modified idea of mine for the future: The simplest way to federation (in my humble opinion) would be giving every major distribution their own branded store, and make it open source (or at least as FOSS as possible) so said distribution can use their own server, and give every store the ability to “borrow” from each other.

This is similar to my first idea, but a little different and far more detailed.

  • Stores “borrow” assets from other distributions who they “trust”. Every store has a list of other distributions labelled as “trustworthy”. Ubuntu Store will “trust” Fedora, and Fedora (could, in return) “trust” Ubuntu. It doesn’t have to be two-ways, but could theoretically be a one-way “trust”. “Trusts” are optional, and are the Store’s choice to add.

Example: There are two stores, Ubuntu, Fedora, SUSE. Ubuntu and Fedora decide to trust each other, but only Fedora trusts SUSE while Ubuntu doesn’t. In this case:

-Fedora Store shows snaps from Ubuntu, Fedora, and SUSE
-Ubuntu Store shows snaps only from Ubuntu and Fedora
-SUSE Store shows snaps only from the SUSE store, because they haven’t decided to trust anyone yet. It doesn’t matter that Fedora trusts them, because they don’t trust them back.

  • If a distribution is listed as “trusted”, the packages from that store appear in your store as well. So if Ubuntu is “trusted” on Fedora’s store, the Fedora storefront shows packages for Ubuntu and Fedora. Packages hosted on Ubuntu’s infrastructure get downloaded from Ubuntu, and Ubuntu gets the money for paid snaps. If a Snap is hosted on the Fedora store and Ubuntu’s store “trusts” Fedora, both Ubuntu and Fedora will see the Snap, but Fedora gets paid because they ran the servers and Ubuntu is only listing the Snaps they have.

Example: Ubuntu and Fedora trust each other. User goes and decides to download “Blender” from Fedora’s store. The Fedora Store finds that it is “trusting” the Ubuntu Store and that the only “Blender” snap is from the Ubuntu Store, so the snap is downloaded from Ubuntu.

Later, a different user logs into Ubuntu again, and downloads a $5 Blender add-on. This add-on is only available through the Fedora store, but Ubuntu “trusts” Fedora, thus it appears in the Ubuntu store. The guy fills out his credit card info, processes payment, and Ubuntu’s SSO talks to Fedora’s SSO, and buys the Snap for him there. The snap is then downloaded from Fedora, and Fedora pockets the 30% cut.

Later, guy #3 decides to download a $10 game. This game is available on both Ubuntu and Fedora. He finds it on the Fedora store, so it is downloaded from Fedora’s servers and Fedora gets paid, even though it was also available through Ubuntu.

  • Developers may want to use other stores than Ubuntu. To encourage this, allow “linking” accounts. Snap should have a universal SSO option which works with whoever is providing it. This way, a developer could link his “Fedora Snap Store” and “Ubuntu Snap Store” accounts together, causing his Snap to be hosted on both servers. If a Snap is on two or more Snap Stores, the snap store the user downloads it from gets first priority for download.

See examples above.

  • To prevent conflicts, most stores will initialize “trusting” each other, like chicken-egg. Example: Fedora store starts with “trusting” Ubuntu and starts with no snaps, causing the Fedora store to hold all “Ubuntu” snaps. Again, this prevents conflicts because it started on top of another store. There would also be a conflict checker for when stores decide to “trust” each other. The only way a conflict would really happen would be if another store held a ton of snaps, then decided to agree with another store which also had a ton of snaps, causing duplicates. If a Store started with no snaps, “trusting” another Store, conflicts shouldn’t happen.

  • Also to prevent conflicts (and power struggles), the stores should be able to trust one another, but “turn off” specific packages or apps from appearing from other stores. This is so that if one store uploads a controversial package, the other stores can say “I trust you, but I just don’t trust that one thing.”

91

If you look further down the history line, you will find references to it being a phone store too. A lot has changed since those early days, and I won’t be surprised if you find documentation and even conversations of those early days. We need to clean that up, but meanwhile the details provided in this topic reflects up to date information.

92

Okay.

Here are a few more questions (maybe they were answered elsewhere, but still wondering):

  1. Is it Canonical’s wish to make the Snap Store back end open source eventually, or keep it closed source as it is now?
  2. Would it almost make more sense to start something like the “Snap Package Foundation” and do governance that way (with Canonical as a major donor) over leaving Canonical in charge (mainly, to show that snap really is distribution-neutral)?
1 Like
93

Sounds tricky to organise, given that Canonical is paying for, as far as I know, all the main snapd and snapcraft maintainers as well as the people who run the store (that’s a lot of wages and a lot of cash), losing control of that store probably seems risky to them. And, like Niemeyer said about federation, it would take time and effort to get right and they don’t want to prioritize that when they have developers (as opposed to merely ordinary users like us) who really badly want specific features to be able to roll out their snaps.

Despite the fact it probably won’t happen, I agree with you that that solution would be ideal.

2 Likes
94

You can read the news. The “open source snap store” implementation is gone. I remember trying it a month ago and I couldn’t get it to work (as well as trying several forks without success).

Also, is it on Canonical’s roadmap to one day open source the real Snap Store?

1 Like
95

I played around a little with a really simple store implementation with the scope “just install a snap”. I was able to self host the hello world snap (downloaded from the real store, so it was signed), the problem was the hard coded keys in the source code prevented me to sign my own packages with a by-me trusted root.

I did this because we where considering to use snaps at work, but we choose not to do so when we realized that we had to maintain both a patched snapd and write our own store… a little to much work so back to debs.

I chatted a little about this on IRC 1-2 weeks ago and it sounded like some form of an on premises store offering was considered for next year, not sure if it’s open source or not but at least that open up the possibility that the code supports several stores.

For me I would be happy if just the keys was moved out of the binary so they where easy to replace. Then I could just resign all snaps that I like to host with my own keys.

I understand why this is not prioritized at the moment, and I’m fine with that, but I hope that we will see some solution next year.

6 Likes
96

I can’t actually find the documentation to which you allude here. @ogra could you share the link to the documentation or specification which details the API on both sides?

97

i think this is https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex

which, despite being falsely named, still applies (someone from the store team please correct me here if i’m wrong)

98

As far as I know, this is not completely valid anymore. The open source snapstore implemented that specification and it doesn’t work with recent versions of snapd.

1 Like
99

I’m not on the Snap Store team, however:

1 Like
100

You say that everything is now the “Snap Store.” However, why do I need a Ubuntu SSO account to use it? Unless that will change too.

1 Like