Mini app capabilities

[Ashoat]

More apps are working on being able to host Farcaster Mini Apps, and the feature set in the Mini Apps SDK continues to grow. Not all of the hosts will support all of the features in the SDK, but some Mini Apps might require specific features.

To address this, we want to introduce a set of four APIs, two on the SDK and two on the Mini App manifest:

1. Manifest: requiredCapabilities, which specifies which Mini App SDK features are needed for this Mini App to function properly. If the host doesn't have all of these features, it shouldn't try rendering the Mini App. This returns a list of strings like wallet.getEvmProvider, actions.signIn, actions.swapToken, etc.
2. SDK: getCapabilities, which specifies which capabilities the Mini App host supports. If a Mini App doesn't strictly require a particular SDK feature, but would like to use it if possible, it can leave out the capability in its manifest and instead call this method at runtime to check if it's available.
3. Manifest: requiredChains, which specifies which chains are needed for this Mini App to function properly. If the host doesn't have all of these chains, it shouldn't try rendering the Mini App.
4. SDK: getChains, which specifies which chains the Mini App host supports. If a Mini App doesn't strictly require a particular chain, but would like to use it if possible, it can leave out the chain in its manifest and instead call this method at runtime to check if it's available.

[SamuelLHuber]

on the chain side there's a great discussion here #240 (reply in thread)

[vrypan]

Notifications might be added to the capabilities. For example, a Farcaster client running locally, without a dedicated IP/Hostname may not be able to handle notifications.

[Ashoat]

Hmm to be honest, I think designing for locally-running Farcaster client is a bit of a distraction. But for what it's worth, the iOS simulator and most Android emulators support dev notifications.

[vrypan]

I don't agree with making decisions that make some types of clients (like https://github.com/hero-org/herocast) worst than others. Especially if it only takes adding a string to an array.

There may be other cases where notifications are not supported. Maybe they are a great use case, who knows?

[Ashoat]

Ah I misunderstood, I thought you were worried about a dev build of a Farcaster client, but you're actually referring to a release build of a local Farcaster client.

I should probably be more familiar but I've only read a bit about Herocast, never tried it. Does it not support notifs? Theoretically a local Farcaster client should be able to support notifs.

Main push-back from me: theoretically a client can come in and implement any subset of functionality. For instance, you could imagine somebody implementing a client that supports wallet.swapToken, but only for a selected set of approved tokens. I think we have to draw some line somewhere of what subset is defined in getCapabilities, and in my opinion the cleanest design is to have each entry correspond to a path to an SDK method.

[deodad]

What use cases are envisioning for how Mini App use this information?

[vrypan]

@Ashoat The reason why a miniapp should be aware of notification capabilities is that for example, using the "stock market alerts miniapp" or the "get notified when the auction starts miniapp" will be useless if they are not supported, and the user will complain it's not working.

BTW, I just checked https://warpcast.com/recaster-fc and even though it seems to be able to render miniapps, I don't think it supports notifications.

@deodad who knows? Platform developers and designers are historically very bad at identifying in advance the use cases that really take off. :-)

[cryptods8]

I have the following issues I think this proposal could solve:

1. Running framedl, I prefer people share their results into proper channels (/framedl, /framedl-pro). Since composeCast sdk action doesn't support channelKey, I'm falling back to compose cast intent (warpcast url) which is not ideal. In the meantime, I'd like to support sharing in other clients (CBW) and I'd prefer if they could share natively without predefined channel (so via composeCast) rather than via warpcast url.
2. I'd like to offer a different default experience for clients that can't do native SIWF (which is currently every client besides WC mobile)

(I know it's not a future-proof solution, but a good temporary workaround for me would be if I could identify the mini app host in my mini app directly)

[Ashoat]

1. I'm inclined to think the right solution there is channelKey being added to composeCast. If I recall correctly, you've asked for this in the past but we just haven't been able to prioritize it. I'll check with the team about it today and get back to you, but ideally I'll like to keep the clean design we have for getCapabilities right now where each entry is a path to an SDK method.
2. Isn't SIWF handled by the actions.signIn capability? I'm not the most familiar with this flow so definitely let me know if I'm missing anything!

[cryptods8]

1. absolutely agree
2. i don't mean having the capability of signing in, i mean having a different ux. currently, i prompt the user to log in whenever they open a mini app. it's super smooth on wc mobile, because it just does it automatically. however on web (or cbw), the user has to switch between devices (or apps), which ruins the experience a little. so in those cases i'd like to try a different approach (e.g. have an unauthenticated "try it out" experience).

i think both issues point towards imperfect implementations of perfect (or solid) protocols / specs. in a perfect world, capabilities are the correct solution, in our world i can't rely on it 100% and i would like to have a fallback.

[Ashoat]

We're working on solving #2, it should be fixed up very soon :)

[Quazia]

Do we want to fold in any information around smart accounts? I can imagine mini-apps that either don't work fully with a smart account or require a smart account to work fully.

Do we want to generalize the provider helpers in anticipation of other virtual machines such that getProviders works across mutliple VMs? Also preference for uniformity in the sense that it should either be getEthereumProvider and getSolanaProvider or (preferablly) getEvmProvider and getSvmProvider.

[Ashoat]

1. Regarding smart wallets vs EOA wallets:
   • My instinct is that a good solution would be to break down the individual capability differences between them, but I haven't had time to research things enough to get a good idea of what those differences are vis a vis mini apps
   • Separately, I'm a bit hesitant to include these differences in getCapabilities as it breaks the clean design we have right now where each entry is a path to an SDK method
   • Overall I'm inclined to keep it out-of-scope here to avoid blocking this proposal too much
2. Regarding provider API:
   • Would prefer to have them accessed via sdk.wallet. The wallet path is kind of like getProviders() already in my opinion
   • Good point on consistency. Checked with the team and we're worried that "SVM" isn't as obvious of an acronym to most, so we're going to go with getEthereumProvider and getSolanaProvider

[Ashoat]

This has been shipped :)

[vrypan]

Great, but what was shipped exactly? Did anything change to the original proposal based on the comments here? Where's the update in documentation so we can see what was shipped?

[Ashoat]

Great, but what was shipped exactly?

• requiredCapabilities and requiredChains were added as optional fields to manifest validation
• getCapabilities and getChains were added to SDK, although they will throw if the host doesn't implement them

Did anything change to the original proposal based on the comments here?

Only the naming of getEvmProvider, which was renamed to getEthereumProvider for consistency with getSolanaProvider.

Where's the update in documentation so we can see what was shipped?

Sorry about this! I plan to update the docs early next week, and will include some other updates as well. Keep your eyes peeled!