Extensions discovery

How can an end user discover and install an extension?

Let’s explore different options.


Extensions can be installed via a universal link that can be embedded in a QR code. So it can be as simple as finding a link or a QR code in the wild.

Browsing a DApp

Extensions references can be added via a status specific API. When browsing a DApp user could be informed that some extensions can be installed. See https://github.com/estebanmino/EIPs/blob/master/EIPS/eip-747.md

Status discovery

Status discovery might relay users extensions. Extensions would then be available via the discovery UI.

Joining a chat

A list of extensions could be associated to a chat. Once joining, a user would then be proposed to install those extensions to have a better experience. Those extensions would only be active in that specific chat.
Private groups admin could manage this list of extensions.

How can we have extensions associated to public chats?

Chat command recipient call to action

A chat command might be sent to a recipient who didn’t install the extension. It should be trivial for them to install the extension.

ENS username

Some well know key/value pair associated to a ENS username name could point to a set of extensions. Those extensions could be used during account creation/restoration.

Any other way extension could be discovered?


@cammellos Do you think the chat flavor could be achieved in private groups? What about for public chats?

@julien private group chats much simpler, as you have an admin and you can tag a list of extension with membership information groups, it is essentially just another attribute (just like the name of the chat for example).

Public chat harder, as you point out, you don’t have an admin, so everyone could potentially have a list of suggested extensions, also you don’t make any noise when you join a public chat.

My gut feeling is that your best bet is to talk to the smart contract guys, you could have a list of extension that are associated with the name of the chat there and they can be added and voted on by people, staking etc.

Token curated registries are an often proposed solution to decentralised list curating.

I’m for the private chat group solution for the same reasons mentioned as @cammellos. One way which is not mentioned here is social. WeChat relies on social to spread official accounts (chat bots and then some) and mini programs because it has the belief that if they control it will become too bureaucratic, so they let the various apps filter through social connections.

In the context of Status then we need to think how easy/difficult it is to share an extension and work to reduce the friction in doing so.

Low hanging fruit for the early days would be an extension public chat.

As in people sharing links? Definitely something we want to leverage. Actually discovery can be seen as the automation of this.

Does WeChat have some kind of app store?

Do you mean having a chat with links to extensions? Makes sense.

Nope. A user may search for a mini program or an official account but the list is not pre-populated. There thinking is if the content is filtered through social then users are much more likely to enjoy the content because it came from their friends who share similar interests.

On min-programs side they do have a “mini-programs” nearby which will show you mini-programs which may be used at locations near you. It’s good for finding a mini program which has utility value at a specific location.

Another great way to discover an extension suggested by @rachel :

Chat command recipient call to action

A chat command might be sent to a recipient who didn’t install the extension. It should be trivial for them to install the extension.

Both chat recipient CTA and Browsing a DApp use cases have now been implemented.

1 Like