docs-site/src/pages/en/verifier.md

---
title: Verifier
description: The Verifier is decrypting the data and materializing the state of the CRDTs
layout: ../../layouts/MainLayout.astro
---

## Remote Verifier

Here are 3 main use-cases for the remote verifier :

- A specific user wants to run a remote verifier on the server instead of running their verifier locally. This is the case for end-users on platforms that are not supported by Tauri which powers all the native apps.
  The end-user on those platforms has to run a local ngd daemon instead, and access the app in their browser of choice, at the url http://localhost:1440 . Here the breaking of E2EE is acceptable, as the decrypted data will reside locally, on the machine of the user.
  As the web app cannot save decrypted user data yet, it has to reprocess all the encrypted commits at every load.
  In order to avoid this, running a remote verifier on the local ngd is a solution, as the ngd can save the decrypted user's data locally, if the user gave permission for it.
  The API for that use case is `session_start_remote` and the credentials (usually stored in the user's wallet) are extracted from the wallet and passed to ngd.
  The rest of the "session APIs" can be used in the same manner as with a local Verifier. This present JS library connects to the server transparently and opens a RemoteVerifier there.
  The remote session can be detached, which means that even after the session is closed, or when the client disconnects from ngd, the Verifier still runs in the daemon.
  This "detached" feature is useful if we want some automatic actions that only the Verifier can do, be performed in the background (signing by example, is a background task).
  When the NGbox will be available, this feature of "detached verifier" will be used extensively, as the goal of the NGbox is to provide the user with an ngd daemon running 24/7 in a trusted environment (owned hardware located at home or office) that has full access to the decrypted data.
- The second use case is what we call a Headless server (because it doesn't have any wallets connecting to it). It departs a bit from the general architecture of NextGraph, as it is meant for backward compatibility with the web 2.0 federation, based on domain names and without E2EE.
  This mode of operation allows users to delegate all their trust to the server. In the future, we will provide the possibility to delegate access only to some parts of the User's data.
  In Headless mode, the server can be used in a traditional federated way, where the server can see the user's data in clear, and act accordingly. We have in mind here to offer bridges to existing federated protocols like ActivityPub and Solid (via the project ActivityPods) at first, and later add other protocols like ATproto, Nostr, XMPP, and even SMTP ! Any web 2.0 federated protocol could be bridged. At the same time, the bridging ngd server would still be a fully-fledged ngd daemon, thus offering all the advantages of NextGraph to its users, who could decide to port their data somewhere else, restrict the access of the server to their own data, interact and collaborate with other users (of the federation or of the whole NextGraph network) in a secure and private way, and use the local-first NG app and access their own data offline.
- A third use case will be to be able to run some services (in nodeJS or Rust) that have received partial access to the user's data, and can process it accordingly. By example, an AI service like jan.ai, or a SPARQL REST endpoint, an LDP endpoint, an endpoint to fetch data that will be displayed by a headless framework like Astro or any other REST/HTTP endpoint to access some of the user's data.

All of those use cases are handled with the present nodeJS library, using the API described [here](https://www.npmjs.com/package/nextgraph).