[base aepp] Wishlist: decentralised aepp store (aepp listing)

Can we have a simple way, maybe first manually by the somehow trusted base aepp team, to add aepps into the aepp section (just a list like we have it now with explorer, voting etc).

We can first use this threat to decide what should be there. I’d like to see

  • gomoku game aepp
  • coffee shop state channel aepp
  • naming aepp
  • redeem aepp (for paper wallets)

and whatever else we have. Maybe with a notice that people should or only can use it in testnet (so list them when you are connected to mainnet but make them non-selectable and when you switch to testnet you can actually click on them)

Thank you!

7 Likes

Good ideas! I know from the last dev call that naming aepp is being worked on. I think a contacts section will also be integrated along with messaging function.

@d-velev did start to build this as a project as far as I know, but am unsure how much more work it would need to finish

There are 2 questions as well as a hidden topic in @emin’s request. I will start with the hidden topic.

æpps need to share certain metadata with wallets/browsers/æpps listing services. This includes their name, icon, etc. Having an agreed upon format/spec is a prerequisite for great UX in browsing æpps inside wallets/browsers. We are working on a metadata aexpansion, which I will post as a draft on GitHub very soon (most likely tomorrow). Since currently there are only a handful of æpps, it is likely okay to implement the draft format from the aexpansion mentioned above before the aexpansion is approved (and alter the æpps to match the approved format, if it differs from the draft one, later).

Now onto the questions:

  1. The Base æpp already supports listing of æpps and we can easily add more. I suggest we do this after the draft format mentioned above is proposed (and we have gotten some feedback on it). We can move forward with this quickly, as mentioned above.

  2. The approach in #1 above is very much centralized: the Base æpp devs add the æpps to the list. Having a decentralized method of adding æpps is a very different project/scope/task. The 4 main issues at its core that I can think of off the top of my head are:

  • who votes/approves submitted aepps (which would include vetting their security, that they are not scams, etc)
  • how is the update of an aepp handled in regards to listing (concern: a legitimate æpp turns into a scam without the voting/approving parties noticing)
  • how can such aepp store/listing service be included in wallets/browsers in a way, which communicates clearly that the wallet/browser is not responsible for validating the security/legitimacy of the æpps in the store
  • hosting of such æpp store (should hosting be decentralized, too, or are we okay with it being centralized… and if the latter, who is providing the hosting/infrastructure).

I believe that working on a decentralized æpp listing service, should be an independent project. Perhaps one supported by the foundation.

1 Like

What about third party resources coming up with their own “repository” of Aepps? Aeternity team can place their official Aepps in the base aepp since that is theirs, but if a user wants external third party aepps, they would plug in the URL of a repository and it would download the list of aepps available in that repository.

For example, Aeknow.org has some aepps listed already: https://aeknow.org/aepps

Now there just need to be a generic “Repository” format so that all parties that want to host a directory of Aepps can follow it and create one.

That’s an interesting approach. You are basically suggesting that the user can pick a listing service (kind of like picking up an app store). I can see value in curated lists of this kind. However they also add yet another vector of vulnerability, as one could create a list of real æpps with one phishing æpp (a copy of a real one) in there.

1 Like

It is up to the user to trust the repository they are adding. There should be a warning letting the user know that the Base Aepp creators are not responsible for any third party aepps they use and that they should trust the repository they are adding.

The trusted repositories would be shared more often. If the repository is found to be malicious, then people would stop using it.

This gives an advantage to all developers who make their own aepps, but have not been accepted into any popular repositories, so they can create their own repository, and people can use all their aepps without having to be voted in.

If I were new to AE, it would not be fun for me to make aepps, and then have to go through a voting process to get my aepp into the base aepp. It would feel very centralized, especially if I were new to the ecosystem and just wanting to learn and develop my own aepps. It would feel like just getting started is already not possible.

1 Like

I think curating such a list is an interesting topic!