Roadmap

The current roadmap has been completed at the end of August 2024. We are now working on establishing the next one.

  1. a. Mutation

    Generate a SparqlUpdate (SU-Set) for each Oxigraph transaction. keep Mutation metadata in triplestore.

  2. b. Query

    accept nextgraph URIs in SPARQL queries

  3. c. Federated Query

    accepted nextgraph URIs in SERVICE

  4. d. OCap

    OCAP enforcement in queries

  5. e. Encryption at rest

    data encrypted at rest for the RDF store

  6. f. RDF-star

    RDF-star and SPARQL-star adaptation to SU-set

  7. g. Blanknodes skolemization

    Blanknodes skolemization

  8. h. SPARQL endpoint

    Modify SPARQL endpoints to match the new URI API

  1. a. Signature of commit

    Signature of commit

  2. b. Signature of snapshot

    Signature of snapshot

  3. c. P2P layer integration - metadata

    Adapt the P2P layer for threshold signatures - metadata

  4. d. Signature API

    API to retrieve the commit signature and the PublicKeySet

  1. a. Automerge-rs

    Integration of automerge-rs

  2. b. Yrs

    Integration of Yrs

  3. c. Prosemirror+Yjs

    Integration of Prosemirror+Yjs

  4. d. Codemirror+Yjs

    Integration of codemirror+Yjs

  1. a. Website and tools

    Creation of a website at nextgraph.org detailing the project and offering a forum (Zulip) and a VCS (Gitea) for project management. source code will be mirrored on github too.

    Visit the forum !

  2. b. Documentation

    Full documentation and specification

    Read the docs

  3. c. Tutorials

    Write tutorials, getting started guide

  1. a. Three Stores of a Site

    3 Stores of a Site

  2. b. Containers

    LDP containers

  3. c. Cache

    Cache is now called pining

  4. d. UserStorage

    Storage of all metadata and materialized state of documents locally

  1. a. Verifier

    Verifier API for application to verify incoming commits

  2. b. P2P protocol

    P2P core overlay protocol with Pub/Sub, two-tier broker dispatch of events

  3. c. External requests

    Being able to access the commits and files from outside

  4. d. Petnames

    Petnames of commits and branches

  1. a. ngd - the NextGraph Daemon: configuration

    The Daemon (ngd) serves the web app, and also acts as a broker. It can be administrated with the help of the CLI (ngcli). A daemon can be installed on any server thus making NextGraph a self-hosted solution

  2. b. ngcli - the command line interpreter: basic commands

    P2P core overlay protocol with Pub/Sub, two-tier broker dispatch of events

  3. c. Websocket communication and Noise protocol encryption

    The App, the CLI and the Daemon communicate with each other using a websocket that is encrypted with the Noise protocol

  4. d. RocksDB plugin for encryption

    the apps, the CLI and the daemon encrypt all their data at rest. For this purpose, RocksDB was chosen as a key-value store compatible with all the targeted platforms. RocksDB offers an interface for encryption at rest, via a plugin. We implement this plugin with a CTR-AES-256 symmetric encryption based on OpenSSL or IPPCP depending on the platform.

    Rocksdb encryption plugin

  5. e. native app based on Tauri, web app, and javascript SDK/API scaffolding

    NextGraph proposes a native application to its users, which runs on several mobile and desktop platforms (Linux, Android, MacOS, iOS, and Windows) and a web app accessible via modern browsers. The native app is based on Tauri framework. Developers can also use the Javascript SDK/API to integrate NextGraph into their own application.

  6. f. Wallet CRDT mechanism, GUIs for creation and opening of the Pazzle

    Before being able to use the App, each user must create a Wallet for themselves, which is a tiny file containing the private keys of their Identity and Public, Protected and Private stores. Those stores contain the private keys to access all the repositories/documents they have permission for.

  7. g. Broker Service Provider workflow for TOS acceptance

    When creating their Pazzle, the user must choose one broker that will be associated with their personal identity. Having a broker is mandatory as the 2-tier P2P network relies on the availability of a broker to exchange events.