(Ethos) Snaps

App Formats

Flatpak vs Snaps

Flatpak

Pros:

• Open-source community with more people involved in decisions.
• Decentralized repositories.
• Built on top of similar tech stack, like OSTree.

Cons:

• finish-args for sandbox require too much knowledge of Linux internals for regular developer.
• Distribution channel is tied with sandbox. No way to distribute non-sandboxed apps when a sandbox doesn't make sense or has a poor user experience. VSCode snap has this problem.
• Integration requires lots of C.

Snaps

Pros:

• Format seems friendly. Has plugs for Electron, Flutter, etc...
• Ability to opt out of sandbox when it doesn't make sense.
• Huge official support from core applications. Microsoft, Spotify, Slack, JetBrains, Doist, etc...
• Integration can use HTTP (local to your computer) for most functions

Cons:

• Canonical controls a lot of decisions.
• App backend is proprietary.
• No (initial) way to curate selection. If using Snap Store, users have no way of knowing if the app has been tested on Bloom, works on Bloom period bc Wayland, or integrates with system features.

Solution

Using Snap + custom tooling seems like the best way to have a "just works" experience. We want users to be able to get Slack, VSCode, and Spotify officially without weird work. We also want to curate the selection.

We can use snapd and not Snap Store, which can obviously be sideloaded from command line.

Market:

• Frontend app written in Flutter.
• Communicates with snapd via HTTP protocol. snapd.dart
• Reads from a list of Snap packages known to work on Bloom. Also has "Featured" sections, etc... The recipes will be hosted on GitHub so users may contribute.
  • This can be downloaded as part of updated. We can either have a BSON format, or do something like an embedded SQLite repository?

To think about:

• Are we allowed to scrape snapd images, descriptions, etc for a more-curated searching experience? Is there any TOS that violates?