Wallet Messaging Community Call: Summary

Problem Statement

In the expanding Bitcoin ecosystem, a common user experience challenge arises when users attempt to initiate actions that their chosen wallet or app might not support, such as specific transaction types/procedures like PayJoin. This results in a frustrating user experience where the incompatibility only becomes apparent after an app is launched or an action is initiated. It can also mislead a user in thinking their transaction is being handled in a privacy preserving way.

A seamless user experience mandates that apps transparently communicate their capabilities to the OS and other apps, ensuring users are only presented with compatible options.

Existing Challenge

Native Bitcoin applications tend to register themselves with bitcoin:// so they can handle BIP21 payment requests. There are other BIPs which append parameters to BIP21 like BIP27 / Payjoin which adds the &pj=... parameter.

Currently, unless an app's full capabilities are registered in the Android package manager, a place accessible for all installed apps to read—there's a significant risk of deteriorating user experience and giving the user a false sense of privacy. Users could be directed to apps that don't support the intended action since the pj parameter will be ignored.

Solution Overview

1. Announcing Capabilities via the Android Manifest File

• Each app should clearly define its supported actions and file types in its AndroidManifest.xml file.
• For instance, by looking at the BlueWallet's manifest, we can deduce its support for common Bitcoin and Lightning URIs, as well as its ability to handle and sign PSBT (Partially Signed Bitcoin Transaction) files.
• This ensures that when a user attempts to open a specific URI or file type, Android will only suggest apps that have declared support for that specific action or file.

2. Retrieving Referrer Information

Apps can use the getReferrer() method to identify which app directed the user to them.

• This can be useful for apps to understand the context in which they were launched, potentially allowing for a more tailored user experience.
• The following code snippet demonstrates how to retrieve the name and icon of the referring app inside an Android Activity:

val callingPackage = getReferrer().getHost()
val pm = packageManager
val applicationInfo = pm.getApplicationInfo(callingPackage, 0)
val appName = pm.getApplicationLabel(applicationInfo).toString()
val appIcon = pm.getApplicationIcon(applicationInfo)

3. Manifest Declaration Example

• The provided manifest snippet from BlueWallet showcases how an app can declare its capabilities.

<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="bitcoin" />
<data android:scheme="lightning" />
<data android:scheme="bluewallet" />
<data android:scheme="lapp" />
<data android:scheme="blue" />
<data android:scheme="http" />
<data android:scheme="https" />
</intent-filter>

• It supports various URIs like bitcoin, lightning, and bluewallet.
• Additionally, it can handle .psbt files, both as binary (application/octet-stream) and plain text (text/plain).

<data android:mimeType="application/octet-stream" android:host="*" android:pathPattern=".*\\.psbt" />
<data android:mimeType="text/plain" android:host="*" android:pathPattern=".*\\.psbt" />

Conclusion

By standardizing the way Bitcoin-related apps announce their capabilities on the OS level, the ecosystem can significantly enhance user experience. This approach ensures users are directed to apps that are compatible with their intended actions, minimizing errors and frustrations.

We will be continuing our R&D into this topic @ HUB21 and posting updates and a proof of concept.