search

sourcenetwork / defradb

DefraDB is a Peer-to-Peer Edge Database. It's the core data storage system for the Source Network Ecosystem, built with IPFS/IPLD, LibP2P, CRDTs, and Semantic web3 properties.
117 stars 32 forks source link

Implement Defra SourceHub ACP module #2366

Open shahzadlone opened 3 months ago

shahzadlone commented 3 months ago

Implement (and integrate) Defra SourceHub ACP module.

AndrewSisley commented 1 month ago

Note: This is currently under discussion in the dev-db.ACP discord thread: https://discord.com/channels/427944769851752448/1200142876307374100

Discussion summary:

Within a single node, within the context of a user request (not limited to GQL requests, but any doc op), we need to differentiate between unowned docs, docs for which the user access cannot be determined (either due to unknown owner, or policy not existing locally), and docs whos owner/policy stuff is known and can be evaluated.

Th unknown owner problem could be solved by hosting/syncing doc owner (but not policy) in the document blocks, however that remains controversial (at least from an ACP perspective, John did hint that we may need this for other reasons though), and does not mean that the policy is known to the node (so unknown-policy still needs to be handled).

If the access (policy/owner) status is unknown, the document must be treated as if the requesting actor/user does not have access (i.e. it does not exist).

Additionally, an LWW Merkle register (or another CRDT) would be needed for ownership change (if owner is not in the doc DAG), and for policy change (or mutation). Given that local ACP supports neither ownership or policy change atm, it is possible to bypass this in the short term, but we should still be aware of the need for this in the medium-long term in order to not make life difficult for us when we do introduce it.

We also found a major problem with ownership change if ownership is within the blocks, in that if ownership changes later commits synced from other nodes that have yet to recieve the ownership change may be invalid/unwanted. We can solve this by either branching the document (multiple heads), or treating ownership change as kind of copy (creating a new doc, potentially with a new docID, and potentially deleting the original). If we keep owner out of the blocks we should not encounter this problem (but, as mentioned, it might be that we need owner in the blocks for other non-ACP reasons).

It has been decided that a P2P-ACP implementation is not to be production ready in the short-medium term. Defra ACP production readiness needs to be achieved using a SourceHub ACP implmentation.

  1. A user proves to a node that he is who he is by signing a message using the node peerID. This is encapsulated in a JWS (not JWT) token.
  2. The same process happens when the interaction is between 2 nodes (P2P).
  3. The user's signature (DID?) is added as a meta field when generating the docID and is stored in the genesis block. This defines the user as the owner of the document.
  4. If an owner of a document is to be changed, it can only be done by the current owner and the change must be anchored on SourceHub.
  5. A user's nodes host his private key (keys?) but private keys are not shared with 3rd party nodes.
  6. We will not worry about nodes making requests on behalf of a non owner user for the time being.

Example cosmos client: https://github.com/sourcenetwork/orbis-go/blob/develop/pkg/authz/acp/acp.go

Here is how to use a Signer interface for the cosmosclient stuff, since all the Account and Address stuff is mostly for the orbis keyring stuff https://github.com/ignite/cli/blob/936476c9358bcda4a67475ea521f1c4a39759dbe/ignite/pkg/cosmosclient/cosmosclient.go#L276

fredcarle commented 1 month ago
Screenshot 2024-04-17 at 12 13 06 PM Screenshot 2024-04-17 at 12 13 45 PM
AndrewSisley commented 1 month ago

note: Unassigning myself for the cooldown, I intend to pick this up again for v0.12, but anyone else is very welcome to steal it in the meantime, or if I am unavailable in 2 weeks.

AndrewSisley commented 1 month ago

Bruno is currently working on a new client for SourceHub that will make things much nicer for us from Defra. It will hopefully be implemented within about 3 weeks. The new client stuff should not impact the spinning up of SourceHub test instances, so that can be worked on a bit before actually having to worry about writing the production code. The interface will be defined before he implements it, but working from that too early is risky and may potentially be changed as work on the implementation progresses.

I plan on leaving this ticket for another week or so, before checking in with Bruno RE the status of the new client.

Note: WIP branch 2366-source-hub