diff --git a/README.md b/README.md index 41719ccf59d..dc3e8fce4b3 100644 --- a/README.md +++ b/README.md @@ -107,6 +107,7 @@ Evaluators are individuals able to evaluate the technology delivered as a result - [Diogo Mendonça](https://github.com/dsm-w3f) - [Sebastian Müller](https://github.com/semuelle) - [Keegan Quigley](https://github.com/keeganquigley) +- [Nikhil Ranjan](https://github.com/nikw3f) - [Seraya Takahashi](https://github.com/takahser) #### W3F Operations Team diff --git a/applications/application-template.md b/applications/application-template.md index 57087dad840..bd01ca873c0 100644 --- a/applications/application-template.md +++ b/applications/application-template.md @@ -108,7 +108,7 @@ This section should break the development roadmap down into milestones and deliv Below we provide an **example roadmap**. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We _recommend_ that teams structure their roadmap as 1 milestone ≈ 1 month. -> :exclamation: If any of your deliverables is based on somebody else's work, make sure you work and publish _under the terms of the license_ of the respective project and that you **highlight this fact in your milestone documentation** and in the source code if applicable! **Teams that submit others' work without attributing it will be immediately terminated.** +> :exclamation: If any of your deliverables is based on somebody else's work, make sure you work and publish _under the terms of the license_ of the respective project and that you **highlight this fact in your milestone documentation** and in the source code if applicable! **Projects that submit other people's work without proper attribution will be immediately terminated.** ### Overview diff --git a/applications/chainlens_substrate_phase4.md b/applications/chainlens_substrate_phase4.md new file mode 100644 index 00000000000..fbc52b5d438 --- /dev/null +++ b/applications/chainlens_substrate_phase4.md @@ -0,0 +1,200 @@ +# Chainlens (Sirato) Substrate Explorer - Phase 4 + +- **Project Name:** Chainlens (Epirus) Substrate Explorer - Phase 4 +- **Team Name:** Web3 Labs Ltd +- **Payment Address:** Fiat payment details will be provided on invoice. +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview + +_We rebranded recently from Sirato to Chainlens_ + +This is an application for a follow-up grant for the Chainlens Substrate Explorer that has completed two grants previously: + +Phase I: [Application](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_explorer.md) [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/527) + +Phase II: [Application](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_phase_2.md) [Milestone 1 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/652) [Milestone 2 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/742) + +Phase III: [Application](https://github.com/w3f/Grants-Program/blob/master/applications/sirato_substrate_phase3.md) [Milestone 1 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/sirato-substrate-explorer-phase3-milestone1.md) + +### Overview + +From our previous grants we have built: + +- A [Wasm contracts and blocks data explorer](https://substrate.sirato.xyz/) that supports smart contracts deployed on pallet-contracts +- A [verifier service](https://github.com/web3labs/ink-verifier-server) that verifies, through reproducible builds, the source code files for a specific on-chain code hash. + +In this grant, we intend to expand Chainlens Substrate to: + +- Display information about verified contracts +- Provide a configurable option to the deployer of the verification service to provide a choice of storage options for uploaded contract artefacts +- Display chain data statistics +- Use the new `—-verifiable` flag of the cargo-contract tool to produce verifiable builds + +## Project Details + +In our current architecture, there are several components: + +- Squid Archive (built on the Subsquid framework): the squid archive connects to the Substrate network node and indexes base data such as blocks and extrinsics, exposing a GraphQL API. +- Squid Processor (built on Subsquid framework): the squid processor ingests data from the squid archive, filtering and transforming the relevant data to the data models for the Explorer. Currently, our squid processor is focused on Wasm contract data from pallet-contracts. The squid processor exposes a GraphQL API. +- Explorer UI: The explorer UI is made up of a set of composable components that consumes the API of the Squid processor and renders the web application. +- Verifier service: this REST web service is responsible for accepting contracts verification requests from the client and processing them. +- Ink-verifier-image: a docker image that can produce a verifiable build of an ink contract. + +![Current Architecture](https://drive.google.com/uc?id=1BVgvcQPCwGa3BJyD__z-wXKgzyt9mBbG) + +Fig: A high-level Chainlens Subtrate architecture + +The UI sends verification requests to the verification service when a user uploads a verifiable contract for verification. The verification service then stores the uploaded contract on the disk and begins verification of the contract. Any information about the request itself isn't persisted for the client to see later. + +## Milestone 1 + +In the first milestone, we will provide an option to the verification service deployer to pick one of these three storage backends before running the service: + +- Local file system +- Object storage such as Amazon S3 +- IPFS + +These options will be available in the form of an environment variable to the service via a config file. + +Here's how these options will work: + +- Local file system: the service will have this as a default option and the service already has this implemented +- Object storage: the uploaded artefacts will be stored in object buckets +- IPFS: a global gateway will be used to upload the artefacts to the public IPFS network + +We will also add support to display verification requests. + +![querying service](https://drive.google.com/uc?id=14T76kHfN_Rdmrz276w1faJ8tHehJxmfF) + +Fig: An architecture of the explorer ui, verification service and the new querying service. + +We will introduce persistence of all verification requests in a structured fashion and present it to the client requesting to see them. The verification service will be modified so that it will accept a few additional parameters from the client related to the contract and will store it in the persistence layer. + +This is to enable other teams to easily extract verification data about verified contracts from Chainlens. + +For querying the verification requests data, we will introduce a new microservice called as verification querying service. This service will have access to the same persistence layer where the requests are stored and serve them over a single REST based API. + +Examples of queries clients can make: + +- return a list of all verification requests + +`GET /stats/` + +response: +``` +{ + result: [ + { + id: 1, + code_hash: 0x123, + deployer: 5Gep, + verification: false + } + ... + ] +} +``` + +- return a list of only successfully verified contracts + +`GET /stats//verified` + +`GET /stats//verified/5` + +- return a list of only failed contracts + +`GET /stats//failed` + +`GET /stats//failed/10` + +- return a list of top n recent verification requests + +`GET /stats//5` + +#### Mock-ups +![verifications requests](https://drive.google.com/uc?id=19gx_F-JIrXTrnHOB4N3JwyEOikOmZlJJ) + +![contracts view](https://drive.google.com/uc?id=1IXG710iH4VoNytFnKkziWbGwBaj9-sn-) + +## Milestone 2 + +In the second milestone, we will add a new UI page to Chainlens Substrate to display statistical information about the chain data. This will convey a nice summary of the chain data in the form of beautiful charts. + +![graphs view](https://drive.google.com/uc?id=1vOkRhdaXrd9_Benr2s1b8KULwVQZMRgM) + + +We'll also modify our contract verification process to use the new feature being added to the cargo-contract tool to produce verifiable builds - `cargo contract build --verifiable` - as discussed [here](https://forum.astar.network/t/webassembly-smart-contract-verification-ecosystem-status/4797) and [here](https://github.com/paritytech/cargo-contract/issues/1065). + +Along with using cargo-contract to produce a verifiable build, we'll add support to detect the active rust toolchain set in the config.toml file of a rust project and use that toolchain version to build the project. + +This modification will make our ink-verifier-image a lot simpler. + +### Technology Stack + +We will use rust to build our new querying microservice. The persistence layer will be a Postgres database. + +### Ecosystem Fit + +There is currently a lack of high-quality open-source explorers for smart contract networks in the Substrate ecosystem. Polkadot.js is the de facto explorer and it is very modular and flexible. However, it was designed more for development and lacks the ability to filter, sort and search through data on the network. In the space of user-facing explorers, Subscan is currently the most popular solution and has the most comprehensive support for Substrate pallets. On the other hand, Subscan is mostly close-sourced and introduces an economic entry barrier for new networks. + +This dominance by Subscan is something that has been highlighted recently during an in-depth [discussion on the Polkadot Forum](https://forum.polkadot.network/t/subscan-ought-to-change-its-business-model-or-be-replaced/2357). + +While a number of open-source alternatives have emerged, none of them have support for smart contracts. In our previous grants, we have expanded the open-source explorer offerings to include WASM contracts on Substrate. At the same time, we also want to provide the essential base data like blocks and extrinsics so that smart contract networks can have a feature-complete explorer at their fingertips. + +## Development Roadmap 🔩 + +### Overview + +- Total Estimated Duration: ~4 months +- Full-Time Equivalent (FTE): 1 +- Total Costs: € 55,000 + +### Milestone 1 + +- Total Estimated Duration: 2 months +- Full-Time Equivalent (FTE): 1 +- Total Costs: €27,500 + +### Milestone 2 + +- Total Estimated Duration: 2 months +- Full-Time Equivalent (FTE): 1 +- Total Costs: €27,500 + +| Nº | Deliverable | Specification +| :-- | :-- | :-- +| 0a. | Licence | Apache 2.0 | +| 0b. | Documentation | We will provide inline documentation of the code and documentation on how to set up an explorer instance. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. We will describe how to run these tests in the guide. | +| 0d. | Docker | We will provide a Dockerfile and Docker Compose file(s) to ease the deployment and execution of the system. | +| 1. | Verifications querying microservice | A microservice that will fetch info about verification requests from the persistence layer. | +| 2. | Updated Explorer UI | We will introduce new pages to display contract verification requests and statistics for chain data. | +| 3. | Updated verification service | The service will now make the verification requests persist and will support configuring storage option type for the uploaded artefacts. | +| 4. | Updated ink verifier image | The ink verifier image will now use the `--verifiable` flag of the cargo-contract tool to build a verifiable contract. | + +## Team 👥 + +### Contact + +- **Contact Name:** Conor Svensson +- **Contact Email:** [conor@web3labs.com](mailto:conor@web3labs.com) + +### Legal Structure + +- **Registered Address:** 7 Bell Yard, London, England, WC2A 2JR +- **Registered Legal Entity:** Web3 Labs Ltd, CRN 10783824 + +### Team Code Repos + +- https://github.com/web3labs + +## Future Plans + +We plan to add open-source support to other popular Substrate pallets in the future. Some interesting pallets we are considering are assets and XCM related pallets, to be able to track asset movements across the DotSama networks. + +The Frontier EVM and EVM+ pallet by Acala are also valuable additions to the ecosystem that we wish to support at some point. On top of that, we also plan to add some proprietary modules for the explorer to be able to sustain our growth long-term. Our goal is to provide a full-fledged open-core explorer with comprehensive data and intuitive UI that networks can customise to their needs. + +Besides the core explorer, we also want to expand the functionality of our ink! verifier service. Right now, it only supports the verification and metadata hosting of ink! smart contracts. + +Our goal is to support any WASM smart contracts and evolve the service to a multi-VM metadata registry that can scale up to cater for the entire Substrate and DotSama ecosystems. diff --git a/applications/dapp_wallet_integration_native_mobile_libraries.md b/applications/dapp_wallet_integration_native_mobile_libraries.md new file mode 100644 index 00000000000..ebff0154557 --- /dev/null +++ b/applications/dapp_wallet_integration_native_mobile_libraries.md @@ -0,0 +1,308 @@ +# Tesseract dApps/Wallet integration native mobile libraries + +- **Team Name:** Tesseract +- **Continuation of:** [mobile dApps/Wallet Connection](https://github.com/w3f/Grants-Program/pull/508) + +### Overview + +This is a follow-up grant proposal aiming to reduce the integration barriers of the mobile dApp/Wallet integration protocol built during the [previous grant](https://github.com/w3f/Grants-Program/pull/508). + +Tesseract dApp/Wallet integration protocol implemented in our [previously finished grant](https://github.com/w3f/Grants-Program/pull/508) 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: . + +The version released during the previous grant is an excellent achievement for Tesseract. It is the first step toward implementing Tesseract’s full potential. Ultimately, we aim to make Tesseract a universal go-to dApp/Wallet integration solution capable of handling any scenario using the shortest peer-to-peer communication path. You can read more about it in detail in one of our articles: [Why do we need better dApp/Wallet connectors?](https://medium.com/@dileping/why-do-we-need-better-dapp-wallet-connectors-and-how-did-we-come-up-with-the-tesseract-protocol-987ce0e8a1ab) + +To achieve such an ambitious goal, we need to cover two main areas of improvement: + +1. Allow Tesseract to cover more use cases: add desktop dApps connectivity, ability to work with dApps running in browsers, etc. +2. Provide the dApp and Wallet developers with a way to integrate Tesseract as easily as it can get. + +Even though covering more use cases ASAP sounds tempting, we believe that the UX improvements Tesseract’s current version brings to the Substrate community already provide enough value by itself to focus on and implement an easy way for the dApps and wallets to integrate Tesseract - a set of native libraries (Swift and Kotlin), that allows using Tesseract no harder than any native library the developers are used to. + +### Why are the Tesseract native libraries necessary? + +iOS and Android provide their developers with native programming languages, which are the standard for the platforms: Swift and Kotlin, respectively. + +In contrast, Tesseract is built in Rust for its reliability, robustness, and cross-platform nature. While providing a lot of pros, Rust is quite hard and cumbersome to integrate into a mobile app (dApp or Wallet) and requires a lot of knowledge and effort, which is a significant barrier to Tesseract integration. + +To counteract this barrier, we propose to build Swift and Kotlin native libraries that wrap all the complexity of Rust integration under the hood and provide the dApp and Wallet developers with easy and familiar native APIs that require no more effort than any other mobile library. + +This way, we reduce the integration barrier to the minimum, allowing Tesseract to participate in Polkadot/Substrate community without bearing any additional complexity for the developer. + +### What about cross-platform mobile apps (React Native, Flutter, etc.)? + +Cross-platform mobile frameworks, such as React Native and Flutter, are popular among mobile developers. Providing libraries for these frameworks is definitely planned. + +However, building a library for such a cross-platform framework is done via Swift/Kotlin bridges. This means that to build the APIs for the cross-platform frameworks, we first need to implement Swift/Kotlin Tesseract libraries. It’s an unavoidable prerequisite. + +We are approaching the infrastructure around Tesseract in stages. Even though we would love to have React Native and Flutter asap, to avoid the grant bloating, we narrowed the scope down to Swift/Kotlin, which provides significant value by itself, allowing non-cross-platform developers to benefit from Tesseract while being a prerequisite step for cross-platform libraries development anyhow. React Native and Flutter are the next step. + +### Native Libraries APIs + +In total, there are four sets of APIs of Tesseract libraries to work on: + +1. Android dApp side +2. Android Wallet side +3. iOS dApp side +4. iOS Wallet side + +Each of the sides requires several rust libraries to be wrapped: + +1. Tesseract itself +2. IPC transport +3. Test protocol +4. Substrate protocol + +For the sake of simplicity, we will not list all the objects and methods here but rather provide examples of how native mobile developers can use Tesseract. + +We aim to make the APIs as simple as we managed to do in Rust and keep them as similar among the platforms as possible. Even though implementing the bridges is not a trivial process and is a lot of interop code, the libraries’ “frontend” APIs still can be very easy and intuitive. Let’s jump straight to it. + +#### dApp Side + +Let’s start with some code examples we have in Rust. Here is how one would initialize Tesseract and request an account from the wallet in Rust on the dApp side: + +```rust +let polkadot_wallet_service = Tesseract::new(Arc::new(delegate)) + .transport(TransportIPCAndroid::new(&env, application)) + .service(Substrate::Protocol); + + +let account = Arc::clone(&polkadot_wallet_service).get_account(AccountType::Sr25519).await?; +``` + +In iOS, it can look something like this: + +```swift +let polkadotWalletService = Tesseract(delegate: delegate) + .transport(IPCTransportIOS()) + .service(protocol: .polkadot) + + +let account = try await polkadotWalletService.getAccount() +``` + +And here is an example for Android: + +```kotlin +val polkadotWalletService = Tesseract(delegate) + .transport(TransportIPC(application)) + .service(Protocol.Polkadot) + +val account = polkadotWalletService.getAccount().await() +``` + +#### Wallet Side + +While the dApp APIs are typical for client-side APIs, the wallet-side APIs resemble some service implementation closely (i.e., a web service or an RPC). Here is how it works in Rust (an example is taken from the Developer Wallet): + +```rust +let ipc = Transport::default(&env)?; +let tesseract = Tesseract::new() + .transport(ipc) + .service(TestService::new(...)) + .service(SubstrateService:new(...)); +``` + +Also, `TestService` and `SubstrateService` are classes implementing a certain interface (separate for each) that defines how exactly the wallet should reply to the public key and transaction signature requests. Here are the Rust interface implementations: + +```rust +impl tesseract::service::Service for TestService { + type Protocol = Test; + + fn protocol(&self) -> &Test { + &Test::Protocol + } + + + fn to_executor(self) -> Box { + Box::new(tesseract_protocol_test::service::TestExecutor::from_service(Self)) + } +} +``` + +```rust +#[async_trait] +impl tesseract_protocol_test::TestService for TestService { + async fn sign_transaction(self: Arc, req: &str) -> tesseract::Result { + //implementation code goes here + } +} +``` + +The implementation of the Polkadot Service is going to be fairly similar, just different methods (Polkadot specific): + +```rust +#[async_trait] +impl tesseract_protocol_substrate::SubstrateService for SubstrateService { + async fn get_account(self: Arc, account_type: AccountType) -> tesseract::Result { + //implementation code goes here + } + + async fn sign_transaction(self: Arc, account_type: AccountType, account_path: &str, extrinsic_data: &[u8], extrinsic_metadata: &[u8], extrinsic_types: &[u8]) -> tesseract::Result> { + //implementation code goes here + } +} +``` + +Such an API implementation approach is pretty straightforward for both Swift and Kotlin. The initialization is a simple builder pattern, and the Rust’s traits here can be replaced with the protocols and interfaces of Swift and Kotlin 1:1 in this case. We are not providing additional examples here to keep the proposal concise, as we believe they are redundant for the wallet example due to its trivial outer API. + +### Feasibility + +All the APIs in the examples are tested to be achievable with the mock objects. The feasibility of creating such bridges was tested while creating the mobile demo applications and the Developer Wallet for the previous grant. + +## Team :busts_in_silhouette: + +### Team members + +- Daniel Leping, @dileping on GitHub, CEO +- Yehor Popovych, @ypopovych on GitHub, CTO + +### Contact + +- **Contact Name:** Daniel Leping +- **Contact Email:** +- **Website:** + +### Legal Structure + +- **Registered Address:** 251 Little Falls Drive, Wilmington, New Castle County, Delaware 19808-1674, USA +- **Registered Legal Entity:** Tesseract Systems, Inc. + +### Team's experience + +Our team has been building blockchain applications since 2017 and has worked together on Tesseract since 2018. The company got funded by SOSV and Emurgo in 2019 and took training in the dLab acceleration program. + +This is our third grant application for W3F. Previously, we were awarded to build [Polkadot/Substrate Swift SDK](https://github.com/w3f/General-Grants-Program/pull/333) and the initial grant of [Tesseract dApp/Wallet integration protocol](https://github.com/w3f/Grants-Program/pull/508). + +Prior to blockchain technology, we had a wealth of experience in building mobile applications and middleware, among which the most noticeable projects are: Swift Express and Reactive Swift. + +The team has a 10-year history of working together, delivering various solutions of high complexity, including the mentioned above Swift Express and Reactive Swift, Cross++ ( cross-platform framework in C++ that allowed to keep the app logic shared while providing the capability to use native UIs) and tens of the web, mobile, and server applications for customers from around the world including the US, EU, Israel, Australia, etc. + +### Team Code Repos + +- - current main repo + +#### Notable past open-source repos + +- +- + +#### Teams' github profiles + +- +- + +### Team LinkedIn Profiles + +- +- + +## Development Roadmap :nut_and_bolt: + +### Roadmap Overview + +The development is split into four equal milestones, each covering client or wallet-side APIs in Kotlin or Swift. This split allows us to focus on a particular library at a time and achieve tangible and easily verifiable goals with each milestone. + +- **Total Estimated Duration:** 16 weeks +- **Full-Time Equivalent (FTE):** 2 + +### Milestone 1: Wallet-side Library in Kotlin (Android) + +- **Estimated duration:** 4 weeks +- **FTE:** 2 + +A library in Kotlin, wrapping the wallet-side Tesseract rust implementation. Provides Android Wallet developers with native Kotlin APIs of Tesseract. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to integrate Tesseract into a Wallet. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | Due to the client-side nature of the deliverable, there is no need for a docker image. | +| 0e. | Article | We will publish an article that explains how Tesseract makes dApps better and how to enable Tesseract protocol support in a Polkadot wallet for Android. | +| 1. | Wallet-side Android library | The library provides Kotlin APIs for Tesseract's wallet-side | +| 2. | Wallet-side IPC wrapper for Android | Kotlin wrapper for the wallet side of Android IPC transport | +| 3. | Wallet-side of the Test protocol in Kotlin | Kotlin API for the wallet side of Tesseract Test protocol | +| 4. | Wallet-side of the Substrate protocol in Kotlin | Kotlin API for the wallet side of Tesseract Substrate protocol | +| 5. | Android demo Wallet | A demo wallet that demonstrates the Kotlin APIs usage | + +### Milestone 2: Wallet-side Library in Swift (iOS) + +- **Estimated duration:** 4 weeks +- **FTE:** 2 + +A library in Swift, wrapping the wallet-side Tesseract rust implementation. Provides iOS Wallet developers with native Swift APIs of Tesseract. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to integrate Tesseract into a Wallet. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | Due to the client-side nature of the deliverable, there is no need for a docker image. | +| 0e. | Article | We will publish an article that explains how Tesseract makes dApps better and how to enable Tesseract protocol support in a Polkadot wallet for iOS. | +| 1. | Wallet-side iOS library | The library provides Swift APIs for Tesseract's wallet-side | +| 2. | Wallet-side IPC wrapper for iOS | Swift wrapper for the wallet side of iOS IPC transport | +| 3. | Wallet-side of the Test protocol in Swift | Swift API for the wallet side of Tesseract Test protocol | +| 4. | Wallet-side of the Substrate protocol in Swift | Swift API for the wallet side of Tesseract Substrate protocol | +| 5. | iOS demo Wallet | A demo wallet that demonstrates the Swift APIs usage | + +### Milestone 3: Client-side library in Kotlin (Android) + +- **Estimated duration:** 4 weeks +- **FTE:** 2 + +A library in Kotlin, wrapping the client-side Tesseract rust implementation. Provides Android dApp developers with native Kotlin APIs of Tesseract. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to integrate Tesseract into a dApp. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | Due to the client-side nature of the deliverable, there is no need for a docker image. | +| 0e. | Article | We will publish an article that explains how Tesseract makes dApps better and how to integrate it into a Polkadot dApp on Android. | +| 1. | Client-side Android library | The library provides Kotlin APIs for Tesseract's client-side | +| 2. | Client-side IPC wrapper for Android | Kotlin wrapper for the dApp side of Android IPC transport | +| 3. | Client-side of the Test protocol in Kotlin | Kotlin API for the dApp side of Tesseract Test protocol | +| 4. | Client-side of the Substrate protocol in Kotlin | Kotlin API for the dApp side of Tesseract Substrate protocol | +| 5. | Android demo dApp | A demo application that demonstrates the Kotlin APIs usage | + +### Milestone 4: Client-side library in Swift (iOS) + +- **Estimated duration:** 4 weeks +- **FTE:** 2 + +A library in Swift, wrapping the client-side Tesseract rust implementation. Provides iOS dApp developers with native Swift APIs of Tesseract. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to integrate Tesseract into a dApp. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | Due to the client-side nature of the deliverable, there is no need for a docker image. | +| 0e. | Article | We will publish an article that explains how Tesseract makes dApps better and how to integrate it into a Polkadot dApp on iOS. | +| 1. | Client-side iOS library | The library provides Swift APIs for Tesseract's client-side | +| 2. | Client-side IPC wrapper for iOS | Swift wrapper for the dApp side of iOS IPC transport | +| 3. | Client-side of the Test protocol in Swift | Swift API for the dApp side of Tesseract Test protocol | +| 4. | Client-side of the Substrate protocol in Swift | Swift API for the dApp side of Tesseract Substrate protocol | +| 5. | iOS demo dApp | A demo application that demonstrates the Swift APIs usage | + +## Future Plans + +As mentioned initially, we aim to make Tesseract a **universal go-to dApp/Wallet integration solution**. We approach the development of Tesseract step-by-step, with each additional step bringing a significant concrete value to the ecosystem. + +The most critical areas we plan to cover are: + +1. Simplifying the integration of Tesseract for various development platforms by providing more and more libraries for various platforms (JS, Flutter, etc.) +2. Cover more use cases. Due to its robust and flexible core, Tesseract is extremely extendible, allowing us to aim for a universal dApp/Wallet integration solution as the ultimate goal. With its first two implemented connectors (mobile IPC for iOS and Android), Tesseract proves its capabilities to provide first-class seamless integration for mobile dApps. Soon, we will release more connectors (Bluetooth, NFC, QR, etc.), allowing more dApps to benefit from our seamless wallet integration. Desktop, Web, and more kinds of dApps will be provided with a seamless wallet integration in the near future. + +## Conclusion :heavy_plus_sign: + +Thanks to the support of the Web3 Foundation, the first version of the Tesseract universal dApp/Wallet integration protocol was built and released successfully. Though, to start providing value to the Polkadot/Substrate community, we need to lower the current technical integration barriers imposed by the fact that Tesseract is built with Rust, which is hard and 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. + +## Some links for reference + +- Github: +- Original grant proposal: +- Demo video: + +- Developer wallet (for Tesseract-compatible dApps testing): +- Polkadot dApp example: diff --git a/applications/index.md b/applications/index.md index cfd8326f063..ac3b86b56cb 100644 --- a/applications/index.md +++ b/applications/index.md @@ -48,7 +48,7 @@ Use this page for an overview of all public grants and their status. Use the sid | [Starks](https://github.com/tur461) | [XCM tool for NFTs](./xNFT.md) | [GitHub](https://github.com/tur461) | ☐ | ☐ | ☐ | | [ChainSafe](https://chainsafe.io/) | Polkadot Snap Maintenance | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☐ | ☐ | | [justmert](https://github.com/justmert) | [DOTLY: Revolutionizing Polkadot Account Statistics](./dotly.md) | [GitHub](https://github.com/justmert/dotly) | ☐ | ☐ | ☐ | -| [Federico Cicciarella](https://www.linkedin.com/in/federicocicciarella/?originalSubdomain=it) | [Tracking Chain](./tracking_chain.md) | [GitHub](https://github.com/TrackingChains/TrackingChain) | ☐ | ☐ | ☐ | +| [Federico Cicciarella](https://www.linkedin.com/in/federicocicciarella/?originalSubdomain=it) | [Tracking Chain](./tracking_chain.md) | [GitHub](https://github.com/TrackingChains/TrackingChain) | ☐ | ☒ | ☐ | | [TPScore](https://github.com/its-a-setup) | [TPScore](./TPScore.md) | [GitHub](https://github.com/its-a-setup) | ☐ | ☐ | ☐ | | [Orochi Network](https://www.orochi.network/) | [Research and development MPC ECDSA](./orochi-network-orosign-part1.md) | [GitHub](https://github.com/orochi-network) | ☐ | ☐ | ☐ | | [k/factory](https://k-f.co/) | [On-Chain Automated Treasury Management](./centrifuge-twamm.md) | [GitHub](https://github.com/centrifuge) | ☐ | ☐ | ☐ | @@ -136,7 +136,7 @@ Use this page for an overview of all public grants and their status. Use the sid | [decentraDOT](https://decentradot.com/) | [Cyclops Validator Dashboard](cyclops.md) | [GitHub](https://github.com/ArthurHoeke?tab=repositories) | ☐ | ☒ | ☒ | | [Anwesh Nayak](https://github.com/muddlebee) | [Mempool Dashboard - Version 2](polkadot-mempool-explorer-v2.md) | [GitHub](https://github.com/muddlebee) | ☐ | ☐ | ☐ | | [Tellor Inc](https://tellor.io/) | [Tellor Oracle Protocol](Tellor.md) | [GitHub](https://github.com/tellor-io/) | ☐ | ☒ | ☐ | -| [Jonathan Brown](https://acuity.social/) | [Hybrid Explorer](hybrid.md) | [GitHub](https://github.com/acuity-social) | ☐ | ☒ | ☐ | +| [Jonathan Brown](https://acuity.social/) | [Hybrid Explorer](hybrid.md) | [GitHub](https://github.com/acuity-social) | ☐ | ☒ | ☒ | | [ParaSpell](https://github.com/paraspell) | [ParaSpell_Follow Up 2](ParaSpell_follow-up2.md) | [GitHub](https://github.com/paraspell) | ☐ | ☒ | ☒ | | [justmert](https://github.com/justmert) | [PolkaFlow](polkaflow.md) | [GitHub](https://github.com/justmert) | ☐ | ☒ | ☒ | | [BelSoft](https://www.belsoft.rs) | [Diffy messenger](Diffy_chat.md) | [GitHub](https://github.com/1db1) | ☐ | ☒ | ☒ |