Wallet Messaging Research Meeting @ Hub21 in Belgrade

What we have so far?

We are now able to open another application, specifically the a bitcoin wallet which holds the device owners funds, and provide it with the invoice that it is requesting to pay. The screen on the wallet app goes directly to ask the user to confirm the payment. Once the payment is made, the wallet app takes you back to the "Service Provider App".

What next?

Cleaning up of the codebase

Have to switch up dependencies for networking and async tasks. Preparing of the android application for adding more features as things were done a bit quick and dirty during the project setup for LNBits.

Add error handling for easier debugging

Cause errors happen and we need to read them...

Deep Linking: Display the name of the the requesting app in the wallet.

deep linking v1 of wallet-messaging we need the wallet application to know what the requesting app is.

How might the wallet-app determine the originator? The most obvious way is to explicitly set it as a parameter in the URI. Something like `callback=<app_namespace>` Can the wallet application read the backstack to find out the identifier of the service provider app.

Even if you try to pull out the app name (or activity name) it would not be user friendly. For example it's com.google.andriod.youtube . Given we have the app package name, have how might we get more information from the operating system about the app name + other info?

One of the benefits of the wallet app being able to implicitly determine the app package name, and read other details about another app on the OS is that the implementation could be easier on the service provider side. The wallet developer then has to do more work resolving names, and providing the best UX so that they can capture the majority of transactions.

Background Payments using Broadcast Receiver: How might we enable payments to get automatically confirmed in the wallet application without having to open the wallet?

The same way deep linking opens an external application, the broadcast receiver can also be opened but in the background and have a short program run. There should not be any network calls done by the broadcast receiver, so it's possible to delegate to another background task. OR we ask the system for some additional time to run the call. Since some payments can take a bit longer we'll have to explore how this works.

Improving the UI for demonstrating the design pattern

We need to make it very clear that there are two different applications talking to one another when demoing the pattern because currently they have a similar style and it doesn't look like you're leaving the service provider app.