You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document outlines the plan to build the GnoMobile framework that will enable developers to create mobile applications using Gno. The code repository is found here:
Current Gno apps run on desktop/laptop computers which have Go installed. To run on mobile, the app would need to bundle the Go runtime which is complicated for most developers. However Berty has years of experience with using Go on mobile and overcoming other difficulties of the Android and iOS operating systems. Therefore, in milestone M0 we demonstrate that it is possible to run a Gno app on mobile.
Milestone M0 has two objectives:
The first M0 objective (now completed) is to create a proof-of-concept mobile application which stores a Gno wallet on the mobile and calls a realm function on a remote Gno.land node. A video demo of this PoC can be found here: https://www.loom.com/share/9537299635564761bc3a6d627411e33a
The second M0 objective (this document) is to use the experience building this app to create a detailed technical plan for a software framework called GnoMobile, which will be developed in milestone M1. The ultimate objective of GnoMobile is to make it easy for other Gno developers to make their apps to run on mobile devices.
GnoMobile System Diagram
For communication between the mobile app and the Gno code, GnoMobile uses gRPC, a well-supported framework which sends and receives Google Protobuf messages. Even though the core Gno code is written in Go, the app code can be React Native, Java, Swift, etc. The following system diagram shows how gRPC is used.
.
Moving from bottom to top, at the bottom are Go packages in the gno codebase. A gnoclient.Client supports communication with the remote Gno.land node with methods like Call to call a realm function. The gno codebase also has keys.Keybase to support a wallet stored on the local device with methods like CreateAccount.
These methods are called directly from the next level up by the GnoMobile Go code. A Go object can’t be passed through the gRPC interface, so the GnoMobile Go code maintains a persistent gnoclient.Client object which is accessed by gRPC calls. The GnoMobile API functions are registered by an amino package.go file and the generated Protobuf files are used to configure the gRPC server.
Finally at the top of the diagram, the gRPC client in the mobile app communicates with the GnoMobile gRPC server over a local connection using Protobuf messages. A gRPC call can either return an immediate result (for example, GetKeyCount) or an asynchronous gRPC stream object which can return delayed results (for example, a Call to a remote realm function). The gRPC framework uses the Protobuf API to generate convenient API functions in the mobile app’s preferred language (React Native, Java, Swift, etc.).
For the M1 version of GnoMobile we will focus on implementing the foundational features that will enable the blockchain operations, having in the center the development of the gnoclient API. Additionally, the M1 version will include the main wallet features and some toolkit features to make it easier for developers to code and gain a deeper understanding of the framework.
Category / Epic
Feature Name
Benefit for the user of GnoMobile
Importance for M1
Dependencies
Comments
Status
Blockchain Operations
gnoclient API
Use as much code as possible from the main Gno repo and benefit from continuous bug fixes by the Gno devs
Needed
HIGH - Will need support from Gno devs on converging on the technical solution design.
Work with the Gno team to test and finish the pull request for the gnoclient.Client public API for calling a realm function. This existing gnoclient package is imported by GnoMobile and is installed along with the Go runtime on mobile. gnolang/gno#1047
DONE
Blockchain Operations
Gas Estimation Interface
Use accurate gas estimation cost so that transactions don’t have to be repeated due to insufficient gas
Needed
HIGH - Will need the Gas estimation driver from Gno devs.
The interface will use the gas estimation driver as an input to get the information that will be displayed to the user. Er towards a “placeholder” type solution. See the faucet repo
Not Started - check with Gno devs (Michael?) for the “formula” in the next meeting. Temp target: provide an error code which tells they’ve run out of gas - we talk about this after we get client feedback
Blockchain Operations
Specify remote address and chain ID
Users have a choice to choose the node they want to interact with
Needed
DONE
Blockchain Operations
Sign & call a realm function
Users will be able to use realm functions
Needed
This operations requires gas and special handling if the gas was not enough
DONE
Blockchain Operations
Call a realm function with pre-signed transaction
Users will be able to use a hardware wallet
Wanted
WIP
Blockchain Operations
Make gnoclient have an interface + constructor to adapt the communication transport (e.g., use for Wesh Network in the future)
Users will be able to use multiple communication transport layers as they need arises
Wanted
LOW - Will need some support from Gno devs
Wesh raison d'être - create the foundation to later (post M1) enable async communication even in off-grid environments using Bluetooth and other near-field communication transport layers
Needs to be tested with an alternative transport
Blockchain Operations
Query a blockchain node
Users will be able to query the account balance, render function. Also, users will be able to call a realm function which doesn’t change state.
Needed
This operations does not requires gas
DONE
Blockchain Operations
Support Render and QEval
Users can call the realm Render function (as seen in the browser). And users can QEval any public realm function
Needed
Add Render and QEval to gnoclient.
DONE
Blockchain Operations
API support to make it possible to display progress feedback while waiting for a realm function to complete
Reduce user frustration while waiting for a function on a remote node (which can take time)
Needed
The mobile app using gRPC can get a stream object which supports this functionality.
gRPC streaming is implemented. DONE - It still needs work on Gno side to be fully operational
Wallet
Create or open a wallet on local device storage
Users are able to create an open wallets on their mobile devices
Needed
DONE
Wallet
Generate wallet recovery phrase
Users will be able to setup a recovery phrase to use later in the case they lose access to their wallet
Needed
DONE
Wallet
API for generating keys
Developers can provide the standard crypto wallet operations for their users
Needed
DONE
Wallet
Recover wallet from recovery phrase
Users can recover the same account or install the same account on another device
Needed
DONE
Wallet
Setup initial credential (username / password)
User account credential once for multiple uses later (when they will not be asked for the credentials again)
Needed
DONE
Wallet
Delete account from the keybase
Users can delete unwanted account
Needed
DONE
Wallet
Get account balance (local storage or by querying the blockchain)
Users can consult their account balance on the mobile device
Needed
The blockchain already supports getting the current account balance
DONE
Wallet
Full transaction history on mobile
Enable users to see their full transaction history on mobile.
Wanted
LOW - This will likely be implemented by a realm function supported by Gno.
Retrieving the transaction history is not yet implemented on the blockchain. It will probably be similar to the Adena wallet UI from Onbloc.
Not Started
Wallet
Further minor utilities for the keybase data-base
Make it easier for developers to interact with the keybase data-base
Needed
Adding wrappers to the needed functions inside the keys.Keybase object (so it is easier for developers to work with it). Wrap GetByNameOrAddress, GetByName and GetByAddress in gnomobile. Add HasByNameOrAddress, HasByName and HasByAddress.
Make it easier for the users (developers) to use GnoMobile.
Needed
Document the API functions for various development platforms (macOS, Ubuntu, etc.) Make sure the API returns the correct errors. Automate publishing on buf
Make it easier for users (developers) to get started with GnoMobile
Needed
1st example app, “Hello Gno” is built. More will follow
Toolkit
Helper functions to parse the Render output for local mobile device display
Users will be able to read the output of the render functions on their limited (small) mobile display
Wanted
DONE
Toolkit
Write a blog post with a simple example
Create awareness around GnoMobile and increase user understanding of the framework
Needed
1st blog post - DONE; More blog posts and communication efforts will follow even after the completion of M1
We will provide video demos of each feature or feature set as we will complete them. We will provide the links to these videos on the Berty Journey on GitHub and also present them in the regular bi-weekly Gno sync meetings.
Overview of M1 Roadmap, Risks & Assumptions
High-Level Timeline and Duration
M1 Start Date: 11 September 2023.
M1 Estimated Date of Completion: 15 December 2023.
Total duration: ~ 3 months
Work effort estimation
10% Set up project infrastructure (including CI on Github)
30% Develop code to complete the gnoclient API specifically Blockchain Operation functions, present to Gno devs
draft a high-level architecture/tech document of the main technical solution to double-check with Gno devs that we are going in the right direction.
building it and submitting the PR followed by the review and merge process (of course Gno devs will do the review and merge)
15% Implement API Wallet functions which don’t depend on Gno devs support
20% Implement the other API “Wanted” functions as possible given progress of Gno devs
25% Implement examples, skeleton apps, blog post and documentation
Assumptions
It is assumed that Gno developers support will be reasonably timely
It is assumed that the needed new blockchain functionality that is currently under development on Gno side will be made available during the M1 timeline so that we can accommodate the dependent M1 features (like gas estimation or transaction history)
Risks
We will not manage to converge quickly enough with the Gno team regarding the technical solution design of the gnoclient API.
Mitigation 1: we will start discussion with the Gno team in week 1 of M1.
Mitigation 2: we will make a provisional design solution decision on our own if necessary.
A definitive solution for gas estimation is not completed during M1 so we will not be able to provide the Gas Estimation feature in M1.
Mitigation 1: we will put a placeholder in the code to accommodate for the future gas estimation driver
Mitigation 2: we will use a simple default formula for gas estimation
Mitigation 3: we will postpone this feature until after M1
The text was updated successfully, but these errors were encountered:
costinberty
changed the title
GnoMobile, a Gno Framework for Mobile. Implemanation Plan
GnoMobile, a Gno Framework for Mobile. Implementation Plan
Sep 12, 2023
Just updated the Implementation plan (the table above). We added quite a few new items to the initial delivery plan, as we felt the need. All the needed features are done, with some comments here and there, mostly saying that we will make updates once some dependencies will be clarified on Gno side. It was a pleasure working on this :)
GnoMobile
GnoMobile, a Mobile Framework for Gno
Implementation Plan
8 September 2023
This document outlines the plan to build the GnoMobile framework that will enable developers to create mobile applications using Gno. The code repository is found here:
https://github.com/gnolang/gnomobile
Context and Objective
Current Gno apps run on desktop/laptop computers which have Go installed. To run on mobile, the app would need to bundle the Go runtime which is complicated for most developers. However Berty has years of experience with using Go on mobile and overcoming other difficulties of the Android and iOS operating systems. Therefore, in milestone M0 we demonstrate that it is possible to run a Gno app on mobile.
Milestone M0 has two objectives:
GnoMobile System Diagram
For communication between the mobile app and the Gno code, GnoMobile uses gRPC, a well-supported framework which sends and receives Google Protobuf messages. Even though the core Gno code is written in Go, the app code can be React Native, Java, Swift, etc. The following system diagram shows how gRPC is used.
Moving from bottom to top, at the bottom are Go packages in the gno codebase. A gnoclient.Client supports communication with the remote Gno.land node with methods like Call to call a realm function. The gno codebase also has keys.Keybase to support a wallet stored on the local device with methods like CreateAccount.
These methods are called directly from the next level up by the GnoMobile Go code. A Go object can’t be passed through the gRPC interface, so the GnoMobile Go code maintains a persistent gnoclient.Client object which is accessed by gRPC calls. The GnoMobile API functions are registered by an amino package.go file and the generated Protobuf files are used to configure the gRPC server.
Finally at the top of the diagram, the gRPC client in the mobile app communicates with the GnoMobile gRPC server over a local connection using Protobuf messages. A gRPC call can either return an immediate result (for example, GetKeyCount) or an asynchronous gRPC stream object which can return delayed results (for example, a Call to a remote realm function). The gRPC framework uses the Protobuf API to generate convenient API functions in the mobile app’s preferred language (React Native, Java, Swift, etc.).
A video explanation of the system diagram can be found here: https://www.loom.com/share/8a991ae4395b448e8e5cdc1c6f250246
GnoMobile Features for M1 version
For the M1 version of GnoMobile we will focus on implementing the foundational features that will enable the blockchain operations, having in the center the development of the gnoclient API. Additionally, the M1 version will include the main wallet features and some toolkit features to make it easier for developers to code and gain a deeper understanding of the framework.
We will provide video demos of each feature or feature set as we will complete them. We will provide the links to these videos on the Berty Journey on GitHub and also present them in the regular bi-weekly Gno sync meetings.
Overview of M1 Roadmap, Risks & Assumptions
High-Level Timeline and Duration
Work effort estimation
Assumptions
Risks
The text was updated successfully, but these errors were encountered: