Using ATProto for AppImage distribution

[MadSpindel]

I was looking into AppImage and really liked the concept of it. The issue I see is how to make it more user-friendly, especially around the discoverability and distribution of AppImages. I found AppImageHub.com but it’s not clear who is behind it or if the apps are even safe to download. For what it’s worth, all of the applications could be malware from the way I see it.

So I started to look into solutions for a trusted and decentralized way of distributing AppImages. First, I found a proposal of using Ethereum smart contracts and storing the applications on IPFS, but I have no experience with either of them so continued the search. Somehow I started to think about Bluesky and its goal of a decentralized (yet centralized?) Twitter. I started to read about the ATProto protocol that’s behind Bluesky and it started to click to me. Bluesky, or rather ATProto, could be used to distribute and discover AppImages!

The way ATProto works (how I understand it) is that each participant has a Decentralized Identifier (DID) and can publish whatever to their Personal Data Server (could be Bluesky or self-hosted) and then Bluesky (or other relays) could index the data and publish updates to what’s called a “Firehose” which is like a big bus/websocket of all events that apps can subscribe to.

I’ve not made any proof of concept yet, but I think the following will work. We need to define a schema (ATProto Lexicon) for an AppImage (and that’s what I would like to discuss here). Then, as an example, @steampowered.com could publish Steam as an AppImage on their Bluesky profile. AppImage package managers and app stores can listen for new appimage releases from the Bluesky websocket and update their feeds accordingly.

I’m thinking about creating a feed and package manager with only official DIDs (as in official DNS domain handles like steampowered.com etc.) but other package managers/stores might want to include everything to create uncensored feeds of AppImages. It will be competition and innovation on who can create the best feeds of AppImages, I hope.

We can also create schemas for CVEs, user comments and ratings etc, which will also be decentralized with ATProto. You can imagine using something like appimaged to listen for new AppImage releases and autoupdate in realtime, or blocking AppImage from running based on security research. Perhaps even curated firejail security profiles etc. Endless possibilities.

This is already too long but I would like to have some opinions/feedback about this. Something I also would like to discuss is if we can add DID or something to the AppImage specification to make it possible to perform a reverse lookup on a standalone file (to find the creator, CVEs, labeled as malware etc.).

[probonopd]

Very interesting @MadSpindel. I have been looking for a way to distribute not only traffic but also trust in a peer to peer way for quite some time. Do you think you would know how to do this?

[MadSpindel]

@probonopd ATProto is still new to me, but the goal is absolutely to develop an end-to-end solution.

Some things to do:

• Define AppImage Lexicon
• Simple CLI to publish AppImage to PDS
• Simple bsky.network websocket listener to save new AppImage releases to a database
• Generate a feed from db
• Package Manager CLI to install AppImage from the feed

I think the difficult part is actually to agree on the AppImage Lexicon schema, e.g. should app permissions be part of it or a different lexicon?

Also, maybe I should add that the AppImage itself will not be hosted on ATProto, only the "manifest" with a download URL to the AppImage.

[probonopd]

What is a "lexicon"?

[MadSpindel]

It's just a fancy name for custom schema.

Why create a schema?
Schemas help other applications understand the data your app is creating. By publishing your schemas, you make it easier for other application authors to publish data in a format your app will recognize and handle.

[probonopd]

So, something like "application name, AppImage size in bytes, version, checksum, license,..."?

[MadSpindel]

So, something like "application name, AppImage size in bytes, version, checksum, license,..."?

Correct! Maybe we should have two schemas, one for application, and one for releases (of the application).

[probonopd]

Maybe a combination of the keys used in XDG desktop files and AppStream metainfo fields might do? That's what we are using for https://github.com/AppImage/appimage.github.io/tree/master/database from which we extract https://github.com/AppImage/appimage.github.io/tree/master/apps...

[MadSpindel]

Sounds reasonable. I'll read through them.

Another thing to discuss: Possible to include perhaps Decentralized Identifier within the AppImage spec somehow? I'm thinking something like, if I download "Spotify" from e.g. appimagehub.com, I want to verify that it's actually made by Spotify and not some random person. If DID is included in the file, a verifier could check the sha256 against the DID (@spotify.com) to see if they have published any release with that sha256. If so, I know it's a valid file from Spotify.

[probonopd]

Yes, that's the harder part. There is something about signatures in the AppImageSpec but it is not used by all AppImages. Maybe calculating a checksum over the entire AppImage file would be easiest.

Also let's think about the case of updates. Check the "Update Information" section of the AppImageSpec; I'd be happy to extend that spec if needed.

[MadSpindel]

I was also thinking about if update section could be used for verification, if we use decentralized identifier to find the updates. Maybe could work.

[MadSpindel]

I think if we have atproto|did|rkey in Update spec, that would work.

Using Raspberry Pi Imager AppImage as an example:
atproto|did:plc:vft2wzc6ut2faedtgwg4asot|imager

Then package manager could check if did:plc:vft2wzc6ut2faedtgwg4asot (@raspberrypi.com) has any org.appimage.application Lexicon with rkey "imager", or check if did:plc:vft2wzc6ut2faedtgwg4asot has any org.appimage.release with rkey imager-2.0.6 and compare sha256 checksum with the downloaded file.

But, is it always possible to find version number within an .AppImage? If not, maybe that should be added to the specification?

[mudkipdev]

I'm guessing the actual files themselves will be downloaded over http?

[MadSpindel]

I'm guessing the actual files themselves will be downloaded over http?

Correct, org.appimage.release should have a download url to the file

[MadSpindel]

Would love to get some feedback from existing AppImage tool developers like @ivan-hc & @TheAssassin

[ivan-hc]

Centralizing AppImages has always been a goal of mine.

I use amcheck, which uses AM to verify whether the AppImages listed here exist and are downloadable.

It tests 250 of them every hour.

https://github.com/ivan-hc/amcheck/actions