| `npm run dev` | Starts local dev server at `localhost:3000` |
| `npm run build` | Build your production site to `./dist/` |
| `npm run preview` | Preview your build locally, before deploying |
| `npm run astro ...` | Run CLI commands like `astro add`, `astro check` |
| `npm run astro --help` | Get help using the Astro CLI |
## New to Astro?
Welcome! Check out [our documentation](https://docs.astro.build) or jump into our [Discord server](https://astro.build/chat).
## Customize This Theme
### Site metadata
`src/config.ts` contains several data objects that describe metadata about your site like title, description, default language, and Open Graph details. You can customize these to match your project.
### CSS styling
The theme's look and feel is controlled by a few key variables that you can customize yourself. You'll find them in the `src/styles/theme.css` CSS file.
If you've never worked with CSS variables before, give [MDN's guide on CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) a quick read.
This theme uses a "cool blue" accent color by default. To customize this for your project, change the `--theme-accent` variable to whatever color you'd like:
Astro uses frontmatter in Markdown pages to choose layouts and pass properties to those layouts. If you are using the default layout, you can customize the page in many different ways to optimize SEO and other things. For example, you can use the `title` and `description` properties to set the document title, meta title, meta description, and Open Graph description.
```markdown
---
title: Example title
description: Really cool docs example that uses Astro
layout: ../../layouts/MainLayout.astro
---
# Page content...
```
For more SEO related properties, look at `src/components/HeadSEO.astro`
### Sidebar navigation
The sidebar navigation is controlled by the `SIDEBAR` variable in your `src/config.ts` file. You can customize the sidebar by modifying this object. A default, starter navigation has already been created for you.
Note the top-level `en` key: This is needed for multi-language support. You can change it to whatever language you'd like, or add new languages as you go. More details on this below.
### Multiple Languages support
The Astro docs template supports multiple langauges out of the box. The default theme only shows `en` documentation, but you can enable multi-language support features by adding a second language to your project.
To add a new language to your project, you'll want to extend the current `src/pages/[lang]/...` layout:
```diff
📂 src/pages
┣ 📂 en
┃ ┣ 📜 page-1.md
┃ ┣ 📜 page-2.md
┃ ┣ 📜 page-3.astro
+ ┣ 📂 es
+ ┃ ┣ 📜 page-1.md
+ ┃ ┣ 📜 page-2.md
+ ┃ ┣ 📜 page-3.astro
```
You'll also need to add the new language name to the `KNOWN_LANGUAGES` map in your `src/config.ts` file. This will enable your new language switcher in the site header.
```diff
// src/config.ts
export const KNOWN_LANGUAGES = {
English: 'en',
+ Spanish: 'es',
};
```
Last step: you'll need to add a new entry to your sidebar, to create the table of contents for that language. While duplicating every page might not sound ideal to everyone, this extra control allows you to create entirely custom content for every language.
> Make sure the sidebar `link` value points to the correct language!
If you plan to use Spanish as the the default language, you just need to modify the redirect path in `src/pages/index.astro`:
```diff
<script>
- window.location.pathname = `/en/introduction`;
+ window.location.pathname = `/es/introduction`;
</script>
```
You can also remove the above script and write a landing page in Spanish instead.
### What if I don't plan to support multiple languages?
That's totally fine! Not all projects need (or can support) multiple languages. You can continue to use this theme without ever adding a second language.
If that single language is not English, you can just replace `en` in directory layouts and configurations with the preferred language.
Find the [documentation online here](https://docs.nextgraph.org)
description: list of features available to all users in our native apps and web app
layout: ../../layouts/MainLayout.astro
---
### Official Apps
Here is the list of types of Document you can create in NextGraph. In parenthesis is the type of underlying CRDT used by that type. See the [CRDTs](framework/crdts) article for more details about CRDTs.
Note: (\*) The JSON Editor (in read-write or read-only) is very primitive for now, it has been developed in one day, to showcase the easy binding of JSON data to some Svelte components. It lacks important features like ( insert in array at position. remove at position in array. splice range. remove from map. change type or name of property in map ). Also the general UX is ugly. But it is functional and demonstrate the potential of CRDT on JSON data, that will be leveraged by app developers. Once it will be improved, this Editor and Viewer will be reused for all Data types, including the Yjs based ones, and the Graph one.
Note: (\*\*) The JSON Editor (in read-write or read-only) used here for the Yjs types, is based on svelte-jsoneditor which isn't so easy to use. But it is a good demonstration that the GUIs can be anything. The data layer works fine and that's the most important for now.
Note: (\*\*\*) Containers are used for the Public Store, Protected Store and Private Store homepages.
Please note that apart from those 3 stores, creating new containers is not really useful yet as you have to add the triple `ldp:contains` manually with SPARQL Update if you want any document to be part of the container.
description: NextGraph supports several CRDTs natively, and is open to integrating more of them in the future. more about the Unified data model and features of our CRDTs
layout: ../../layouts/MainLayout.astro
layout: ../../../layouts/MainLayout.astro
---
<style>
@ -16,12 +16,34 @@ For now, we offer:
- **Graph** CRDT : the Semantic Web / Linked Data / RDF format, made available as a local-first CRDT model thanks to an OR-set logic (Observe Remove Set) formalized in the paper SU-set (SPARQL Update set). This allows the programmer to link data across documents, globally, and privately. Any NextGraph document features a Graph, that enables connecting it with other documents, and representing its data following any Ontology/vocabulary of the RDF world. Links in RDF are known as predicates and help establishing relationships between Documents while qualifying such relation. Learn more about RDF and how it allows each individual key/value to point to another Document/Resource, similar to foreign keys in the SQL world. With the SPARQL language you can then traverse the Graph and navigate between Documents.
- **Automerge** CRDT: A versatile and compact format that offers sequence and set operations in an integrated way, that lets all types be combined in one document. It is based on the formal research of Martin Kleppmann, Geoffrey Litt et.al and the Ink & Switch lab, and implements the RGA algorithm (Replicated Growable Array). Their work brought the formalization of Byzantine Eventual Consistency, upon which NextGraph builds its own design. Automerge offers a rich text API (Peritext) but we do not expose it in NextGraph for now, preferring the one of Yjs for all rich text purposes.
- **Automerge** CRDT: A versatile and compact format that offers sequence and set operations in an integrated way, that lets all types be combined in one document. It is based on the formal research of Martin Kleppmann, Geoffrey Litt et al. and the Ink & Switch lab, and implements the RGA algorithm (Replicated Growable Array). Their work brought the formalization of Byzantine Eventual Consistency, upon which NextGraph builds its own design. Automerge offers a rich text API (Peritext) but we do not expose it in NextGraph for now, preferring the one of Yjs for all rich text purposes.
- **Yjs** CRDT: Well-known and widely-used library based on the YATA model. It offers an efficient and robust format for sequences and sets. On top of those primitives, the library offers 4 formats: XML (used by all rich-text applications), plain text, maps (like JSON objects), and arrays (aka lists). We use the XML format for both the "Rich text" and "MarkDown" documents, and offer the 4 formats as separated **classes** of discrete documents for the programmer to use. We all thank Kevin Jahns for bringing this foundational work to the CRDT world.
In the future, we might want to integrate more CRDTs into NextGraph, specially the promising LORO or json-joy, or older CRDTs like Diamond Types.
If you are not familiar with CRDTs, here are some nice introductions you can read about that subject. TODO.
## Semantic Web, Linked Data, RDF
If the Semantic Web and RDF are still unknown to you, we have selected some good introductory materials here. TODO.
The essential information to understand about RDF is that it encodes the data in the form of triples, which are composition of 3 elements.
The 3 elements are called : `Subject -> Predicate -> Object`. That's one triple. The semantic database is just a set of triples.
The subject represents the Resource we are establishing facts about. The Predicate indicates the "key" or "property" we want to specify about the Resource. And the Object represents the "value".
Hence, if we want to say that "Bob owns a bicycle", then we write it this way : `Bob -> Owns -> Bicycle`. We can also say that `Bob -> color_of_eyes -> Blue` and so on.
In addition, the values (aka, the Object part of the triple) can also be a reference to another Resource. So basically we can link Resources (Subjects) together.
If we have a triple saying `Alice -> lives_in -> Wonderland`, then we can also say that `Bob -> is_friend_with -> Alice`. Here we have linked the 2 Resources together, and the Predicate `is_friend_with` is not just a property, but it is in fact a `relationship`. If Alice also considers Bob as a friend, then we could say the inverse relationship `Alice -> is_friend_with -> Bob`.
We understand that the Predicates of the RDF world, are corresponding to the keys and properties of the JS/JSON world. Values of the JS world are equivalent to Objects of RDF, although in JS, you cannot encode a link to another (possibily remote) Resource as a value.
Finally, the Subject of a resource is its unique identifier. NextGraph assigns a unique ID to each Document, and that's the Subject of the triples it contains. As an analogy, the same could be done in JSON by giving a unique name to a JSON file, or to a JS variable (POJO) holding some map of key/values.
## 3 parts of a Document
A Document in NextGraph is composed of 3 parts :
@ -42,60 +64,60 @@ As you will see in the **branch** section below, the programmer decides which CR
Now let's have a look at what those CRDTs have in common and what is different between them. We have marked 🔥 the features that are unique to each model and that we find very cool.
| <tdcolspan=3> (aka property/value, and in RDF, it is called predicate/object) this is the basic feature that the 3 models offer. You have a Document, and you can add key/value pairs to it. Also known as Map or Object. |
| <tdcolspan=3> Thanks to the Ontology/Schema mechanism of RDF (OWL), the schema information is embedded inside the data (with what we call a Predicate), thus avoiding any need for schema migration. Also, it brings full data interoperability as many common ontologies already exist and can be reused, and new ones can be published or shared |
| **nested** | ✅ blank nodes | ✅ | ✅ |
| <tdcolspan=3> key/value pairs can be nested (like in JSON) |
| **sequence** | ❌ \* | ✅ | ✅ |
| <tdcolspan=3> And like in JSON or Javascript, some keys can be Arrays (aka list), which preserve the ordering of the elements. (\*) In RDF, storing arrays is a bit more tricky. For that purpose, Collections can encode order, but are not CRDT based nor concurrency safe |
| **sets** | 🔺 multiset | ✅ | ✅ |
| <tdcolspan=3> RDF predicates (the equivalent of properties or keys in discrete documents) are not unique. they can have multiple values. that's the main difference between the discrete and graph models. We will offer the option to enforce rules on RDF data (with SHACL/SHEX) that could force unicity of keys, but that would require the use of **Synchronous Transactions**. |
| <tdcolspan=3> allows concurrent edits on the value of a property that is a string. this feature is only offered by Automerge. Very useful for collaborative forms or tables/spreadsheets by example! |
| **multi-lingual strings** | ✅ 🔥 | ❌ | ❌ |
| <tdcolspan=3> Store the value of a string property in several languages / translations |
| **Counter CRDT** | ❌ | ❌ | ✅ 🔥 |
| <tdcolspan=3> Counters are a safe way to manage integers in a concurrent system. Automerge is the only one offering counters. Please note that CRDT types in general are "eventual consistent" only (BASE model). If you need stronger guarantees like the ones provided by ACID systems (specially guaranteeing the sequencing of operations, very useful for preventing double-spending) then you have to use a **Synchronous Transaction** in Nextgraph. |
| <tdcolspan=3> (\*) discrete data cannot link to external documents. This is the reason why all Documents in NextGraph have a Graph part, in order to enable inter-linking of data and documents across the Global Giant Graph of Linked Data / Semantic Web |
| **Float values** | ✅ | 🟧 | ✅ |
| <tdcolspan=3> Yjs doesn't enforce strong typing on values. they can be any valid JSON (and Floats are just Numbers). |
| **Date values** | ✅ | ❌ | ✅ |
| <tdcolspan=3> JSON doesn't support JS Date datatype. So for the same reason as above, Yjs doesn't support Dates. |
| **Binary buffer values** | ✅ \* | ✅ | ✅ |
| <tdcolspan=3> (\*) as base64 or hex encoded. please note that for all purposes of storing binary data, you should use the **binary files** facility of each Document instead, which is much more efficient. |
| **boolean, integer values** | ✅ | ✅ | ✅ |
| **NULL values** | ❌ | ✅ | ✅ |
| **strongly typed decimal values** | ✅ | ❌ | ❌ |
| <tdcolspan=3> signed, unsigned, and different sizes of integers |
| **revisions, diff, revert** | 🟧 | 🟧 | 🟧 |
| <tdcolspan=3> 🔥 implemented at the NextGraph level. work in progress. You will be able to see the diffs and access all the historical data of the Document, and also revert to previous versions. |
| **compact** | ✅ | ✅ | ❓ |
| <tdcolspan=3> compacting is always available as a feature at the NextGraph level (and will compact Graph and Discrete parts alike). Yjs tends to garbage collect deleted content. not sure if automerge does it. Compact will remove all the historical data and deleted content (you won't be able to see diffs nor revert, for all the causal past happening before the compact operation. but normal CRDT behaviour can resume after) . This is a synchronous operation. |
| **snapshot** | ✅ | ✅ | ✅ |
| <tdcolspan=3> take a snapshot of the data at a given HEADs, and store it in a non-CRDT way so it can be opened quickly. Also removes all the historical and deleted data. But a snapshot cannot be used to continue collborating on the document. See it as something similar to "export as a static file". |
| **isolated transactions** | ✅ | ✅ | ✅ |
| <tdcolspan=3> A NextGraph transaction can atomically mutate both the Graph and the Discrete data in a single isolated transaction. Can be useful to enforce consistency and keep in sync between information stored in the discrete and graph parts of the same document. but: transactions cannot span multiple documents (for that matter, see **smart contracts**). When a SPARQL Update spans across Documents, then the Transaction is split into several ones (one for each target Document) and each one is applied separately, meaning, not atomically. Also, keep in mind, as explained above in the "Counter" section, that CRDTs are eventually consistent. If you need ACID guarantees, use a synchronous transaction instead. |
| <tdcolspan=3> 🔥 this is planned. will be available shortly. the store will be **writable** and will allow a bidirectional binding of the data to some javascript reactive variables in Svelte (same could be done for React/Redux) and we are considering the use of **Valtio** for a generic reactive store, that would also work on nodeJS and Deno |
| <tdcolspan=3> (\*) support is planned at the NextGraph level, to be able to query discrete data too in SPARQL. (GraphQL support could then be added) |
| **export/import JSON** | ✅ JSON-LD | ✅ | ✅ |
| | | | |
| **Rich Text** | N/A | attributes on XMLElement | [Marks and Block Markers](https://automerge.org/docs/documents/rich_text/) and [here](https://automerge.org/docs/under-the-hood/rich_text_schema/) |
| <tdcolspan=3> Yjs integration for ProseMirror and Milkdown is quite stable. Peritext is newer and only offers ProseMirror integration. For this reason we use Yjs for Rich Text. Performance considerations should be evaluated too. |
| **Referencing rich text from outside** | N/A | ✅ 🔥 [Relative Position](https://docs.yjs.dev/api/relative-positions) | ✅ [get_cursor](https://automerge.org/automerge/automerge/trait.ReadDoc.html#tymethod.get_cursor) |
| <tdcolspan=3> useful for anchoring comments, quotes and annotations (as you shouldn't have to modify a document in order to add a comment or annotation to it). |
| **shared cursor** | N/A | 🟧 \* | 🟧 \* |
| <tdcolspan=3> (\*) available in lib but not yet integrated in NextGraph |
| <tdcolspan=3> (aka property/value, and in RDF, it is called predicate/object) this is the basic feature that the 3 models offer. You have a Document, and you can add key/value pairs to it. Also known as Map or Object. |
| <tdcolspan=3> Thanks to the Ontology/Schema mechanism of RDF (OWL), the schema information is embedded inside the data (with what we call a Predicate), thus avoiding any need for schema migration. Also, it brings full data interoperability as many common ontologies already exist and can be reused, and new ones can be published or shared |
| **nested**| ✅ blank nodes | ✅ | ✅ |
| <tdcolspan=3> key/value pairs can be nested (like in JSON) |
| **sequence**| ❌ \* | ✅ | ✅ |
| <tdcolspan=3> And like in JSON or Javascript, some keys can be Arrays (aka list), which preserve the ordering of the elements. (\*) In RDF, storing arrays is a bit more tricky. For that purpose, Collections can encode order, but are not CRDT based nor concurrency safe |
| **sets**| 🔺 multiset | ✅ | ✅ |
| <tdcolspan=3> RDF predicates (the equivalent of properties or keys in discrete documents) are not unique. they can have multiple values. that's the main difference between the discrete and graph models. We will offer the option to enforce rules on RDF data (with SHACL/SHEX) that could force unicity of keys, but that would require the use of **Synchronous Transactions**. Sets are usually represented in JS/JSON with a map, of which the values are not used (set to null or false), because keys are unique, so we use the keys to represent the set. In RDF, keys are not unique, but a set can be represented by choosing a single key (a predicate) and its many values will represent the set, as a pair "key/value" is unique (aka a "predicate/object" pair). |
| <tdcolspan=3> allows concurrent edits on the value of a property that is a string. this feature is only offered by Automerge. Very useful for collaborative forms or tables/spreadsheets by example! |
| **multi-lingual strings**| ✅ 🔥 | ❌ | ❌ |
| <tdcolspan=3> Store the value of a string property in several languages / translations |
| **Counter CRDT**| ❌ | ❌ | ✅ 🔥 |
| <tdcolspan=3> Counters are a safe way to manage integers in a concurrent system. Automerge is the only one offering counters. Please note that CRDT types in general are "eventual consistent" only (BASE model). If you need stronger guarantees like the ones provided by ACID systems (specially guaranteeing the sequencing of operations, very useful for preventing double-spending) then you have to use a **Synchronous Transaction** in Nextgraph. |
| <tdcolspan=3> (\*) discrete data cannot link to external documents. This is the reason why all Documents in NextGraph have a Graph part, in order to enable inter-linking of data and documents across the Global Giant Graph of Linked Data / Semantic Web |
| **Float values**| ✅ | 🟧 | ✅ |
| <tdcolspan=3> Yjs doesn't enforce strong typing on values. they can be any valid JSON (and Floats are just Numbers). |
| **Date values**| ✅ | ❌ | ✅ |
| <tdcolspan=3> JSON doesn't support JS Date datatype. So for the same reason as above, Yjs doesn't support Dates. |
| **Binary buffer values**| ✅ \* | ✅ | ✅ |
| <tdcolspan=3> (\*) as base64 or hex encoded. please note that for all purposes of storing binary data, you should use the **binary files** facility of each Document instead, which is much more efficient. |
| **boolean, integer values**| ✅ | ✅ | ✅ |
| **NULL values**| ❌ | ✅ | ✅ |
| **strongly typed decimal values**| ✅ | ❌ | ❌ |
| <tdcolspan=3> signed, unsigned, and different sizes of integers |
| **revisions, diff, revert**| 🟧 | 🟧 | 🟧 |
| <tdcolspan=3> 🔥 implemented at the NextGraph level. work in progress. You will be able to see the diffs and access all the historical data of the Document, and also revert to previous versions. |
| **compact**| ✅ | ✅ | ❓ |
| <tdcolspan=3> compacting is always available as a feature at the NextGraph level (and will compact Graph and Discrete parts alike). Yjs tends to garbage collect deleted content. not sure if automerge does it. Compact will remove all the historical data and deleted content (you won't be able to see diffs nor revert, for all the causal past happening before the compact operation. but normal CRDT behaviour can resume after) . This is a synchronous operation. |
| **snapshot**| ✅ | ✅ | ✅ |
| <tdcolspan=3> take a snapshot of the data at a given HEADs, and store it in a non-CRDT way so it can be opened quickly. Also removes all the historical and deleted data. But a snapshot cannot be used to continue collborating on the document. See it as something similar to "export as a static file". |
| **isolated transactions**| ✅ | ✅ | ✅ |
| <tdcolspan=3> A NextGraph transaction can atomically mutate both the Graph and the Discrete data in a single isolated transaction. Can be useful to enforce consistency and keep in sync between information stored in the discrete and graph parts of the same document. but: transactions cannot span multiple documents (for that matter, see **smart contracts**). When a SPARQL Update spans across Documents, then the Transaction is split into several ones (one for each target Document) and each one is applied separately, meaning, not atomically. Also, keep in mind, as explained above in the "Counter" section, that CRDTs are eventually consistent. If you need ACID guarantees, use a synchronous transaction instead. |
| **Svelte5 reactive Store (Runes)**| 🟧 | 🟧 | 🟧 |
| <tdcolspan=3> 🔥 this is planned. will be available shortly. the store will be **writable** and will allow a bidirectional binding of the data to some javascript reactive variables in Svelte (same could be done for React/Redux) and we are considering the use of **Valtio** for a generic reactive store, that would also work on nodeJS and Deno |
| <tdcolspan=3> (\*) support is planned at the NextGraph level, to be able to query discrete data too in SPARQL. (GraphQL support could then be added) |
| **export/import JSON**| ✅ JSON-LD | ✅ | ✅ |
| | | | |
| **Rich Text**| N/A | attributes on XMLElement | [Marks and Block Markers](https://automerge.org/docs/documents/rich_text/) and [here](https://automerge.org/docs/under-the-hood/rich_text_schema/) |
| <tdcolspan=3> Yjs integration for ProseMirror and Milkdown is quite stable. Peritext is newer and only offers ProseMirror integration. For this reason we use Yjs for Rich Text. Performance considerations should be evaluated too. |
| **Referencing rich text from outside**| N/A | ✅ 🔥 [Relative Position](https://docs.yjs.dev/api/relative-positions) | ✅ [get_cursor](https://automerge.org/automerge/automerge/trait.ReadDoc.html#tymethod.get_cursor) |
| <tdcolspan=3> useful for anchoring comments, quotes and annotations (as you shouldn't have to modify a document in order to add a comment or annotation to it). |
| **shared cursor**| N/A | 🟧 \* | 🟧 \* |
| <tdcolspan=3> (\*) available in lib but not yet integrated in NextGraph |
description: Define and use Smart Contracts to manage multi-party business processes like logistics, supply chain, e-commerce, with cross-document transactions.
The "Getting started" guide will be available soon.
Get started and try our official App by [installing it](https://nextgraph.org/download/), or using the web app at [nextgraph.eu](https://nextgraph.eu).
If you want to know more, have questions or want to get in touch with us, the simplest way is to join the [forum](https://forum.nextgraph.org).
The App is available for
For bug reports, please create an account and submit a new issue in our [Gitea instance](https://git.nextgraph.org/NextGraph).
- Android
- iOS(soon)
- Linux, specially Ubuntu
- macOS
- Windows
Stay tuned by subscribing to our [newsletter](https://list.nextgraph.org/subscription/form).
For unsupported devices, we offer a web version at [nextgraph.eu](https://nextgraph.eu), and will also provide a local install based on ngd soon.
#### Create a Wallet
The first step that is waiting for you when you start using our apps, is to create a Wallet for yourself.
The purpose and procedure is described within the app. Please follow the steps one by one. This process is a bit long at the first launch, but it is necessary. The wallet enables your digital sovereignty and independence.
We at NextGraph will never see your wallet nor its content. When you create your wallet, there is no access to the internet that is needed. Your wallet stays local, on your device. Only your encrypted documents are sent to the Broker.
For this reason, you will have to export and import your wallet from the first device where you created it, towards the other devices that you want to use.
We have made the transfer of the wallet easy, and you have several options. The easiest one is to use a **QR-Code** that will be displayed on one of your device, and that you can scan from the other device.
If this is not available to you (if none of your devices has a camera) then you can use the TextCode option, or transfer your Wallet File with a USB key. Those other options are also described inside the app. You can also find more information about that in the [Wallet section](wallet) here below.
#### Choose a Broker
All the apps (native or web) need to have a Broker configured in order to operate well. This is due to the **2-tier** decentralized peer-to-peer network of NextGraph.
When you create your wallet, you will be asked to select a Broker. This is a server that is running 24/7 and that will help you synchronize your data with all your devices and with other users.
For now, we only offer you one Broker (nextgraph.eu) located in France. In the future, there will be other options too with Brokers available in other countries, and also with the option to self-host your own broker.
You will be able to change your broker later on. Your data will move to the new broker and all your documents will be accessible from the new broker. With NextGraph, all your data is totally **portable** and there is no fear to have with being locked-in with one provider or another. All your contacts will be transparently informed that you have moved your account to another Broker and everything will work seamlessly.
#### Use the App
Once your wallet is created and you are entering the App main screen for the first time, you will have to learn how to use it. here is a brief introduction to the App.
You have created a Wallet, and inside this wallet, there is one default `Identity` that represents you. This identity is called **personal** because it represents you as an individual. You can later create more Identities if you want to separate your work life and your personal life, by example, or for other purposes of keeping your identities separated.
Within each Identity, your data is organized into **3 different Stores**.
##### Stores
- the public store : is equivalent to your website, blog, or public profile on social networks. You can put in this store all the documents, pictures, videos, posts, data, etc... that you want everybody to have access to, without the need for special permissions.
- the protected store : is a space where you can share data, documents, and media with other users, but they will need a special link and permission in order to access them and collaborate with you on those documents (or just read them). You can also create Groups here when you want to chat or collaborate with several users. This store also acts as your protected profile for social networks. Only your followers will be able to see this profile, as it is not public.
- the private store : this is a place where you put only private and personal information that only you has access to. This store will be accessible to all your devices, so it is useful in order to synchronize private data between them. You can put sensitive data too, as everything is encrypted. Nobody else will every see this data. it is not possible to share the documents of your private store.
You can also later, move documents from one store to another, if you are the owner of such document.
When you arrive in the App, the first screen that you see, and this is your Homepage, is in fact, your private store, where you can organize your personal data.
Then you can access your protected store with the icon that represents 2 users.
And your public profile/store can be found with the icon that represents one user.
##### Documents
The app is based on the concept of Documents. Everything is a Document in NextGraph. Even your 3 stores' homepage are Documents themselves.
If you want to post some article, text, image or video on social media, those are considered a Document, that you send to your Stream.
If instead, you want to add some content to your public or protected profile, you just create a document there and it will add itself to the grid of content visible on the profile (like on instagram).
You want to write an email? you create a document, and then send it via email from within the app (this feature will come soon).
You want to collaborate with someone on a document? create it in your protected store, and select a contact to share it with.
You want to add a new contact ? this is also a tiny document, that represents the contact information of the person.
Each document has a **type** (which is called a "primary class" internally) and you have to select this type before you create it.
The full list of available types is detailed in the [features](features) section below. It is also visible within the app, when you want to create a new Document (with the "plus" button).
Documents can be moved from one place to another within the store. You can reorganize your store as you like, with the help of `containers` and soon with `folders` too.
You can read more about [Documents and Stores](documents) in the corresponding section below.
##### Document Menu
We bring your attention shortly on the Document's Menu that is accessible from the button with 3 vertical dots, at the top right corner of the screen.
Each Document has a double nature :
- it has a _Document-like_ nature where you can store and edit some rich-text, or just some data, according to the class of the Document that you have chosen. This is so far very consistent with what we expect from a document in general. All the apps that you use with NextGraph, will store their data inside these Documents.
- A Document also has a _Graph_ nature, which is something new that NextGraph added (hence the name "NextGraph"). This "graph nature" of the document let's you link this document to other documents. It also let's you enter some specific data or meta-data about this document, that will be part of the Graph of all your documents. This graph is something important, that you are not used to. Social networks are all based on a Graphs. The Web itself is a huge Graph. When you follow or get followed, when you like or comment on a Post, when you write a DM to someone, all this information is stored as a Graph, that connects different documents together. Later, you will probably need to _query_ this graph. This is done transparently when you want to see all your followers, and when you want to consult the **stream** of all the posts that they have published recently, or when you want to search for something. It is also used for recommendations. But in any case, what is important to understand is that internally, each Document can be linked to any other Document (like the classical Web that links webpages) and that the applications you will use on NextGraph, will also store more Graph information. Because NextGraph is local-first and decentralized, this **graph** information is available to you at all time. And if you want to see it, you can go to any Document and in the Document Menu, you can select "Graph" and you will see options to view and edit the Graph. This is a bit technical for now (you will see things like Turtle, SPARQL etc) but in the future, we will provide here some nice tools where you will be able to explore your own graph easily.
##### Viewer and Editor
Also from this Document Menu, you always have the option to switch from the 2 different modes:
- Viewer mode
- Editor mode.
A document always opens in Viewer mode (read-only) and if you want to modify it, you have to go to the Document menu to select an Editor.
For now, only one editor is provided for each Document type, but in the future, you will be able to install more Editors, and also more viewers.
If you open the same document in 2 different tabs or browser windows, or with different apps (on mobile, desktop, etc), and when you edit the Document in one of the window, it automatically updates itself in the viewer or editor that is opened in the other window(s). Try it! it works great.
But please pay attention to the fact that by default, the **live editing** mode is not activated, and instead, you have to click on the blue mark button that appears at the top right corner of the screen, in order to **save** your changes.
If you want to switch to **live editing** you can do so with the toggle button accessible from the Document Menu.
If you are editing a text document, please pay attention to the fact that live editing is going to send each character one by one, and this has a huge data size overhead/amplification, as each character will be encrypted and sent in our network, separately.
Viewers and Editors are what we call "Apps". And they can be installed from the built-in App Store (not ready yet, but will be available soon)
NextGraph comes with a set of Official Apps (listed in [Features](features)) and developers can create new apps.
##### Attachments and Files
From the Document Menu, you will see many other options, most of them are not implemented et, and will not do anything when clicked. There are there to tease you about the upcoming features ;)
Two menu options are implemented for now : History and "Attachments and Files".
The later is, as its name indicates, about adding some images or any other attachment file to the Document. Images will be useful when you want to insert some picture in a Rich-Text document (not available yet. but you can already add pictures in the Attachments and Files).
##### History
History is another Pane that is already implemented. It shows all the history of modifications on the Document.
You will be able (in the future) to select a specific revision and "revert" to it. Or to see more details about each modification (that are called "Commits").
Because NextGraph is local-first and based on CRDTs, if you modify the Document concurrently from 2 different devices while being offline on one or both of the devices, then a temporary "fork" will happen on the Document History. This is visible with a new colored branch that will pop out of the blue branch.
Once the two devices will be back online, you will see tha they will automatically synchronize themselves and the "fork" will be automatically "merged". The colored branch will come back to the blue main branch.
##### User Panel
The User Panel is another menu that is accessible from the Logo of NextGraph at the left top corner of the screen.
It offers some options to manage your connection to the Broker, your wallet, your account, and in the future, some settings.
You can also "logout" from this menu, which will close your wallet.
There is also an option to disconnect from the broker (with the blue toggle button called "Personal") in order to simulate a loss of internet connectivity.
If your internet connection is down, you can also see the status here ( there will be a red Offline sign ).
The App always tries to connect to the Broker every 5 seconds.
##### Magic carpet
You might ask yourself what the magic carpet is.
It is not functional yet, but it wil lbe something like a "clipboard" where you can store temporary data.
But unlike the clipboard we are used to (with CMD+C and CMD+V), the Magic Carpet can keep a list of many items. This is useful when you want to move things around. Also the Magic Carpet is always reachable from anywhere in the app, and let's you drag and drop things.
Stay tuned for more features, by checking out the [roadmap](roadmap).
We are still lagging behind on the documentation part. Sorry about that. But the situation will improvement very soon. Please bare with us for a few more weeks. Thank you!
NextGraph is an Open Source **App and a Platform** that anybody can use for free. Individuals and Organizations, SMEs and corporations will enjoy a rich set of features ranging from Document sharing, collaborative and productivity tools, to a Social Network, Smart contracts and more.
If you have questions or want to get in touch with us, the simplest way is to join the [forum](https://forum.nextgraph.org).
> NextGraph is secure, privacy-preserving, decentralized, and local-first (it can work online and offline too).
For bug reports, please create an account and submit a new issue in our [Gitea instance](https://git.nextgraph.org/NextGraph).
In addition, NextGraph is also a [Framework](./framework) for App developers who want to adapt their existing app to NextGraph, or create new apps that will be based on the new principles that we want to foster and that will bring the advent of a New Internet, Next Generation Internet, call it Web 3.0 or Web 4.0, small web, whatever you want, as long as it is secure, privacy preserving, decentralized, interoperable, and easy to use!
Stay tuned by subscribing to our [newsletter](https://list.nextgraph.org/subscription/form).
We aim at becoming a serious alternative to the Big-Tech products and services, and to gather forces among the Free and Open Source communities (FOSS) in order to offer the best experience to end-users and programmers alike, with easy-to-use applications where the user regain **total control over their data, privacy and software**.
You can read more about NextGraph on [our website](https://nextgraph.org).
#### App & Platform
[Get started](getting-started) with our official App by [installing it](https://nextgraph.org/download/), or using the web app at [nextgraph.eu](https://nextgraph.eu).
You should read the [Getting started](getting-started) guide as it explains how to use the app for the first time.
Try it and discover all the features we are offering you.
More documentation about the App and the Platform can be found in the [following sections](./local-first) and you can see a list of [features here](./features) and a [roadmap](./roadmap) of the forthcoming ones.
You can find help in the [FAQ section](help) where frequently asked questions have been answered.
If you have any more questions or want to get in touch with us, the simplest way is to join the [forum](https://forum.nextgraph.org). For bug reports, please create an account and submit a new issue in our [Gitea instance](https://git.nextgraph.org/NextGraph). Stay tuned by subscribing to our [newsletter](https://list.nextgraph.org/subscription/form).
#### Framework
As a programmer, you can develop apps with our Framework and benefit from all the features of our platform.
Built applications that are **secure and privacy-preserving**, **local-first**, that sync their data automatically without any conflicts, that work offline and online, that do not depend on any third-party and paying infrastructure, and that are **data-centric, interoperable, and portable**.
Our framework is available for web and native apps, developed in Javascript/Typescript with Front-end frameworks like React or Svelte, and also in Rust, and optionally with Tauri framework. Your app can integrate the NextGraph [ecosystem](ecosystem) with our built-in App Store, or can stay "standalone" and remain independent from our official apps.
You can also develop **services**, based on NodeJs/Deno or Rust, and access the data in order to process it (subject to previous authorization from the user).
Discover more about the features of our framework and [get started](framework/getting-started) with your first app in the following sections.
#### Design, Reference & Specifications
If you are curious about how NextGraph works internally, you can find more information about that in the [Design](design) section.
The reference on all our APIs and SDKs, including the specifications of our protocols and formats can be found in the [Reference](specs) section.
description: NextGraph aims to offer a robust, private, secure and easy to use Social Network and Platform, as an alternative to the Big Tech offers (Meta Facebook Instagram Threads TikTok X Twitter) while being compatible with ActivityPub, Nostr, BlueSky and ATproto
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).
