📑 [Epic]: kick-start the Devkit Privacy Computation Engine

[nweldev]

Description

Handling privacy requests and regulation, provenance and retention policies related computation rules.

Note

This Epic is only for @m4rk055 to kick-start the project by himself.
As soon as the project is ready for other people to contribute, a new epic should be created, and this one rapidly closed.

Intended outcome

• have a minimal but operational privacy computation engine allowing to demo a DevKit MVP (v0)
• have a strong enough basis to develop the following privacy computation features

Sub-tasks

• Initialize repositories for Privacy Computation Engine #774
• Implement handling of transparency requests in PCE #807

Stakeholders

• @m4rk055 for development
• @noelmace and @milstan for tracking and help
• @blindnet-io/engineering for reviews and knowledge sharing

[milstan]

As I am working on Privacy Request Multicast Protocol, I realize that in fact the operation of passing PRIV objects from one system to another can be regarded as sychronisation of dataset replicas (in the sense of Conflict-free Replicated Data Types - CRDT).

In this sens, maybe we have an interest to directly develop storage of PRIV objects (for the purposes of the Privacy Compiler) as a CRDT database (e.g. Redis or other), and then we can develop the mutlicast protocol as a simple merge, so if two systems are in communication, wherever the user makes a Privacy Request/Consent or wahterver, they simply reach equal information.

p.s. I am still working on full set of requirements (and this might proove more complicated then I thaught), but it would be interested to get your view @m4rk055 on this? Is it worth exploring? Can we make a PRIV object (any of Consent, Capture - not supported now, Privacy Request, Response....) a data type in the CRDT?

The idea behind would be to avoid making a novel protocol for asychnonous Eventual Consistency (because that is what we need to acheive among Systems exchanging data), but reuse an existing one.