In Fearless Wallet we are planning to include WC support in Stage 4, so we are happy to participate in any discussions regarding this as representative of one of the apps in the ecosystem.

It appears Math Wallet already has some partial support for polkadot Web3 in their embedded dapp browser

Hey, thanks for the great write-up, with KodaDot we are interested to participate as well. We have few ideas on how to do this. Definitely not fans of custodial relay servers w/ WC, in worst-case, it would be nice, but it's not a mobile-only approach.

Here are some mobile signer ideas people have passed along, steal them:

iframe that calls out to a user-specified signing handler - standard of communication into the iframe for arbitrary methods required by the page (be they fetching certain types of data [ie, content stored in ipfs, dat, other chains, apps, or apis] or requesting signatures or other interactive operations) and a method for user-specified pages to declare their "capabilities" to handle these methods and calls for given networks, protocols, and ecosystems.

all-in on deeplinking - pages provide deeplinks containing: • raw data to sign - either raw extrinsics, or call data • contextual metadata • page to load as a callback after signing is complete dapp devs handle the signature response in-url, instead of using an intermediary relay server, and provide the page that broadcasts the signed data as the callback page. This is a Good Idea because deeplinks within a single mobile device are not restricted by qr code density back and forth.

all-in on deeplinking 2: standard protocol to pass data to signing apps, no "callback" to a broadcast page - apps just assume that the signing app will do what is required, including broadcasting, they may provide "retry" buttons if the expected extrinsic doesn't appear onchain

@jam10o do we have some communication channels with client apps development in Polkadot/Kusama ecosystem? It would be great to discuss such standards there, as well as some topics related to QR-pay formats, etc. If such a channel doesn't exist, maybe it's reasonable to create one? For example in Element

I believe there are a couple Builders Program channels which are relevant, but are not public.

Definitely needs to be something public for these kinds of conversations, I agree. I'm probably not the correct person to be coordinating this though, otherwise I'd be offering to curate this proposal myself as well.

I see. Yeah, we have applied to the SBP program from the Fearless Wallet side, but our candidacy is still under review, but I agree that such a communication channel should be public anyway

upd: JFYI I have created this group in Element: https://matrix.to/#/#substrateappsdev:matrix.org

For MathWallet:

1. We already have polkadotjs embedded in mobile dapp browser.
2. We will support WalletConnect for polkadot later which is used in many dapp in other ecosystem already.
3. We'd like to discuss/have a deeplink standard protocol which is actually for flexiable, decentralize and easy to understand between dapp and wallet.

@ericyu your team's feedback is definitely valuable here, as you've already integrated PolkadotJS web3, eth web3, and Walletconnect

if any teams need an extra pair of hands please share here as i'd be keen to contribute to open-source issues

I am glad to be the curator of the bounty.

Continue the discussion from the motion：

• Pocket4D team has experience in built Substrate Dart API and would like to create a mobile app to enable relay transactions from mobile app to mobile wallet, see their proposal and solution comparision
• Wallet Beacon team has experience in building the SDK to relay transactions from the frontend app and mobile wallet and would like to extend it into Substrate-based chains.
• Fearless team has built useful tools and services in both Android and iOS, they also have RPC service for parsing metadata from the different blockchain (more info are required).

It is nice to see there are different good proposals/solutions related to this bounty, with some further discussion, we could distribute the fund with sub-bounty and support solutions.

PS: It is also very nice to see many related libraries/tools existed in the ecosystem, I create this page and encourage more teams to share their mobile experiences.

Awesome! Fearless Wallet team would like to actively participate in this bounty. We can provide high-quality results when it comes to developing mobile apps for Substrate, meaning we can handle following work in the context of this bounty:

1. Develop iOS & Android native (Swift, Kotlin or KMM) SDK
2. Develop native iOS & Android demo app of mobile signer 2.1. Developing integration of resulting mobile signer in Fearless Wallet
3. Participate in researching of best ways to use mobile signers in Polkadot & Kusama ecosystem (address challenges related to different Runtime of each Parachain and how e.g. balances/tokens work there, etc)

In other words - we can handle both research & development for native mobile apps and libraries, so we are very excited to help!

At AirGap & Papers we've been thinking about a seamless, secure and trustless approach to connect dApps with wallets for a while now. The team has worked on Beacon, a solution for the Tezos protocol that is being used by multiple wallets and numerous dApps.

Applying the lessons that learned during the development process and with existing building blocks in place, we can together create a solution that achieves the following goals:

• A standard e.g. Polkadot Standards Proposal (PSP) for wallet and dApp interaction defined by the ecosystem of wallet and dApp developers
• Beacon Network, a decentralized peer to peer network of nodes based on the matrix protocol allowing trust-less and encrypted message relaying without any centralized relay server
• Connecting dApps to mobile, browser extension, web, desktop or hardware wallets
• Deeplinking support for mobile, web and desktop wallets
• Transport layer agnostic e.g. peer to peer or PostMessage etc.
• Beacon SDK as an implementation of the defined standard for dApp and wallet developers
• Example dApps, reference wallets and developer documentation

More details can be found in the draft of our proposal.

Team Pocket4D is glad to join the discussion. We had already seen excellent solutions like WalletConnect and Beacon from great Web3 community, no matter it is Ethereum or Tezos, or Polkadot. It is representing true Web3 spirit unifying us together.

For the proposal, there are a few usage context and criteria in our consideration:

• As fewer remote connection as possible. We hope we don't use any middle server.
• Better support multi-chain and protocols, ethereum and others, more importantly, parachain projects.
• Better providing config options and transparency to end users, especially when connection is lost or anything goes wrong accidently, users would be notified and take actions.
• We hope to narrow down to mobile-mobile for the first milestone, because it is the major scenario of mobile usage.

We hope to provide a cleaner solution for mobile wallets and Dapps, and because it is openly configured, we can use it to connect wider ecosystem components, eg Identity App, Web Wallets, Offline signers and so on.

After the first milestone is done and demo is released, we will proceed to use protocols from community like Beacon.

We hope the product can be the Web3 connector, not just "Wallet Connector"

Thanks for the proposals made by Fearless, Wallet Beacon, and Pocket4D team. I do think the three teams could cooperate together on composing the mobile injector and related tools. And I would like to coordinate the tasks and bring good chemistry here.

1. I think three teams need to agree on a Polkadot Signing Standard, which is a JSON file include the necessary info and signing protocol (e.g. Beacon, QR, ledger standard, etc). With this standard, the tx request from dApp could be built into different forms and send to variant signing wallets. For the minimal required data please refer to Universal Offline Signatures.

2. @pascuin team could leads the Beacon protocol with SDK support, it is a critical part to link mobile embedded dApp/web app to connect mobile wallet in a trustless way. As the SDK is currently built with Typescript/Javascript, I think @antonkhvorov team can help build the iOS/Android version SDK if both teams agrees on that. It is also important for Beacon team to provide a guide on how to join the Beacon Network's matrix server as the third party, it would be good if we could have multi-team joined this network together. In addition to that, AirGap Wallet/ AirGap Vault QR scanning needs to be compatible with Polkadot.js and UOS.

3. The @neeboo team could focus on the mobile app - mobile wallet connection part, as well as create a mobile application to relay transaction from apps to wallets, which will need to support the aforementioned Polkadot Signing Standard and enable switching the tx request into different forms, it would be good if the application could update the metadata and interpret the raw and signed transactions, which could offload a lot of work from Parity Signer. For interpretation the tx data, probably @antonkhvorov already has some remote solutions on that.

4. As far as I know, all three teams have different focus in different programming languages, @antonkhvorov in native iOS/Android, @pascuin in Typescript and @@neeboo in Dart/Flutter, so it would be good if you could extract some common libraries for tx packaging and signing there, which prevents duplication work and further benefits the community.

I am excited to see all the proposals and I suggest splitting the bounty into 2-3 sub-bounties, so all three teams contribute on different sides and compose a better solution. But currently, sub-bounties are not available on Kusama, will need some extra info from Raul.

For now, I think the three teams may have a look at each other's proposal, and let's have a kick-off meeting sooner next week and agrees on each other role and tasks. Once we decide, we could start developing.

Please provide the detailed task lists with expected working hours and developers from working teams. And once the sub-bounty feature is ready, I could split the bounty according to the tasks.

Could you please grant the comments permission to the public for your proposals @antonkhvorov @neeboo ?

With the kick-off meeting, three teams decide to work on the bounty.

• Paper AG team works on their Wallet Beacon solution to add Substrate support with Javascript/iOS/Android SDK to connect dApps and mobile wallets in a decentralized way, as well as a PSP network relaying the encrypted messages, which is open and could be maintained by the community.

• Pocket 4D team works on building a relay app that could forward the signing request from dApp to any mobile wallet, it should also compatible with cold mobile wallets like Parity Signer and AirGap Vault.

• Soramitsu team will speed up the above solutions in example app building process and provide Fearless Wallet as the first use case for both solutions.

So the bounty will be split with two major sub-bounties and one relatively small sub-bounty. I am waiting for

1. the sub-bounty feature to be ready
2. Estimated cost list from three teams (could refer to this table )

But the development process is already started.

All the related documents will store in the github repo: https://github.com/hanwencheng/Substrate-Mobile-Injector.

According to the proposal from two teams, and the KSM price on 22.04.2021 from Subscan $360.832, now we have two sub-bounties:

• The total cost of Wallet Beacon team is $220,800, which is 612 KSM.
• The total cost of Pocket 4D team is $79,520, which is 221 KSM.

PS: The total cost of Fearless wallet team will be calculated when the integration starts with the above two products.

Progress Report from 08.07.2021: from Hanwen on Direction Channel

"Hi, councilors, glad to share the progress of bounty #3.

The Wallet Beacon team is working on beacon-SDK with polkadot.js, together with the Fearless Wallet team, they have made this test app with Fearless Wallet, it shows nicely that after paring with QR code from the dApp, a user could easily confirm the transaction on the mobile wallets side, video here.

Pocket4D team at the same is working on the deep linking of mobile app-mobile app connection, which is 70% completed."

Original message: here.

As currently there are two teams are working on bounty #3 (namely: WalletBeacon, Fearless Wallet, Wallet 4D suspend the development according to the resource problem), in addition, the workload is not easy. So we intend to use sub-bounties and distribute the cost of the bounty with multiple teams and in multiple stages.

As the development tasks take a longer time, it is risky for teams to develop the products to keep working without any return. That's also at the beginning I suggest splitting the bounty into sub-bounties.

But as far as the sub-bounty PR is not yet to merge. I suggest that we could distribute the KSM in 2 batches, in order to keep incentivizing and reducing the risk of the involved teams, and eventually ensure the delivery of the products.

The plan is that the council firstly mark the task as finished, and distribute the payment to me as the bounty curator. I will check the currently completed work and review the summary of the submission work result. And distribute the KSM for the 1st batch delivery. And once the tasks are all complete, I will distribute the 2nd batch KSM. After all the distribution I will send back the rest of KSM to the council.

With the submission of the current work the Beacon and Fearless team have done, I think they have done a good job in the right direction of completing the bounty. All the related submission and review files are in this Github repo: https://github.com/hanwencheng/Substrate-Mobile-Injector/tree/main/Submission, the 1st batch distribution KSM is about 30% of the total bounty value. Council members, please feel free to check. Also please let me know if the plan is sensible.

One minor correction - council doesn't mark the task as complete, the curator (you) do :)

@jam10o is correct - this is a curator's task.

@@hanwen thank you for the update!

Our team would like to continue to work on the bounty, but now as a novawallet.io team. We would appreciate the opportunity to continue working with the Beacon team on improving their SDKs for the Polkadot ecosystem

I just made the tx that distributes the reward to the multi-sig wallet: FC4tZgWUDpg1AK5uoY7Z9bTaUanemyipoG7Tk8W9YXpxvZ6

The multi-sig wallet is currently handled by 4 accounts, which are listed on this page, two from me, one from Pascal of Beacon team, one from Anton of Fearless/Nova team.

To be noticed the accounts consisting of multi-sig wallet is only serve for decentralizing the monitoring, custody, and distribution process, they are not the final beneficiaries of the bounty.

If the bounty passed the chill period, I will distribute the 1st batch bounty value to the Fearless wallet team and the Beacon team according to the review of the submission in this folder and keep the rest of the bounty value in the multi-sig wallet.

Once the 2nd batch of work (that means all the rest of the work) has been done, I will review new submissions again and distribute the reward accordingly. And send the rest of the bounty value back to the council.

Thanks for the report, @hanwen! Appreciated.

As the bounty is completed, the KSM in the bounty is not able to cover the cost due to the changing price of KSM. I have created a new treasury proposal to top up the KSM of the bounty, and attach the review of the bounty.

preferably without requiring users to install an additional application on their devices so that it is platform agnostic, "as secure as possible".

So in my understanding outcome should be:

1. Description of a standard (how agents interact with each other, in particular, mobile device-web app-blockchain)
2. SDK for mobile devs to integrate into their mobile app
3. Demo app and/or Implementation in existing app (Polkawallet/Fearless Wallet/etc)

That's being said, I'm not sure that I get this sentence regarding "without requiring to install any additional application on their device" and "platform agnostic". Users have to install something on their devices to store their keypairs securely in the app's storage. In addition, what means by "platform agnostic" in this context?

I'm not sure that I get this sentence regarding "without requiring to install any additional application on their device" and "platform agnostic". Users have to install something on their devices to store their keypairs securely in the app's storage. In addition, what means by "platform agnostic" in this context?

hey yeah, that statement was made in the context of one example of a potential direction of a standard, not meant to be prescriptive as a goal - as you imply, that is an insecure direction and there's a reason nobody does it this way :)

If we wait for sub-bounties before beginning payouts for this, I would like for integrations into existing ecosystem apps, and implementations of whatever standard that comes out of this, to be incentivised via sub-bounty - from discussions with individuals and teams working on similar standards on other networks, it looks like the standardization process will be more involved than the actual implementation in this case.

In the process of developing PatraStore, when we are thinking about how to provide a unified wallet signature interface for Dapp developers, it is similar to the content mentioned in this bounty. We refer to the corresponding implementation and product plan of web3-react in Ethereum and designed the library https://github.com/patractlabs/arche. In this repo, we think we need to design an abstraction layer interface of a wallet, and based on the abstract interface to connect different wallet implementations, such as extensions, ledger, etc. At that time, WalletConnect and Ledger was still immature, so it is paused. Now, maybe we can explore this direction together.

Some further thought on the bounty, it would be good if we have a "Injector" which could:

1. Compatible with as much as mobile wallets as possible, currently there are many Mobile Wallets with different security mechanisms of key storage. And most of the time a high-security key storage comes with the compromise of user experience. As this injector is a vital part of the ecosystem, I think we could let the user decide which kind of wallet/key storage they want to use.
2. Compatible with as much dapps as possible, different dapps will create the signing request data from raw TxData with different forms, like QR code or string with a specific prefix. It would be good if this app could format the signing request into different forms like QR code for Parity Signer, or QR code for WalletConnect, raw tx for Ledger, and forward this signing request to different wallet apps. Thus, for dapp builders, once they aligned with this standard, they could be compatible with as much wallet as possible.
3. Use remote connection as little as possible. Ideally, it should not use any centralized server to relay the message or use Andoird or iOS centralized service for forwarding messages. Because:
   • The connection may affect the signing process, once the server is down or unavailable then the signing service could not be used. For example, the Chinese Great Firewall has blocked all the google services include Firebase.
   • There are still chances for TLS to go wrong, e.g. with the compromised CA, with a compromised server, etc.

It could be an App/SDK, and could perform the following role in the ecosystem:

I think this is a good direction/good priorities for an approach that can include multiple signing options and integrations - ie, if wallets include support for tools like walletconnect v2, this injector would allow their users to interact with dApps, meanwhile if we need to support other transport layers like walletbeacon, that support could be added to the injector itself.

I think the question that is still unanswered from the perspective of wallet implementors, is using this injector to allow users to interact with dApps on different Substrate-based chains than they natively have support for; to ensure that the user understands what they are signing, it's necessary to have or convey Metadata to the wallet, so they can parse and display the information. Do you think this kind of feature would be in scope, as something to convey over the transport layer?

iiuc the papers.ch / walletbeacon team has put alot of thought into this area for their tezos integration.

I would like to be the curator of this bounty with my experience in building Parity Signer and Ethereum-based wallets.

And to clarify, some of my personal interests are as followings:

1. As leading Litentry Project we are also building a governance-focused app, in the design, it intends to be compatible with as many mobile wallets as possible, and the Dapp itself does not need to have key storage, which could be a first Dapp side use case with this injector.

2. As a developer of Parity Signer, I would also like to see this injector could extend the use cases of air-gapped Wallet.

to ensure that the user understands what they are signing, it's necessary to have or convey Metadata to the wallet, so they can parse and display the information.

Maybe the injector in the transport layer could interpreter the transaction, with local metadata interpretation or remote call. But I think we need to first decide the form of this injector from the implementor side, is it a separate app or a SDK?

Create this repo for sharing basic info and shared documents for this bounty: https://github.com/hanwencheng/Substrate-Mobile-Injector.

If you want to be the collaborator of the repo, just feel free to ping me your Github account.