GnoMobile, a Gno Framework for Mobile. Implementation Plan

[costinberty]

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:

1. 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
2. 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.).

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.

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.	DONE - gnolang/gno#1313 . https://github.com/gnolang/gno/pull/1316  #66
Wallet	Remember account password during the session	Users will not have to enter password each time they use or switch accounts	Wanted		Standard functionality; otherwise it will be very annoying for users to use GnoMobile	DONE
Toolkit	Implement gRPC in Android and iOS and React Native	Devs will be able to write the mobile app in whatever language they choose while keeping the benefits of the core Gno functionality written in Go.	Needed		Developers will have a clear API with proto files so they will know the types and methods to call to interact with the blockchain.	DONE
Toolkit	gRPC streaming	Prerequisite to implement the functionality to show the progress (bar)	Needed			DONE
Toolkit	Implement gRPC error handling on React Native		Needed			DONE
Toolkit	gRPC Authentication	(only our app can talk to the gRPC server)	Wanted			WIP - Under study by Remi
Toolkit	genproto options to support gRPC	Developers can use gRPC with all its benefits	Needed	LOW - maybe just approving a PR from Gno devs	amino package.go is easier for Go programmers to understand the connection of the Protobuf data structures to the existing Go code	DONE - but waiting for 2 PRs to be merged into the Gno Main (out of scope for M1) https://github.com/gnolang/gno/pull/1213 - MERGED, https://github.com/gnolang/gno/pull/1235 - MERGED
Toolkit	Write install instructions & API documentation	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	https://github.com/gnolang/gnomobile/pull/70 - MERGED. Jeff will add more doc for errors as they become clear.
Toolkit	Build example skeleton apps for Android and iOS	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

[costinberty]

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 :)

[costinberty]

✅ DONE