Our ethOS team has been working on a decentralized app store (DAS) solution for a while now. We’ve gone through a few working prototypes where we’ve identified shortcomings and found opportunities to further enhance our approach. In this post we’ll break down our current thinking.

Some of our guiding principles are:

• open source architecture, allowing anyone to expand the solution

• open chain architecture, allowing anyone to build their own UI client on top of the DAS

• working backwards from the UI in order to ensure we’re solving the right problems and ensuring the proper level of UX

• proper level of correctness in the system in order to avoid non-deterministic behavior

• expandable architecture that allows us to decorate existing entities and build the solution in stages

• proper level of safety and security that protects the end user from malicious actors

While there are a few DAS solutions out there, none have addressed the last point above. The collective agreement is that security is not something that is easily solvable - we think otherwise.

The core of our approach consists of:

• carefully defining the entities in the system

• ensuring immutability

• allowing for extensibility

We divide entities into core and decorated entities. Core entities make up the core of the system, hence the name. Decorated entities allow us to expand code entities with additional data.

Core entities include users, dev profiles, apps, app versions and app binaries. Decorated entities enable concepts like safety profiles, app reviews and identity verification.

The common quality is that both live on the blockchain and refer each other, which allows us to create a verifiable tree that ensures the correctness of an app. All entities can be traced back to the app and developer, which prevents spoofing and reduces the blast radius when it comes to malicious actors.

A DAS store can function with just the core entities in place, however decorators allow us to expand the data set with other valuable information. Decoration can even be performed by centralized services, as long as the data is written to the blockchain in a controlled manner.

When it comes to app binaries, our approach is to use IPFS as the storage mechanism. This allows us to prevent tampering because IPFS assigns a unique content hash to every item it hosts. In addition to deploying app binaries to IPFS, we are also considering deploying our management portal app there as well. This would allow us to keep the app decentralized, instead of hosting it in a centralized location, and help us avoid using centralized IPFS infra. With this approach in place, the core of our solution would be fully decentralized.

As usual, we are open to questions and feedback. If you see something that doesn’t make sense, you want to learn more about out approach, or even help us build all of this, reach out to us in our Discord.

In our next post, we'll cover the developer portal side of things. Stay tuned!