Tesseract dApps/Wallet integration native mobile libraries proposal #1856
Conversation
|
|
|
Thanks for the application @dileping formatting looks good. A few initial questions:
|
|
Thanks for the question, @keeganquigley. Please, see my comments below inline.
I think there is some confusion here. Please, let me clarify. The proposal is to build the fully functioning Swift and Kotlin libraries wrapping all the functionality of Tesseract. Not just the prerequisites. All the developers using the "default" approach for their mobile work will be able to use Tesseract just like any other library. As for the cross-platform libraries (ReactNative, Flutter, etc.), we'd like to provide cross-platform developers to integrate Tesseract as easily as everybody else in the future. Though, there are a couple of points to consider:
As for the funding of the cross-platform libraries - I think it's either through another grant or investor funding.
I agree; a lot of progress has been made in the Rust interop. I was monitoring it from time to time and researched this topic before preparing the proposal. Despite the progress, I still find the projects lacking a lot of what we need (i.e., asynchronous communication). While working on the previous grant, we developed a set of libraries that makes the interop process much easier. Here you can check them out:
These libraries provide us with pretty much everything we need and handle our edge cases very well. I think working around the limitations of other libraries will take more time and effort for us than doing how we have approached the interop so far. Also, we are planning to extract them eventually and make them more friendly for other developers. So they should end up in separate repos soon.
Any client library (assuming it doesn't have private keys functionality hardcoded) can be used with Tesseract as a signature provider. Here is an example of how we did it for subxt in our Polkadot Chat dApp Demo: https://github.com/tesseract-one/polkachat.rs/blob/main/common/src/substrate/signer.rs We thought about an idea to possibly provide ready-made Tesseract signature providers for the most popular Polkadot client libraries in the future. |
|
Thanks @dileping for the thorough explanations. Regarding my first comment, yes I just wasn't sure if the prerequisites you mentioned were part of this grant or not. Thanks for your clarifications there. I will mark the application as ready for review and ping the rest of the committee to take a look. I will also ping my colleague @CrackTheCode016 in case he has time and is able to give a quick review, as he is more familiar with Rust and mobile libraries than I. |
keeganquigley
added
the
ready for review
Thanks for moving the status forward, @keeganquigley! Glad my explanations were clear. Will be happy to answer more questions as they come up. |
There was a problem hiding this comment.
Thank you for submitting! I have left a few comments. As I understand, this proposal aims to do the following:
Provide Substrate-specific wrappers for Tesseract, which will allow for chain-specific signing capabilities to be possible. Basically, allow someone to use Substrate signing and extrinsic construction libs in native mobile environments through IPC to whatever wallet contains the private key?
Thank you again!
| 1. Tesseract itself | ||
| 2. IPC transport | ||
| 3. Test protocol | ||
| 4. Substrate protocol |
There was a problem hiding this comment.
How much of Substrate would be wrapped here?
It seems to me, whatever is used in constructing extrinsics in something like like subxt would be most appropriate? (sp_core, sp_runtime, some SCALE stuff etc). Or will you wrap subxt directly?
There was a problem hiding this comment.
We don't aim to wrap the subxt library. For the integration with Substrate, what we really need is a substrate-specific communication protocol. As for the integration with subxt, here is an example of how we did it in our demo apps: https://github.com/tesseract-one/polkachat.rs/blob/main/common/src/substrate/signer.rs
Also, we are providing a Substrate Swift library (not even a wrapper) for iOS developers so that they can use Substrate really easily together with Tesseract: https://github.com/tesseract-one/Substrate.swift/
|
|
||
| 1. Tesseract itself | ||
| 2. IPC transport | ||
| 3. Test protocol |
There was a problem hiding this comment.
Apologies if it was mentioned, but what is "Test protocol"?
There was a problem hiding this comment.
The test protocol is a communication protocol implemented in Tesseract on the same level as Substrate. It allows passing strings between the dApp and the Wallet and aims to be an easy way to test that Tesseract works correctly in the dApp or Wallet - whatever one tests at the moment.
| ```swift | ||
| let polkadotWalletService = Tesseract(delegate: delegate) | ||
| .transport(IPCTransportIOS()) | ||
| .service(protocol: .polkadot) |
There was a problem hiding this comment.
Assuming this will also support other networks, i.e., Kusama, or other Substrate based chains
There was a problem hiding this comment.
I didn't test it with Kusama, but it is the goal. Theoretically, it should work with any chain built on top of the Substrate. We are going to make sure it's the case.
Hi @CrackTheCode016, thanks for reviewing the proposal! I think you can say so - allow mobile developers to use Substrate and use the signing capabilities of whatever wallets. That's the goal; however, I want to add some details which I believe should bring more clarity. Actually, we have already implemented the Substrate chain-specific capabilities in Rust during the previous grant. Here is what the interface for the Substrate communication protocol looks like: https://github.com/tesseract-one/Tesseract.rs/tree/master/protocols/substrate. Currently, it's the only blockchain protocol we support, though more can be added fairly easily. Regarding the Substrate integration, within this grant proposal scope, we aim to provide Swift and Kotlin APIs for the protocol we already have. However, the proposal is not limited to only wrapping the Substrate integration. Instead, it aims to provide the whole Tesseract together with Substrate protocol for the mobile native environment in the form of native libs: Kotlin and Swift. This is necessary because Tesseract is written in Rust, and although it's possible to use Rust in native mobile apps, it's hardly an easy and enjoyable process. As an example, please, take a look at two demos we created as a part of the previous grant (both using Tesseract in its Rust form):
Also, I will go ahead and comment inline on your review. |
|
@dileping Thank you for the clarification! Based on this, this will serve as native wrappers for Tesseract as a whole, which subsequently includes Substrate. On a personal note, I don't see many native wallets in this ecosystem, but that is primarily due to the barrier to development (everything is either in Rust or Typescript), so cross-platform apps are de facto. As a former native app developer, there are many pros to native development from both a performance and security standpoint. Re-light client support might become relevant to pass in other information (proof or finality justification) from wallets and/or light clients on the device (as this is the future of client-side in web3). As an example, it is not farfetched for wallets to effectively become light clients themselves. Would you foresee Tesseract being able to provide this sort of support to dapps directly from this sort of setup? |
|
@CrackTheCode016, thanks for the detailed reply! Please, see my comments below.
Exactly!
I agree. There are some, but definitely not a lot. There are a couple of things I think are important as well for consideration here:
I think I started understanding what you and @keeganquigley are talking about when mentioning the light nodes. As I understand, you mean using Tesseract not only for querying pub keys and signing transactions but also to query other types of data from a local wallet/light node instead of querying a pub node, am I right? From a technical perspective - I think it's totally possible. I'd love to chat with you more about it and hear more details, like what use cases exactly you have encountered and what potential use scenarios you see. Sounds very interesting. |
There was a problem hiding this comment.
@dileping thank you for the application. I read the comments and the application. As far as I understood, the value added here is to have a native API to connect with Tesseract both in Kotlin/Swift. This could help native mobile developers to connect to some Polkadot wallet, in case Tesseract. However, I'm trying to understand why they would do that. There are other ways to connect with wallets using native interfaces. For example, they would wallet connect native kotlin or Swift SDK to connect to Nova Wallet or SubWallet. In this case, what would make the developer to select Tesseract instead of an approach like that?
Another doubt is the extent of the integration with Tesseract, what would be the functions/capabilities covered? Where you say all capabilities and features, what do you mean? I searched in the Tesseract examples and found three functions being used, I think would be more than that. Where we can figure out what exact capabilities we are talking about?
|
Hi @dsm-w3f, thanks for the review! Please, see my comments below inline.
I'd add to this that the added value is to provide the Substrate community with a realistic way to start using Tesseract. With just the Rust APIs available, it's a huge barrier because of the complexity of Rust interop. The way we want to approach it - that's totally correct - the main deliverables are Swift and Java libraries for the dApp and Wallet sides, providing wallet integration through the Tesseract protocol.
Not sure I understood you correctly. Just to ensure there is no misunderstanding: we don't plan to make our own wallet for production. Just the Developer Waller, which is made only for the developers to test their dApps easier. Instead, we want to provide the community wallets and dApps with a new integration option.
Can't disagree. Though, we believe there is a big room for improvement in how the dApps and Wallets play together. Tesseract brings its own perspective to solving the problem, which in our opinion, provides a superior user experience plus some other benefits. Here are a couple of links to the documents we've created that analyze how exactly Tesseract's approach is different and what improvements such an approach brings to the table:
I think there is some confusion here. In the demo dApps, we didn't expose the Tesseract APIs directly to Kotlin or Swift. Instead, we opted for a "cross-platform app with a native UI." We have built the whole logic of the application in Rust and made a narrow point of contact between the thin UI layer and the Rust logic implementation. To make it clear - the example file you encountered is not a part of Tesseract's API, but rather how the UI and the Core (cross-platform part) of the example communicate with one another. Tesseract Rust APIs are mainly located in the Tesseract.rs. There you can find the APIs in various groups. Firstly divided by the location where they are used:
Secondly, divided by the API category:
As for the examples of some use cases, I'd suggest, for starters going to the following subrepos where the Rust APIs are used directly in a dApp and a Wallet: |
semuelle
added
the
closed process: private finances
|
@dileping thank you for the answer. I understood that the Tesseract is an interconnection library between the Dapp and Wallet as WalletConnect is. Could you please give me more details on the affirmation "in our opinion, (Tesseract) provides a superior user experience plus some other benefits"? I read the application and saw that there are some characteristics that you claim that Tesseract could be better than other libs with the same purpose. Could you compare for example with WalletConnect, using native libs (see the links in my previous comment), and provide some of these characteristics that Tesseract could do that WalletConnect can't? Or in what way Tesseract is different from WalletConnect that could influence the decision of developers to use Tesseract and not WalletConnect? |
@dsm-w3f, thanks for the question! It's quite a challenge to provide you with a succinct answer here, but I'll do my best. Tesseract does not aim to bring more features. Instead, it aims to do the dApp and Wallet interaction better. Even though from the technical perspective, Tesseract and WalletConnect are based on completely different technologies, and I'd love to start with it, let's rather jump first to some obvious consequences of the different technological choices:
The above is not a comprehensive list of differences but rather is what the end-user may experience right away. The differences become even more apparent once we start talking about the technological differences. The main one is the approach chosen - WalletConnect uses the internet connection as its main data transfer mechanism, plus some additional ones for connection initiation or app switching. Tesseract is built with a totally different approach - each use case is unique and requires a different connection technology. For example, a dApp and a Wallet on the same phone are best to connect locally through IPC, while a dApp on a laptop would benefit the best from a Bluetooth connection to the Wallet on the phone. WalletConnect, however, chooses to use the Internet for both scenarios. Tesseract encapsulates all these complexities with various connection types under the hood, thus allowing the dApps and Wallets to benefit from the best available data transport while not having to implement each one separately. For now, we have managed to implement Tesseract core architecture and local data transports for mobile, allowing the mobile native dApps to interact with the wallets the best way we know, but the more data transports (Bluetooth, NFC, etc.) we implement, the more radical differences we will see in these two approaches. |
There was a problem hiding this comment.
Thanks for pointing out the differences @dileping and for the deep dives @CrackTheCode016 @dsm-w3f
IMO it's important to put more focus on mobile as that will be the way that most people access wallets. Since native wallets have some advantages over the cross-platform ones, and I think it's good to have competing libraries anyway, I'm willing to go ahead with it.
|
@dileping thank you for the answer. I understood that Tesseract work locally and don't need internet connection to interact between the wallet and Dapp, what is good, with the other functionalities presented. I think is a good feature set to have, so I'll go forward with this application. Just to add an opinion, I still think that the argumentation to convince people to use Tesseract is weak and needs more effort to show in a clear way the advantages of using it and the risks/disadvantages of connecting wallets in other ways. This is more from a marketing perspective than a technical one. Anyway, from the technical perspective looks good to me. |
|
@keeganquigley and @dsm-w3f, thanks a lot for approving our proposal and for going through all the info I sent! As for the weak marketing - I agree, we need to improve it. For that, we may need some help. Maybe the substrate builders program you've mentioned before? If you have any suggestions, please, let me know. |
|
@dileping I think SBP gives better support for creating a business than W3F grants program. I think a good time for applying to SBP is after successfully delivering a grant final milestone, but feel free to apply. |
There was a problem hiding this comment.
Thanks for the application, @dileping. I'm happy to support this project. My only recommendation would be - in line with what Diogo and Keegan already said - to get more eyes and hands on your code. Looking at your repos, it's only your team making contributions. Ideally, there would be a community of developers involved in raising and fixing issues. Otherwise, the project stands or falls with you. Given that this is your third grant, I'd be happy to make an introduction to Square One or the SBP.
|
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
|
@dileping, there are no payment details in either document. Could you add those? |
|
@semuelle, thanks for accepting our proposal! I agree we need to involve the community - that's the goal. This particular grant is a milestone towards getting there by making Tesseract much easier usable. As for the rest - I'll send you an e-mail now. |
Project Abstract
This follow-up grant proposal aims to reduce the integration barriers of the mobile dApp/Wallet integration protocol built during the previous grant.
Tesseract dApp/Wallet integration protocol implemented in our previously finished grant provides excellent UX enhancement capabilities to the Polkadot Substrate ecosystem. Its current version allows native mobile applications to request public keys and transaction signatures through seamless integration with any Tesseract-compatible wallet installed on the same smartphone. You can see the Polkadoot dApp interacting with a wallet demo here: https://www.youtube.com/watch?v=0AlDYB3Qglc.
Though, to start providing value to the Polkadot/Substrate community, we need to lower the current technical integration barriers. Tesseract is built in Rust for its reliability, robustness, and cross-platform nature. While being a great benefit, it also imposes a technical barrier by being labor-intensive to integrate into mobile dApps and Wallets. To eliminate this, we propose to build a set of native Swift and Kotlin libraries that wrap Tesseract’s Rust implementation under the hood and provide mobile developers with a straightforward way to integrate Tesseract within minutes, thus significantly improving the UX of mobile dApps within Polkadot/Substrate ecosystem.
Application Checklist
dapp_wallet_integration_native_mobile_libraries.md).@_______:matrix.org(change the homeserver if you use a different one)