Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vault Sharing With GestaltIDs #626

Closed
amydevs opened this issue Nov 10, 2023 · 3 comments
Closed

Vault Sharing With GestaltIDs #626

amydevs opened this issue Nov 10, 2023 · 3 comments
Assignees
Labels
development Standard development

Comments

@amydevs
Copy link
Member

amydevs commented Nov 10, 2023

Specification

Originally, vault sharing was understood that it was only to a singular node.

The desired behaviour should be that sharing a vault with a nodeId shares the vault with the entire gestalt. This is because Gestalts are addressable by both nodeIds and identityProviderIds. Furthermore, the VaultShare handlers should also be able to accept identityProviderIds as well, and take the first discovered node of the identity to trust.

There are some implications regarding discovery. For example, in the case where node B trusts node A, and hence gestalt A, but node C joins gestalt A after this, so that node B does not know that node C is in gestalt A yet.

Untitled-2023-10-23-0424 excalidraw(4)

Additional context

Tasks

  1. Allow for nodes from the same trusted gestalt to clone/pull a vault
  2. When a vault is shared with a gestalt, implement notifications for all nodes of that gestalt
  3. Update discovery mechanism when vault pull is called.
@amydevs amydevs added the development Standard development label Nov 10, 2023
@CMCDragonkai
Copy link
Member

We already had an issue: MatrixAI/Polykey-CLI#30

Why create a new one?

@amydevs
Copy link
Member Author

amydevs commented Nov 13, 2023

This is too complicated for now, mainly there's too much stuff strewn across ACL and GestaltGraph to centralize the logic for Node vault permissions. Specifically, it seems that GestaltGraph already has logic in the form of linkNodeAndNode that will synchronise the permissions of 2 nodes for a vault, but what we want is for this to be done on the fly within ACL. This would result in a circular dependency between ACL and GestaltGraph that seems kinda nasty.

Actually, the logic will be done in the handlers. This should make this alot easier. ACL will stay as a low-level API, and the handler will simply synchronize the GestaltGraph so that new nodes are linked if it is a newly added node to a gestalt.

This should be able to be fixed by periodic background triggering of Discovery, or some sort of mechanism to trigger discovery based on a node entering or leaving a Gestalt, similar to a broadcast. I initially I had tried to trigger discovery whenever a Vault is being pulled, and the permissions for the node corresponding to the pulled vault aren't found, but this is quite slow. The ideal is that the triggering of discovery should be push based, rather than pull based. This is too complicated to be implemented in a day.

let permissions = await acl.getNodePerm(requestingNodeId, tran);
      if (permissions == null || permissions.vaults[vaultId] == null) {
        const task = await discovery.queueDiscoveryByNode(requestingNodeId);
        const prom = task.promise();
        console.log(prom);
        await prom;
        permissions = await acl.getNodePerm(requestingNodeId, tran);
      }
      if (permissions == null) {
        throw new vaultsErrors.ErrorVaultsPermissionDenied(
          `No permissions found for ${nodeIdEncoded}`,
        );
      }

Furthermore, the Discovery mechanism is meant to be a continuous background task that updates the GestaltGraph periodically. This is currently not implemented, as users are only able to manually trigger the discovery of a gestalt.

#328

#190

@CMCDragonkai
Copy link
Member

Closed in favour of MatrixAI/Polykey-CLI#30.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Standard development
Development

No branches or pull requests

2 participants