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

Sigchain commands for inspecting the sigchain #252

Open
CMCDragonkai opened this issue Aug 11, 2024 · 4 comments
Open

Sigchain commands for inspecting the sigchain #252

CMCDragonkai opened this issue Aug 11, 2024 · 4 comments
Labels
development Standard development

Comments

@CMCDragonkai
Copy link
Member

CMCDragonkai commented Aug 11, 2024

Specification

The sigchain is part of our identities claims process, but soon will also be part of the network authentication to private networks in PKE. And in the future is likely part of further decentralized trust infrastructure.

Right now there's no commands for inspecting the sigchain. The closest is simply inspecting the gestalt graph, and even then that command isn't the best either. That's simply identities list.

We should have a sigchain command too. I wonder if this should be part of the identities subcommand...

In this sense, it should be possible to see the chain of claims of the current node, but also the chain of claims of the gestalt itself - which includes other vertices of the gestalt.

I can propose a few basic commands first, but this means we need to change some of the other commands a bit.

# IDENTITY PROVIDERS
identities authenticate
identities authenticated
identities search

# ACL/PERMISSIONS (maybe `identities acl`)
identities trust
identities untrust
identities permissions
identities allow
identities disallow

# GESTALT GRAPH (maybe `identities graph`)
identities list
identities get
identities discover
identities queue # QUESTION COMMAND

# SIGCHAIN (some of this is related to GG, but not all SigChain is about the GG)
identities claim
identities invite # I don't think this command should exist, it should just be merged into claim
identities chain # Show the chain
identities chain list
identities chain get <CLAIMID>

# OR lift the sigchain up (it's no longer just about identities)
sigchain get # show all sigchain claims in order (default order should be ascending by ClaimID)
sigchain get <claimId> # show a single claim in the sigchain

I think we have overloaded the identities too much. There's too much complex functionality all put into the identities subcommand.

On the side note, I think we're not that consistent with CRUD operational terminology.

  • list - get all the things
  • get - get one thing
  • connections

Inside the code, it's pretty clear that reading something is always a getX, and reading multiple things is always getXs. For example getLink vs getLinks, and we always tend to stream things too. Unless a batch itself has a special type name like CertificateChain. However it's also possible to simplify this with just:

X get # get all things
X get <someID> get one thing

So then to look up the chain, you can just do polykey sigchain get and to get 1 thing, it can be polykey sigchain get <claimId>.

In this sense, it should be possible to dispense with the list subcommand entirely.

Additional context

Tasks

  1. ...
  2. ...
@CMCDragonkai CMCDragonkai added the development Standard development label Aug 11, 2024
Copy link

linear bot commented Aug 11, 2024

@CMCDragonkai
Copy link
Member Author

Spec is still TBD, but I noticed that there was no issue for commands relating to the sigchain.

@CMCDragonkai
Copy link
Member Author

@tegefaulkes

@CMCDragonkai
Copy link
Member Author

So #6 was actually discussing this already.

Given that @amydevs has been working on the network segregation issue. I suspect new commands are necessary. What issue are you working on that may be related to increasing the complexity of the identities subcommand.

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

1 participant