# Architecture
#### 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)](https://github.com/t3-oss/create-t3-app) tech stack and is delivered through Google owned CDN **(**[**Firebase Hosting**](https://firebase.google.com/docs/hosting)**)**. It uses [**DID**](https://www.w3.org/TR/did-core/) provided by the [**Ceramic** Key DID library](https://developers.ceramic.network/reference/accounts/key-did/) to pass the vSelf Dapp authorization, [**Wallet Selector**](https://github.com/near/wallet-selector) for [**NEAR**](https://near.org/) authorization and integration with NEAR contacts, [**MetaMask**](https://metamask.io/) with [**WalletConnect**](https://walletconnect.com/) SDK for authorization in the EVM-compatible chains, including [**Camino**](https://camino.network/) Blockchain. Also we use [near-api-js](https://github.com/near/near-api-js) and [caminojs](https://github.com/chain4travel/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**](https://keypom.xyz/) to support claiming new NEAR accounts on the fly. Mobile application is developed in [**Unity**](https://unity.com/) and obtained through Google Play [here](https://play.google.com/store/apps/details?id=com.VSelf.vselfapp) and App Store [here](https://apps.apple.com/ge/app/vself/id1631569446). It uses [**Unity NEAR SDK**](< https://github.com/metaseed-project/metaseed-unity-toolkit>) (currently in development) to pass the authentication. Mobile application sends authenticated requests to API services and communicates with web applications using [web sockets](https://assetstore.unity.com/packages/tools/network/fm-websocket-1-0-155542). Web application is developed using [**Next.js**](https://nextjs.org/) framework and hosted using [**Firebase**](https://firebase.google.com/docs/hosting). NEAR-compatible production version is available [here](https://vself.app/) and development version - [here](https://testnet.vself.app/). Camino-compatible staging version is available [here](https://brands.vself.app/) and supports [Columbus testnet](https://docs.camino.network/about/columbus-testnet/index.html). 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**](https://nextjs.org/) framework it allows us to implement server side logic in[ **Typescript**](https://www.typescriptlang.org/) 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](https://next-auth.js.org/)) for access control and identity management. We plan to use Firebase and [**Google Cloud**](https://cloud.google.com/run) to host and deploy our [dockerized](https://www.docker.com/) services for a long time, but to avoid any vendor lock, we will be migrating to [**Kubernetes**](https://kubernetes.io/). #### Storage Layer (Database, Storage) We use hybrid data storage solution for different types of the user personal data. [**Social DB**](https://github.com/NearSocial/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](broken://pages/80bSDgH4YgjA6l1SuJfL) process for all the users without NEAR wallet. For access data storage we chose to go with [**GunDB**](https://gun.eco/docs/Introduction) distributed graph database in the user side. We store there the[ identity tree](/vself-project-documentation/user-profile-toolkit.md#manage-sub-identities-and-create-public-profiles) 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**](https://ipfs.io/) will be the standard in the near future and we integrate external distributed storage [**Filecoin**](https://filecoin.io/) and use [**NFT.Storage**](https://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**](https://www.rust-lang.org/) (using [**Rust SDK**](https://docs.near.org/sdk/rust/introduction)**).** For Camino contacts we use [**Solidity**](https://docs.soliditylang.org/en/v0.8.19/)**.** 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**](https://infura.io/)**)** 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**](https://thegraph.com/en/) 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**](https://analytics.google.com/analytics/web/provision/#/provision) for web & mobile applications, [**Pagoda**](https://www.pagoda.co/console) & [**Tenderly** ](https://tenderly.co/)to implement the contracts monitoring functionality. #### System architecture model Here is systems architecture [C4 model](https://c4model.com/), render is available [here](< https://structurizr.com/dsl>). The reference documentation and source model in DSL is published to our [documentation](https://github.com/vself-project/docs) repository.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vself-project.gitbook.io/vself-project-documentation/technical-overview/architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.