MatrixAI / Polykey-CLI

Polykey CLI - Open Source Decentralized Secret Sharing System for Zero Trust Workflows
https://polykey.com
GNU General Public License v3.0
5 stars 3 forks source link

Singleton NodeId discovery and share #204

Open tegefaulkes opened 1 month ago

tegefaulkes commented 1 month ago

Specification

We've run into a usability problem with discovery, trusting and sharing. Currently when you trust or share it requires that you have the node in you gestalt graph. This runs to a problem where it's common to not have a node in the GG but it's unclear why. For example the flow would be

  1. discover node.
  2. trust node.
  3. share vault.

The discovery step seems superfluous from the user experience perspective. I know my friends nodeId because we're likely coordinating sharing and trusting. So why do I need to discover them first, a step that can take an unknown amount of time?

Ideally we can skip the discover step entirely. Given that discovery is an active process. Where it contacts nodes and identities to confirm them before adding them to the gestalt graph. If we don't wait long enough or even could just fail to connect and process a vertex. We can't actually proceed with sharing.

cmcdragonkai ➜ matrix-framework-13-ryzen-7040  ➜ ~/Projects/Polykey-CLI
 $ ./dist/polykey.js identities discover vg6gldhfdstju8frtbguav2p2svmev85dvpdb34gffmiagpgjf2pg

// Returns since it's non-blocking but the node isn't actually discovered. There is no feedback as to why without running with --monitor

So how do we fix this? AFAIK it's working as designed beyond the fact that it's taking longer than expected. I can think of a few options.

  1. Work out why it takes so long. If it can ping (I have no idea if this was confirmed or not) then it should discover with almost no delay. If it fails to connect then it would fail.
  2. It's possible that we have a task leak or too many tasks to process in a timely manner. I only have a vague vibe for this and if it was the case that would be very odd. We don't rate limit tasks AFAIK.
  3. Do we change discovery algorithm to add vertices to the GG without confirming them first? So just queuing them will add them to the GG?
  4. Do we make trusting and sharing add a placeholder vertex to the GG without the need for discovery? I'm already adding this as part of social discovery work. Otherwise we have very little starting points for discovering based on permission links.

Additional context

Tasks

  1. Needs more discussion I think. TBD
linear[bot] commented 1 month ago

ENG-340 Singleton NodeId discovery and share

amydevs commented 1 month ago

yeah i have no idea why the task takes so long to start executing sometimes

tegefaulkes commented 1 month ago

I suspect that there may be a task leak? If a long running node accumulates a lot of tasks then that can crowd out newer tasks. That said, I don't think we currently rate limit new tasks. So if new tasks are getting crowded out like that then I'd think we'd be getting other problems as well.

I guess this brings up the need for adding task events to the audit domain as well. So we can see how these tasks are being created and processed.