You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
I think we have overloaded the
identities
too much. There's too much complex functionality all put into theidentities
subcommand.On the side note, I think we're not that consistent with CRUD operational terminology.
list
- get all the thingsget
- get one thingconnections
Inside the code, it's pretty clear that reading something is always a
getX
, and reading multiple things is alwaysgetXs
. For examplegetLink
vsgetLinks
, and we always tend to stream things too. Unless a batch itself has a special type name likeCertificateChain
. However it's also possible to simplify this with just:So then to look up the chain, you can just do
polykey sigchain get
and to get 1 thing, it can bepolykey sigchain get <claimId>
.In this sense, it should be possible to dispense with the
list
subcommand entirely.Additional context
identities unclaim
command #164Tasks
The text was updated successfully, but these errors were encountered: