Please bare with us as we are currently writing/publishing the documentation (23 of August until 28 of August 2024).
The NextGraph official apps have been designed with accessibility in mind.
But unfortunately, we did not have enough time for now to test it with a screen reader.
We will do so in the coming months in order to offer you the best experience if you have special needs for accessibility.
#### About translation
Our apps are available in several languages, but we are still in the process of establishing a reliable translation mechanism, and for now, only the German translation is available.
We will add more translations very soon, and will also ask for your help in translating the apps to your language, if your language isn't available yet.
Everything in NextGraph, every data, is stored inside a Document.
That's a central concept, that is not that hard to grasp.
That's a central concept, that is not that hard to grasp, and that has been adopted in database like MongoDB and CouchDB.
A Document contains some content (that varies with the format).
A Document contains some content (that varies with the format. In our case, RDF, JSON, plain text or XML). All the Documents of a user form a local database that can be queried and updated within transactions.
Each Document synchronizes itself between all your devices, and with the users that you shared it with (if any).
Each Document transparently synchronizes itself between all your devices, and with the users that you shared it with (if any).
### Dual nature of a Document: Sun vs. Cloud
Each Document has a double nature :
It has a **_Document-like_** nature where you can store and edit some rich-text, plain-text, or just some JSON or XML data, according to your needs and the primary class of the Document that you have chosen when you created it. This is so far very consistent with what we expect from a document in general. All the apps that you use or develop with NextGraph, will store their data inside these Documents. The Document-like nature is represented with a "cloud" icon. A note for developers: In the internals of NextGraph, the Document-like nature of a Document is called "discrete", because otherwise it is too many things that are called "document".
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 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. The Graph-like nature is represented with a "sun" icon. The Graph part of the document is stored in the RDF format.
In addition, you can also attach some **binary files** to any Document. Those files are immutable in the sense that you can add them or delete them, but you cannot modify their content.
So to recap, in a Document we have :
- the **Graph** part (some RDF triples). This is mandatory and always available in all documents, even if left empty.
- the **Discrete** part (some JSON, XML or plain-text. based on Yjs or Automerge CRDTs). This can be optional, meaning that it is possible to create a purely graph\*based document that doesn't hold any discrete part.
- some optional **binary files** attached to the document.
If you are curious about why we implemented this dual nature of documents, read more about that in the [CRDTs chapter](/en/framework/crdts).
### Repository
Each NextGraph document is stored in a separate repository, that holds all the changes (that we call "commits") and also all the [permissions](/en/framework/permissions). The commits of such repository mutate both the RDF resource and the discrete document.
Each Document is identified with a **unique identifier**, that is a public key randomly generated at creation time. This ID will never change over time. Internally we call this a RepoID.
It is a permanent ID of the form `did:ng:o:[44 chars of the ID]` by example `did:ng:o:EghEnCqhpzp4Z7KXdbTx0LkQ1dUaaqwC0DGVS-0BAKAA`.
This Identifier is a valid URI that can be used to link a document with another (both in the rich-text or in the RDF data, as subject, object or even predicate i a document is used to define an ontology). We call it **NURI**, for NextGraph URI.
It follows the **DID** (Decentralized Identifier) format, and an adhoc DID Method will be specified and registered shortly.
#### Type of a Document (primary class)
When you create a new Document, you first have to select its **type**, which is also called "primary class" internally.
There are already several types proposed to you (not all of them are currently implemented. see a list in [features](/en/features), and App developers can add new types.
Here is a short list of the most used types :
- Post or Article : a rich text document that can contain links, images, bold, italic, embeds etc...
- Markdown : the same, but using the MarkDown format.
- Plain Text : just some text.
- Contact : represents a person you know or about whom you have contact details.
- Event : An event that has a date and a place and that other people are invited to.
- Form : a form that needs to be filled-in.
- Spreadsheet : columns, rows and cells to store numeric and text values, with formulas.
- Chart : a visual representation of some data
- Geo Map : a geographical map that contains some markers
- etc...
In order to create a new Document, you can use the "plus" button on the main screen of the App.
#### Viewer, Editor and Apps
A document can be opened in
- Viewer mode or in
- Editor mode (if you have permission to edit the document, of course)
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. The "Document menu" is accessible from any Document, by clicking on the "3 vertical dots" button at the top-right corner of the screen.
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 windows, 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 instead you want to switch to **live editing** you can do so with the toggle button of the same name, 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](/en/features) that are always available (they don't need to be installed), and developers can also create new apps, that will need to be installed by the final user (but when the user receives a link to a Document for which they don't have the necessary app installed, we will propose them to install this missing app automatically).
#### History
Each document keeps track of the whole history of modifications. This is accessible from the History pane, from within the Document menu.
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 that they will automatically synchronize themselves and the "fork" will be automatically "merged". The colored branch will come back to the blue main branch. This is what CRDTs are all about. It syncs and merges all your changes, without any conflict, so it can do that transparently without asking you what to do (unlike "git", for those who know what "git" is).
You can try this between 2 tabs in your browser, or a browser tab and a native app, or 2 different native apps (desktop and android by example). It works great!
### Blocks and Branches
We just explained that a Document has a type (a primary class) and that it keeps all the changes (called Commits) in a history.
To be more precise, this primary class and all those commits, are not stored for each Document, but for each Branch within a Document. What is a branch ? And why can a document contain several branches?
A **branch** is a concept that helps us separate the data within a single document, and it can be used in several ways.
- A document can be composed of several blocks. Imagine the blocks like separate paragraphs in a text document, or separate embeds (video, table, spreadsheet, etc...) of content that come from other documents or that have different types, and you want to assemble all those blocks into one document. So you select those blocks and put them one after another. When the reader opens a document, they will not see that it is made of several blocks. to them it will just appear to be one document that they scroll into.
- We also use branches when we want to fork the work that is happening on a Document (let's say in collaborative editing). This can be handy if we want to keep the current version of the Document unchanged, while we are working a newer version. All the work on the newer version is not visible to the reader, until the "working branch" is merged back into the main branch. This is something that programmers will understand very well, but that can be very handy for everybody else too. Please note that we use the terms "fork" and "merge" here as we did when we talked about CRDTs earlier, but it is not exactly the same thing. Here the fork and merge happens only on request from the user. You can decide at some point to fork a document or block. Then you can also decide that it is time to merge it back. But that's a bit different than the automatic and transparent "merge and fork" that is continuously happening every time that someone goes offline. To make things more clear, we don't call the later this way, we just say the document synchronizes itself. fork and merge should be terms used only when the user decides to manually fork.
- Branches and blocks can also be used to store different translation of your content. You do not want to create a new document for each translation. Instead, you create separate blocks within the same document, and each block hols the translated content. NextGraph is designed to help you with managing translation and multi-lingual content, and when the user will open the Document, the most adapted language will be selected for them.
- Another advantage of blocks, is that it lets you create different types of content within the same document. As we have seen earlier, NextGraph offers different types of content (called primary classes). We said earlier that you have to select a type when you create a document. That's true. And this will in fact be the type of the main branch of your document. But then you can add more blocks, that will have different types. So you can combine many different types of content inside the same document. And eventually, you can even change the type of the document itself, by switching the main branch to be another branch (more on that later).
- Also, we internally use the branches feature to store some internal data that you don't see, but that needs to have different branches for the good functioning of NextGraph.
One of the advantage of dividing your content into several blocks is also that blocks can have different read permissions. So if you want to share some information with a certain group of people, but not with some other group, but still refer to that as one document, then you can use blocks. By example, let's say you a Social profile, where you describe yourself, your interest, and where you put some contact information. Maybe the contact details should not be available to everyone (like phone number, postal address, etc..) Still, you do not want to create 2 documents for that purpose. So you will have 2 blocks. one will only contain the minimum public information you want to share to everyone. The other block will contain more details like phone number and address, and it will include also a link to the other block. This way, you don't have to copy paste the general information about you in both blocks. The "include link" is transparent for the privileged reader who got access to the more private profile. they will not see that that the document is composed of 2 blocks. to them it will just appear as one document. And of course, all the other readers who only got the link to the generic block, will not see that there exist another block that contains more private details.
So, to recap. Each branch holds a separate list of commits, that can be seen in the History pane.
For now the App does not let you create new blocks and branches, but it will come very soon. internally, the branches are already there, and they work well. What you see for now in the App when you open a document, is called the "main" branch. Later, you will be able to add more blocks and branches.
Those who are more curious about the internals of the branch, commits, DAG (directly acyclic graph) used in NextGraph, can refer to the [Repo format](/en/specs/format-repo) of the specs.
### Stores
Now let's dive into the last important concept related to Documents in NextGraph: the **Store**.
A store is a way to group several Documents together.
When you created your Wallet, we have created for you, inside your wallet, a personal identity. You can also later create more identities if you wish to (not implemented yet).
Inside your identity, we have also created 3 stores by default for you!
Those are :
- 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 have 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 ever see this data. it is not possible to share the documents of your private store with anybody else.
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.
We said that you can create **Groups** when you want to share, exchange and collaborate with other users. In fact, each Group is a separate Store. This is helpful because each group can have its own set of permissions, and then you can configure the store so that all the documents included in this store, inherit the permissions of the store. This way, we can manage the group easily. If we add a member to the group, they immediately get access to all the documents in the group. The same happens when you remove a user from the group: they loose access to all the documents at once.
As you will see, a Store can be organized into folders and sub-folders, making it very easy to keep tidy. It is the equivalent of the "drive" that you have been using in cloud-based sharing system.
Write permissions are managed at the level of the Document, not at the level of the branch or block. But read permissions can be by block or branch. See more about the [permissions here](/en/framework/permissions).
We also included the feature of having a chat system inside each document. The chat is only accessible to the editors of the document. It is helpful for coordinating the editing work while working on a collaborative document. (not implemented yet).
Another feature that is planned for the documents, is to have the ability to comment and annotate on every document.
Finally, there is an additional type of Store, that we call **"Dialog"** and it is there to hold all the data you exchange with another user (and only with that other user). We use it to store the DMs (direct messages) that you exchange with that other User, and it can also be used to share and create documents with that other user. It is like a private drive, just for you and the other person. You cannot add more users to this store. It is a nice way to organize your documents and content shared with that other person, because scrolling the whole chat is not fun when you search for something that you have exchanged 1 year ago. Here with the Dialog store, you can keep and organize all this content in a more permanent way, and easy to find it later on.
With all this description of documents and stores, you can already understand that NextGraph is also a [Social network](/en/social-network) ! Let's dive into that [more in details](/en/social-network) .
@ -38,7 +38,7 @@ Now comes another problem. If the concept of a “server” is back in the pictu
All 3 existing protocols I just mentioned, are derived from the first one: double ratchet by Moxie Marlinspike et al. This protocol is very good at one thing: enforce privacy for the participants **within the group**. And prevent any other agent that is **outside of the group**, from seeing any plaintext (the messages in clear, unencrypted form). The guarantees are simple: Or you are inside the group and you can see everything within this group. Or you are outside of the group and you cannot see anything. Very nice! Very useful. Everybody uses it on a daily basis, in WhatsApp, by example. In addition, it adds a guarantee called Perfect Forward Secrecy (PFS) which has a negative side-effect for newcomers that will join the group later on (that are invited to join after a while). hey will not be able to see the historical content of the group. That's good for paranoid people who are afraid a compromised key would let unauthorized people see all the past conversation. And it also is based on the concept that this compromised key would be detected, and the intruder would be kicked out fast enough so he doesn’t see any newer messages neither (that's Post Compromise Security), which is another problem difficult to solve. Anyway, it turns out that PFS is an anti-feature in our case, because we obviously want a joining collaborator to **have access to all the historical data** of a DAG of modification of a document. If they wouldn't have that, they wouldn't be able to reconstruct the document's content at all. This is a problem that Matrix is facing. So basically, we do not want PFS. And this problem is being addressed in a [new draft specification called MIMI](https://datatracker.ietf.org/group/mimi/about/), a working group of the IETF. But even if this is solved, I am afraid it will not be enough for our use cases.
We want the double-ratchet because we want to change epoch from time to time. Specially when we revoke the access of a specific user. In this case, the encryption keys need to be refreshed. We can also do so in a periodic manner, for extra security. Another reason why existing group E2EE protocols are not adapted for us, is that the “all or nothing“ access pattern is not what we need neither.
Like with the double ratchet, we want to renew epoch from time to time. Specially when we revoke the access of a specific user. In this case, the encryption keys need to be refreshed. We can also do so in a periodic manner, for extra security. Another reason why existing group E2EE protocols are not adapted for us, is that the “all or nothing“ access pattern is not what we need neither.
@ -14,7 +14,7 @@ NextGraph supports several CRDTs natively, and is open to integrating more of th
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.
- **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)](https://inria.hal.science/hal-00686484/document). 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, implemented by Alex Good, and follows 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.
@ -93,6 +93,7 @@ We bring your attention shortly on the Document's Menu that is accessible from t
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. The Document-like nature is represented with a "cloud" icon.
- 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 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. The Graph-like nature is represented with a "sun" icon.
@ -4,8 +4,41 @@ description: Help / FAQ about NextGraph
layout: ../../layouts/MainLayout.astro
---
Please bare with us as we are currently writing/publishing the documentation (23 of August until 28 of August 2024).
If you have 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).
Here is a list of Frequently asked question. If you have more questions, send them to use by email : team @ nextgraph.org or in the forum.
#### Why do I have to accept ToS ?
You have heard that with NextGraph there will be no more ToS to accept. You are right that with NextGraph we can do without ToS, when the user is connecting to a self-hosted broker. As this option is not available yet, we only offer you to connect to our public Broker Service Provider for now, which needs some ToS to be accepted. Very soon more options will be available to you, including self-hosting, but some users might still prefer using our brokers. In any case, the ToS here are minimal and with end-to-end encryption, your data is unreadable to us anyway.
#### Why is the loading so slow on the web app ?
When you use the web app, we do not store your data locally, because there is not enough space to do so in local storage (the browser limits us to 5MB). Soon we will have a new feature for the web-app, where all your data will be stored locally in the browser, thanks to indexedDB. but this is not ready yet. So for now, every time you open your wallet and start using the web app, all the document's content is fetched from the broker. This can take some time and it explains why the load ing is slow. Once the documents have been retrieve, as long as you do not close the tab, we keep it locally and it even works offline, if you loose connectivity to the internet.
#### Where is my data stored when I install the native App ?
When you use our native app, all the content of the documents is stored locally in an encrypted form, in the following sub-folder of your home/user folder :
- on Linux: `~/.local/share/org.nextgraph.app`
- on macOS: `/Users/[username]/Library/Application Support/org.nextgraph.app`
- on Windows: `C:\Users\[username]\AppData\Roaming\org.nextgraph.app`
- on Android and iOS: the folder is not accessible to you. it is protected by the OS.
You will soon be able to use the CLI in order to read your local data (on Desktop and Laptop).
We recommend you to **not configure** your mobile Nextgraph app for Cloud backup. There is o need to store your NextGraph data in the Cloud as it is already backed up by your broker. In the future, we will also offer you the option to backup your data to more than one broker.
#### I cannot share my documents with other users
This is a temporary limitation that will be lifted in several weeks from now (in the course of Q3 2024).
#### Can I create several Wallet for myself ?
We do not recommend you to create more than one Wallet. The app is not designed to handle such case. Instead, the app has been designed so that you can create more separate identities from within the same wallet. identities that are stored in the same wallet are still independent one from another and nobody will be able to tell that you own both identities. This feature is not available yet but will come soon. here is really no need to create to create several wallets. Specially because you will ahve difficulties to remember several pazzles.
#### Where is the iOS app ?
We were not able to publish the iOS app for now, as we do not have a compilation station with the latest macOS. This will be fixed soon and the app should eb available in the App Store of Apple soon afterwards.
@ -4,4 +4,8 @@ description: See the work in progress and scheduled improvements of the Official
layout: ../../layouts/MainLayout.astro
---
Please bare with us as we are currently writing/publishing the documentation (23 of August until 28 of August 2024).
We just finished a [roadmap](https://nextgraph.org/roadmap) of one year and half that was funded by NLnet and NGI, and that led to the publication of the first alpha release of NextGraph and all the Apps (web, linux, macOS, windows and android).
The iOS version will be available soon too.
The next roadmap will be published in october 2024. We are still preparing it at the moment. Stay tuned!
@ -4,4 +4,8 @@ description: Self host NextGraph broker on your own server or locally
layout: ../../layouts/MainLayout.astro
---
Please bare with us as we are currently writing/publishing the documentation (23 of August until 28 of August 2024).
Self-hosting of the broker will come at the end of 2024. Stay tuned for more features and added freedom!
When you self-host a broker, you enjoy the exact same features than with our public Broker Service Providers, but in addtion, you don't have to abide by any Terms of Services, and your data is free from any limitations.
You are then responsible for your own data, and you can also invite friends and family to use your own broker.
@ -4,4 +4,102 @@ description: NextGraph aims to offer a robust, private, secure and easy to use S
layout: ../../layouts/MainLayout.astro
---
Please bare with us as we are currently writing/publishing the documentation (23 of August until 28 of August 2024).
We have seen that Nextgraph is [organized around documents](/en/documents), and that we can share and collaborate on the those documents with other users.
The internal mechanism of synchronization of the documents is based on a pub/sub, and this enables us to offer all the range of features and services that a Social Network offers.
Nowadays, all apps and content want to be shared with others (except the private content).
It would not make sense for us not to have integrated a social network in NextGraph, as the very nature of the web and the internet, is about sharing and communication.
The Social Network of NextGraph is based on our platform, that is secure and encrypted end-to-end, decentralized and P2P, and also enjoys the features of local-first that we offer.
Furthermore, as you understood NextGraph data model is based on the Semantic Web, we benefit from that very much, as the Semantic Web and Linked Data fits perfectly to the construction of a Social Network.
Our protocol is open source, our infrastructure is also open, as anybody can run their own broker, and we are basing all our work on established Open standards.
The only part that we had to design and implement ourselves, is the [network protocol](/en/network). We explained in the [Encryption chapter](/en/encryption) why we had to create a new protocol and why we could not reuse an existing one. But this innovation was worth it!
As we also know that existing protocols are widely used, we will strive to be compatible with them.
ActivityPub is the most famous OSS protocol for social network, and we have started a collaboration with the [ActivityPods project](https://activitypods.org) in order to bring full compatibility of NextGraph with ActivityPub protocol, and also with the Solid standard! We also aim at harmonizing our frameworks so that apps developed for ActivityPods will also work on NextGraph framework and thus benefit from local-first and ent-to-end encryption, and the reverse will also be true. Apps developed on NextGraph framework will also work on ActivityPods, and therefor be compatible with ActivityPub and Solid.
ActivityPods will act as a gateway between the world of HTTP and NextGraph, that has severed ties with HTTP for reasons explained in the [Encryption chapter](/en/encryption).
Later on, we also aim at being compatible with Nostr, BlueSky/ATproto and maybe more protocols too.
We believe that offering Social Network features in the heart of our framework is essential. here is a list of the features that will soon be part of our framework and platform.
### Stream
Each NextGraph Store comes by default with a **Stream**, which is a list of updates that we anybody can subscribe to. (the private store doesn't offer that, and in order to subscribe to the protected store, you need the link with the long secret key).
Subscribing to the stream is equivalent to "following" a profile.
The stream can be composed of any type of content.
In order to publish some content in your own stream, you just need to create a new document, and select the option "Send in current stream". All your followers will then see this content when they consult their aggregated stream (accessible from the main screen of the app, with the icon of a thunder bolt). It works exactly the same as the feed of instagram or Mastodon.
Any document that has already been created, can be sent into the stream, with the "Share" menu of the Document menu.
It is also possible to "re-tweet" or "boost" something that we like, or to "quote and post" if we also want to add our own comment before reposting.
We can also "reply" to a Post, which is the equivalent of commenting, on other platforms.
We also differentiate between the content that the user wants to add permanently to their profile (this is what we call the homepage of the Store), and the content that should be sent to the stream (more like Stories, or announcements that new content has been added to the store). The stream is ephemeral, while the Store stays permanent.
Of course, it is also possible to like and react to al the content, and to share content in the DMs too.
### Groups and chatroom
As we already explained in the [Documents](/en/documents) chapter, the user can create new groups and invite users to participate to that group.
This feature can be used to create chatrooms, and benefit from all the other features of NextGraph within this chat room : collaborative documents, organize into folders, work offline, end-to-end encryption etc...
This feature will come soon :)
### Navigating the social graph
One of the advantages of NextGraph, is that your social graph (the connections between you and other users), is stored in a graph in a decentralized way, and there is no central authority that can control or see this graph.
We give way too much power to some private companies like Meta or Twitter/X, when we use their platform. They can see the whole graph of all the social connections between people, globally, all over the planet. That's a lot of interesting information, used for advertising, but also for political meddling, and also for surveillance by intelligence services.
With nextGraph, the social graph is distributed in the hands of each participant to the graph, that holds only the needed connections to the people they know, follow, like or interact with. Nobody can see the "big picture".
But this has a negative side-effect. The global graph that Meta by example, maintains, enables them to be able to derive some useful information like recommendations, or specialized content that matches your interests.
We will overcome this caveat of not having access to the global graph, by enabling peer-to-peer traversal of the graph.
This will be possible very soon in NextGraph, thanks to the use of the Semantic Web and the features of "federated queries" that let's you query the data that is not on your machine, but instead, sits in the machine of your friends and contacts. If those other users give you the permission to do so, you will be ale to search in their own graph too.
This is why NextGraph makes a strong separation between the data that is private and should always stay private, and the data that is public or protected. Public data can be queried by anyone, will protected data needs your permission.
With federated queries, we will be able to ask our friends for recommendation, and to see our social graph in a more meaningful way.
Because Meta stores all the global graph based on the data that we provide to this company (by clicking, liking, commenting, following, etc) that does not mean that the Meta company let us have access to the data that we generated. To the contrary. They keep this data for themselves and share it only with advertisers and the CIA.
Here with NextGraph, we can finally regain control over our social graph and shared data, and if we are allowed by our peers, we can navigate this social graph freely.
And unlike ActivityPub, where everything is public and the system administrators of the Mastodon servers can see everything that we do, including reading our private DMs, with NextGraph, we all have end-to-end encryption by default. We also benefit from the local-first feature of NextGraph, which makes the apps work offline too. That's very handy when traveling by example, as the whole social network app still works without internet, and will synchronize itself back when we are connected again.
### Compatibility with Big Tech
Even though we really want to get rid of all th Big-Tech products and services, we understand that a level of compatibility with them will be need if we want the transition process to be fast and smooth.
Indeed, most of our contacts and friends today are still using the social networks and tools of Big-Tech.
If we want to reach them, we have to use the tools and platforms that they use, until they eventually switch to OSS tools and platforms, and specially, to NextGraph.
We are investigating how we could offer a certain level of compatibility with those platforms, so that users of NextGraph can also cross-post to Meta or X, and could also interact with their users (DMs, follow, etc).
It will not be easy, as those platforms do not offer APIs for us to connect to and have access to their users.
Maybe one day the European Union will finally force them to open their APIs and force interoperability.
In the meanwhile, we are currently exploring ways to implement this already.
Another important tool would be the option to import all the content and contacts that someone has gathered through the years on a platform of big-tech, so it can be used in NextGraph, when that person decides to switch to our platform. Some big-tech platforms already offer the export option. and we would have to implement the import part.
It is important to understand that NextGraph does not need to implement an export feature, because with NextGraph, all your data is totally under your control already. it is local and you have it directly on your device, it is saved in some open standards like RDF, JSON or Markdown, and you can do whatever you want with it. Furthermore, if you decide at some point ot use a different broker, or to self-host your own broker, all your data at NextGraph is absolutely **portable** and you can move your data to another broker without any bad consequence. Your documents and links have unique IDs that are not related to the broker where you store the data. That's another advantage that no other platform or framework can offer, not even ActivityPub, which is all based on http and domain names, and that will break as soon as you change hosting provider. (I have experienced this myself. The list of followers can easily be transferred, but you loose all your posts and DMs).
Welcome to NextGraph, that will soon offer all those Social Network features, and that already offers the best [collaborative tools](/en/collaboration) with offline-first and end-to-end encryption.
