Accrescent's catalog is maintained by a respected community member and checks dev signatures on a third-party database on Github. Correct me if I'm wrong.

While zap.store currently is more or less that, we're aiming to change the status quo trust model.

Users will be able to cryptographically verify an artifact came from a developer using nostr. They can do so directly, relying on a web-of-trust check, or indirectly via curators (choose your own walled gardens).

In addition, we're targeting multiple operating systems and other features like relay-based communities, the ability to zap apps and developers, a marketplace for new apps and more.

Reply to this note

Please Login to reply.

Discussion

Nostr or the like wont be involved for Accrescent, it's been designed to compliment GrapheneOS to be a private and secure app store in the same fashion that GrapheneOS is. There had been interests for us using Accrescent for a long time and this addition coming in a time where people are into using other app stores is just a coincidence. Accrescent has been in active development and maintenance since 2021 and we had expressed interest to mirror it in our Apps app for a while.

> Accrescent's catalog is maintained by a respected community member and checks dev signatures on a third-party database on Github. Correct me if I'm wrong.

This is not done through GitHub rather Accrescent's own hosted infrastructure. When you open the app it will download the current repository metadata JSON which has the app names, ID, signing cert hashes, etc.

> Users will be able to cryptographically verify an artifact came from a developer using nostr. They can do so directly, relying on a web-of-trust check, or indirectly via curators (choose your own walled gardens).

For Accrescent, apps are verified by key pinning of the apps and signing of the app store's repository data. The repository is signed by Accrescent and verified with the repository data public key (hard coded into the app) before it can be fetched. It has downgrade protection and also has a minimum revision hard coded to protect against being served old metadata on first use. It also can support key rotation.

Downloading an app will make the client check the signed repository metadata and compare the app's certificate hash, minimum version, and app name from the signed repository metadata. If any of the parameters do not match it will not install the app for you. For updates it does not matter as Android won't let you update apps with a different certificate than your currently installed version.

Minimum version protects against first install of an insecure, older version, and app name protects against malicious copycat apps.

When someone submits an app on the Accrescent developer console (whitelist only right now) for the first time, it will put a hash of their app's signing key to the repository metadata. This makes sure users are only downloading apps by the real developer.

So in a nutshell, Accrescent places trust in 1 respected GrapheneOS community member. Zapstore places trust in your NOSTR-derived web of trust. Thanks for the clarification!

Regardless, when using an app store you are required to trust the app itself, the party who maintains the app, and the source of the apps. If your source to get the apps is from the same party who develops the app store, there is less parties to trust. It's a big reason we provide the option to install the apps like Markup, Android Auto, or Play Services directly from GrapheneOS as well. You'd only need to trust the apps and the developers rather than an arbitrary additional party just to get those apps specifically.

Right, that's a given. I'm specifically talking about the curation trust model inherent in all app stores. On this point, Zapstore & Accrescent diverge.

Appreciate your response

Accrescent is too sus.

All communication channels are through well-known compromised locations. Your work is beyond all that from the beginning, please do keep the good work and keep the apps offline.

Good question. I recently answered this:

nostr:nevent1qqst8tm7fj4fd4zu7d938ltcqqu7e0h2z0kpsxggfgzjapph5tmhjkcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrceeh65u3xgwrjsnny0wnf8zv4wd0v3374ckn9wdl92yc0qf3s05psgqqqqqqsch357h

The big difference is that once developers start signing their own apps, and using different relays (we're a few months away from that), there effectively is no centralized walled garden. No other app store doing that. Does that help?

If I understand you correctly none of what you mentioned has been implemented yet but is planned for the future. If yes, then this clarifies a lot and explains why zap.store looks like an ordinary appstore to me at the moment.