D2.1 - Towards the deadline

An internal planning post for what is happening/planned for D2.1 – MVP Alpha (DROMEDAR).

Will post as response per mail. No stable internet.

1 Like

With the D2.1 deadline we want to have a minimal working DMC
implementation. The implementations consists of an OCaml library
and a CLI that uses the library.


This is the repository of the OCaml DMC implementation.

See the meeting in
an idea of what the CLI should be able to do. Some things we leave


  • Persistent storage for ERIS blocks (@nemael is working on
  • Persistent storage for DMC objects
  • Implementation of RDF Signify using ocaml-rdf and
  • Sub-commands
    • init to initialize a new DMC repository
    • add to add an element to a DMC set
    • remove to remove an element from a DMC set
    • state query the state of a DMC container
  • Documentation
    • Simple walk-trough in the Readme

Things for later (not for D2.1)

  • DMC registers (D2.1 will only implement DMC sets)
  • Adding and removing additional authorized public keys to a DMC
  • Transport
  • Datalog REPL


Implementation of DMC logic and sub-commands is fairly
straightforward with the ocaml-rdf library which includes a
Datalog engine. No troubles expected.

Tricky part might be persistent storage. @nemael is already
looking into this.


Bindings to the Monocypher cryptographic library.


  • Implement bindings to Ed25519 functions (required for RDF Signify/DMC).

This todo is straightforward but quite a bit of mechanical work. If anybody is
interested it is up for grabs.


OCaml implementation of ERIS.


  • Make it work with persistent storage (see notes on ocaml-dmc, @nemael
    is on it)


OCaml RDF library. This is the working horse of the DMC implementation and
includes the tricky parts (Turtle serializer and Datalog implementation).


  • RDF/Turtle serializer (@arie is working on this)
  • Content-addressable RDF (implementation of FragmentGraph)
  • Datalog. ocaml rdf already contains a working Datalog implementation
    (taken from
    However it lacks to essential features: Negation and built-in functions.
    @pukkamustard is working on implementing Negation and built-in functions.


We have fall-backs for the critical components:

  • If RDF/Turtle does not work out we use RDF/JSON which is already implemented
    by @arie
  • If we fail at implementing negation/built-in functions in the existing
    Datalog implementation we can use the
    implementation. c-cube/datalog has support for negation and built-in
    functions however there are some other things that make it not suitable:
  • Implementation is fairly complex (compared to ramsdell/ocaml-datalog.
    This is partly due to support for negation/built-ins but also because it
    allows nested terms (something we do not need/want).
  • No support for persistent storage. ramsdell/ocaml-datalog also does not
    support persistent storage, but it seems easier to implement there as the
    implementation is much more readable and hackable (in @pukkamustard’s
    Nevertheless, @pukkamustard has experimented with c-cube/datalog and thinks
    that it can be hacked to work as we want if necessary. This will be the
    fallback if we do not manage to implement negation/built-ins by our self.

D2.1 post

A public post/page that introduces and summarizes the work done.


  • Write post. Deferred until ocaml-dmc takes on more shape.

Apparently not the full email made it to the post (it was cut at ocaml-monocypher). I’ve added the missing sections from my original mail.

Thanks so much for this very clear explanation of the state of work, it is very helpful to see clearly where we’re at and what will be at hand to work with.
I appreciate much that you consider alternative options for the different cases.

This is an interesting choice, I wonder what are the differences between one and another.

Can’t wait to see this happen as it is at the heart of public usage I think.