rad-identities

[FintanH]

The majority of the work is porting over code from copy and modifying it to be generic over the type of identity being used.

The package is split into top-level modules:

• any
• local
• project
• person
• rad_refs
• refs
• tracking

For each of those there's a corresponding module under the cli module which performs all the setup logic followed by calling the top-level function, mentioned above.

The cli module culminates in the args and main modules, where the former defines all the arguments requried for calling the evaluation functions, and the latter calling those eval functions based on the given command.

The field module captures lens-like Has traits so that we can write functionality that can be re-used across both Person and Project. These traits allow us to talk about the fields on those two identities polymorphically.

The git hierarchy provides utilities for setting up working copies.

============= Preserving previous thoughts ============= :construction: The WIP of the rad-identities CLI library :construction:

Happy to receive early feedback :)

TODO:

• [ ] add examples in CLI docs
• [ ] add tests to test package
• [ ] flesh out what review would actually do
• [x] clean up missing identities (should use the error variant for this)
• [x] find a home for common setup of getting a signer and storage (read/write) -- addressing in https://github.com/radicle-dev/radicle-link/pull/739
• [x] eval_create logic can move to top-level create
• [x] eval_checkout logic can also move to top-level checkout
• [x] HasBranch logic can be modified for Person, possibly just seeing if a default_branch field is in the extensions, or think about using HEAD instead and doing away with default_branch altogether (possibly out of scope of this PR)
• [x] Update docs for checkout since they're dated
• [x] Introduce output type for serializing to json or cbor -- addressing in https://github.com/radicle-dev/radicle-link/pull/739
• [x] rad_delegates should output the Persons
• [x] logic in src/refs.rs is cribbed from librad/git/refs.rs, might be worth finding a place to consolidate them
• [x] Output vector for listing functions

Once https://github.com/radicle-dev/radicle-link/pull/739 lands:

• [x] ~Use Format type for outputting to stdout~ punting on this because https://github.com/radicle-dev/radicle-link/issues/464 would be a nice-to-have for this and JSON output is the default anyway.
• [x] Clean up duplicated storage setup logic

Testing:

• [x] Working copy tests:
  • [x] new working copy
  • [x] existing working copy
  • [x] checkout working copy
• [ ] CLI tests for eval functions
  • [ ] any
  • [ ] local
  • [ ] person
  • [ ] project
  • [ ] rad_refs
  • [ ] refs
  • [ ] tracking

[xla]

add tests to test package

:exploding_head:

[FintanH]

I'm marking this as ready to review and capturing the following for follow-up tasks (to avoid PR fatigue):

• adding CLI examples as part of the documentation
• adding more extensive testing of the eval modules
• propose & discuss how the review feature should work via EMAIL

[FintanH]

Really nice, long but easy to read, like any good epic fantasy.

And just like George R. R. Martin, you'll never see my end to this adventure

[FintanH]

I started playing around with rad identities and realised that to create a Person I had to do the following:

rad identities person create new --payload '{"https://radicle.xyz/link/identities/person/v1": {"name": "fintohaps"}}'

So the URL has to be specified, which makes sense because it's expecting a PersonPayload. I initially thought I could throw in {"name": "fintohaps"}. The URL would probably be a pain to copy & paste (or remember for the brave) all the time. So it'd be worth thinking about how this might be made easier. My first thought of course is dhall :) There could be a base Person payload file and a constructor that takes just the name field, and it could be extended with // if wanted. Then creation could be rad identities person create new --payload $(dhall ./Person/base "fintohaps")

On a separate but slightly related note, the signer_ssh[0] function isn't working and results in this error being repeated in a loop:

180774: Agent protocol error
180775: Agent protocol error
180776: Agent protocol error
180777: Agent protocol error
180778: Agent protocol error
180779: Agent protocol error

[kim]

So the URL has to be specified,

Why is this? Because you want to allow extension payloads as well?

Maybe that just requires two different UIs to (basically) achieve the same thing:

rad identities person create new \
    --payload '{"name": "hax0r"}' \
    --ext '{"https://shady.ru": {"foo": "bar"}}'

vs

rad identities create \
  --payload '{"https://radicle.xyz/link/identities/person/v1": {"name": "hax0r"}}'

(btw: "create new"? can I also "create old"?)

[FintanH]

Maybe that just requires two different UIs to (basically) achieve the same

Foiled again to introduce dhall into the workflow :P thanks for that suggestion! Looks good so I'll have a crack at it.

(btw: "create new"? can I also "create old"?)

Not quite, you can create existing though :)