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 [here](https://www.farley.ai/posts/causal) and [here](https://www.bartoszsypytkowski.com/the-state-of-a-state-based-crdts/).
If you are not familiar with CRDTs, there are some nice introductions you can read about that subject [here](https://www.farley.ai/posts/causal) and [here](https://www.bartoszsypytkowski.com/the-state-of-a-state-based-crdts/).
@ -135,7 +135,7 @@ It should be noted that permissions can span a whole UserStorage, or a whole Sto
As we already mentioned shortly when we talked about blocks [here](/en/documents#blocks-and-branches), you can include some other blocks inside a document. This will have the effect of including also all the triples of such block, inside the document where the include is declared.
This is very handy when you are in Document A, and you need to access some extra data coming from another Document or Branch B, and you want to make sure that anybody who will read the current Document A, will also fetch and include the other Document or Block B automatically. If you have some logic in your document tha depends on such data, in a SPARQL query by example, this **include** mechanism will solve the headache of fetching and caching the foreign data.
This is very handy when you are in Document A, and you need to access some extra data coming from another Document or Branch B, and you want to make sure that anybody who will read the current Document A, will also fetch and include the other Document or Block B automatically. If you have some logic in your document that depends on such data, in a SPARQL query by example, this **include** mechanism will solve the headache of fetching and caching the foreign data.
The included block can be from the same document, from another document in the same store, or not, and even in someone else's document, on a remote machine. Thanks to the pub/sub and synchronization mechanism of NextGraph, this foreign block will always stay up to date as it will synchronize with the original source.
@ -143,11 +143,11 @@ The included block can be from the same document, from another document in the s
And this leads us to an explanation about what happens to named graphs in NextGraph.
Named Graphs are an RDF and SPARQL feature that lets you organize your triples into a bag. This bag contains your triples, and we call this bag a Graph. it also gets an ID in the form of a URI (URL normally. In NextGraph, a Nuri).
Named Graphs are an RDF and SPARQL feature that lets you organize your triples into a bag. This bag contains your triples, and we call this bag a Graph. It also gets an ID in the form of a URI (URL normally. In NextGraph, a Nuri).
SPARQL has options to specify which named graph(s) you want the query to relate to.
Theoretically, a triplestore can put any kind of triple in any graph. By the way, when the triplestore can understand the concept of a named graph, then we can it a quadstore, because then each triple has a 4th part telling about which graph the triple is stored in. So triples become quads (they have 4 parts instead of 3). And the triplestore becomes a quadstore.
Theoretically, a triplestore can put any kind of triple in any graph. By the way, when the triplestore can understand the concept of a named graph, then we call it a quadstore, because then each triple has a 4th part telling about which graph the triple is stored in. So triples become quads (they have 4 parts instead of 3). And the triplestore becomes a quadstore.
NextGraph is a quadstore, but there are some limitations.
@ -4,7 +4,7 @@ description: NextGraph aims to offer a robust, private, secure and easy to use S
layout: ../../layouts/MainLayout.astro
---
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.
We have seen that NextGraph is [organized around documents](/en/documents), and that we can share and collaborate on 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.
@ -22,7 +22,7 @@ The only part that we had to design and implement ourselves, is the [network pro
As we also know that some 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 end-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.
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 end-to-end encryption, and the reverse will also be true. Apps developed on NextGraph framework will also work on ActivityPods, and therefore 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).
