Architecture

in development

Frontend Layer (Web & Mobile)

Web application (runs in the browser) acts as a secure digital wallet and handles all client side secrets, credentials and cryptography. It's currently based on the T3 (Typescript/Tailwind CSS/tRPC) tech stack and is delivered through Google owned CDN (Firebase Hosting).

It uses DID provided by the Ceramic Key DID library to pass the vSelf Dapp authorization, Wallet Selector for NEAR authorization and integration with NEAR contacts, MetaMask with WalletConnect SDK for authorization in the EVM-compatible chains, including Camino Blockchain. Also we use near-api-js and caminojs to interact with supported chains.

We integrate Magic.link to provide Web3 onboarding without a seed phrase and authentication through an authorization token. And also, we integrate Keypom to support claiming new NEAR accounts on the fly.

Mobile application is developed in Unity and obtained through Google Play here and App Store here. It uses Unity NEAR SDK (currently in development) to pass the authentication. Mobile application sends authenticated requests to API services and communicates with web applications using web sockets.

Web application is developed using Next.js framework and hosted using Firebase. NEAR-compatible production version is available here and development version - here. Camino-compatible staging version is available here and supports Columbus testnet.

All frontend applications use vSelf API for data fetching, session management and for interacting with other vSelf subsystems.

Cloud Layer (API)

As we use Next.js framework it allows us to implement server side logic in Typescript and use it for typesafe endpoints implementation. The cloud based backend can be decoupled in two logical layers. The first part consists of the services directly interacting with user applications, and the other one runs in the cloud and doesn't affect UX directly.

The main vSelf API service serves as a bridge between frontend applications and backend services. It communicates with vSelf databases, smart contracts and any 3rd party APIs which are required. Also it implements authentication and authorization mechanisms (with next-auth) for access control and identity management.

We plan to use Firebase and Google Cloud to host and deploy our dockerized services for a long time, but to avoid any vendor lock, we will be migrating to Kubernetes.

Storage Layer (Database, Storage)

We use hybrid data storage solution for different types of the user personal data.

Social DB is used as an on-chain data storage for public profiles. Public profile data can contain public identity or sub identity information, and user is able to choose witch information she wants to share. Social DB usage requires the NEAR ID, and we provide a smooth on-boarding process for all the users without NEAR wallet.

For access data storage we chose to go with GunDB distributed graph database in the user side. We store there the identity tree and keypairs for different supported chains. It has several distinct features that we find useful and particularly relevant to the web3 world. It provides us with an offline-first storage solution for client side and fast data synchronization protocol with conflict resolution.

The Storage service is responsible for long term storage of immutable data (like big files - source images and text documents), backups. We believe IPFS will be the standard in the near future and we integrate external distributed storage Filecoin and use NFT.Storage gateway.

Backend (Contracts, Indexer, Monitoring)

Deeper backend layer is concerned with business logic inside smart contracts, analytics tools and cloud infrastructure management.

The main part and business logic involving any value transfer is executed and verified on-chain. For this we develop a set of NEAR smart contracts written in Rust (using Rust SDK). For Camino contacts we use Solidity. Until governance mechanisms are developed and tested, we are fully responsible for deployment and migrations. But once vSelf DAO is ready it's possible to pass admin rights to some consortium of users who will make decisions on behalf of the community.

The second one is Indexer service which serves two purposes. First it is responsible for the NEAR blockchain RPC endpoint, so it runs its own instance of NEAR (currently falls back to services like Infura) and makes sure our cloud never loses connectivity to the blockchain network. The second is to watch every blockchain state update and maps all relevant data to our internal representation. For this reason we integrate The Graph Protocol sub-graphs to index NFTs, SBTs and verifiable credentials for each supported chain (NEAR, Camino).

Lastly for monitoring there is a separate service which aggregates analytics and logs from different sources and subsystems. Its goal is twofold - on one hand we need to provide our dev-ops with real-time data on systems health and operational status, on the other hand management needs access to the usage metrics for customer development and feature planning. We use Google Analytics for web & mobile applications, Pagoda & Tenderly to implement the contracts monitoring functionality.

System architecture model

Here is systems architecture C4 model, render is available here. The reference documentation and source model in DSL is published to our documentation repository.