Slack Archive

To Index

Back To Top
<@U024CJMG22J> has joined the channel
<@U024KC347B4> has joined the channel
<@U013SSREL0H> has joined the channel
<@U03EUG009MY> has joined the channel
petteri.stenius
<@U03U37DM125> has joined the channel
daniel.hardman
<@U03RLLP2CR5> has joined the channel
<@U02PA6UQ6BV> has joined the channel
<@U035R1TFEET> has joined the channel
<@U0448S72CQN> has joined the channel
<@U02N0K6LL93> has joined the channel
rodolfo.miranda
<@U03P53FCYB1> has joined the channel
I updated this repo with actual working cryptographic primitives of raw to qualified base64 for all the types I believe are needed to implement Signify's signing at the edge. I ported over unit tests from KERIpy to ensure compatibility as I believe communication between a cloud agent and an edge signer should be via CESR
Up next for this weekend includes updating the LICENSE and README files, adding CI for the unit tests with GitHub actions and including a few badges because, you know... badges are cool
After all that is finished, I'm going to start fleshing out key creation on the client and figure out how that would integrate with keripy. In particular, I'm curious what needs to be communicated from the cloud agent to the edge for hierarchical deterministic key chains. I look forward to studying the Manager and Keeper in keripy to figure out what is tracked for that purpose.
daniel.hardman
Wow! Super exciting!
Yes, this is very exciting. I would like to pitch in however I can. I’m studying those classes, and many others, as I bring myself up to speed on KERIpy. I’ll put a focus on Manager and Keeper so I can be of use here.
I just merged in a new PR: Highlights include a ported Manager, test Keeper, Encrypter/Decrypter, Signer and Indexer and Siger with dual index support. I also got CI/CD working and running tests on each PR.
That’s cool. Nice work. Hope to join you soon.
I still have several hundred lines of Manager tests to port over from keripy which I can do now that I have Siger implemented.
After that, I'd like to build 2 things. First, a web page that exercises the Manager functionality just to see it working in a browser. Second, a REST API in keripy for the test Keeper interface in Signify
<@U04HMQT1XFV> has joined the channel
nuttawut.kongsuwan
<@U04H17ZEX9R> has joined the channel
<@U04GUPCB1M4> has joined the channel
<@U02MD0HA7EJ> has joined the channel
joseph.l.hunsaker
<@U03QRSUA87Q> has joined the channel
I have not been good at updating my progress on Signify on this channel recently. Last week I merged in: That added support for hierarchical deterministic keychains into the TypeScript Signify client and also started working on the Python server (signifypy) that will be the new KERI Python Agent to support signing at the edge. I'll have more PRs coming this weekend. I was hesitant to add GitHub integration to the repos for fear of the noise. However, for fear of being drowned out by the Chesty Crustaceans and all their posts over on <#C04LNE87GHE|cesr-dev> I think maybe it is time. Since I am in love with emoji voting, here's the vote: :no_mouth: - Stay quiet and don't add GitHub integrations for signify-ts and signifypy :crab: - Integrate GitHub and be as loud as the Crabs
petteri.stenius
FYI - Ed25519 is becoming natively supported in browsers with Web Crypto API. Chrome already has it (you need to enable ). See here With this you could do for example: `const key = await crypto.subtle.generateKey({ name: "Ed25519" }, false, ["sign", "verify"]);` `const signature = await crypto.subtle.sign({ name: "Ed25519" }, key.privateKey, data);`
andreialexandru98
<@U0474LZ0ZLG> has joined the channel
petteri.stenius
Hi <@U024CJMG22J>. I have tried running signigy-ts in a browser. There are some issues I run into: - Signify uses the Buffer type which is for Node server side. Should re-factor and replace with Uint8Array - Blake3 wasm has some issues. Cannot get it working in a browser with the toolchain my tester app uses. - I replaced urlsafe-base64 with js-base64 that better works in a browser I have a with fixes to some of these issues. I also created a simple app that invokes code in signify-ts. Using latest Chrome the tester can successfully invoke Keri Signer but not Blake3 digest. Before creating a pull request I'd like to know if this the correct way? For example what is best practice to to solving platform differences (Browser vs Node)? Now I created a virtual "platform" module that is routed to either "platform-browser" or "platform-node" depending on context. Also are there some preferences with toolchains the system should support? Personally I have limited experience with this.
Hi Petteri- This is good stuff, thanks for looking at this. I've been able to get all the way through AID creation (including Blake3) with a tester app of my own in Chrome after make several changes to signify-ts. Of course after these changes my tests won't run in signify-ts repo. However, I'm wondering if this is the right approach. I'm not sure we want to be running a signify client in a browser by loading the client as a web app. Instead, I've started working on an Electron app that can be packaged and signed to provide more secure code delivery. With this approach, we can leave signify-ts as a Node library and run the signify code in the main process of the Electron app (which is Node). Eventually we may want to deliver multiple modules from signify-ts for browser and Node but maybe not in the short term. What does everyone think?
I like the electron route, we used it for keep for our first iteration and while signing can be awkward to get right (thanks Apple) I does feel right. I'd also like to see where bundling with things like Ionic/Cordova/Flutter/Tauri could push a "better" user experience opposed to rebuilding web apps from scratch with things like Mithril.
Maybe there could be some an alternative route with Cesride and Tauri to do a PoC, see what signing at the edge looks like with that stack O_o
¯\_(ツ)_/¯
so many options (but I like building and signing locally regardless of the stack)
So yeah, Tauri looks a lot like Electron but with Rust as the "main process" instead of Node. So if we keep the UI clean enough in the Electron app it could be repurposed over to Tauri. So all Signify stuff stays out of the UI and can be implemented in either Rust with CESRide or in Node with Signify-TS
petteri.stenius
Thanks, this is good discussion. Is this a slight change in direction or priorities? From my perspective the main difference to Keep is that, because of signify edge model, the Keri Agent does not need to be local but can exist in the "cloud". However, as with Keep, this model requires installing a thick "desktop client" and in the short term does not support web based clients.
contact.johannes
<@U04PXR871PS> has joined the channel
<@U03RTP08W3B> has joined the channel
This message was deleted.
No, they are targeting different functionality. I would assume that there would be a signify-ide or signifide or signide or something similar that would consume CESRide and expose the same functionality as signify-ts.
But that doesn't exist yet
That's very premature. Signify is still a work in progress as we are just starting to flesh out what the API looks like. As I mentioned in the thread above, there is sill a missing piece in Rust that would be a version of Signify that consumes CESRide.
Instead of a barrage of questions all over Slack, my I suggest attending a few of the KERI Working Group meetings and get these questions on the agenda. It will be a much more productive way to discuss.
I wouldn't characterize this as a change in either direction or priorities but more of a learning exercise trying to find the best path forward. Seeing the limitations of the current version of a TypeScript signify client we, as a community, may want to step back and see if we can coordinate efforts and see if there is a better path.
No, there is a specific project for implementing a did:keri did method resolver.
Meetings are the best place to have the discussions for sure, it’s also nice to put names to faces and do introductions too
petteri.stenius
Yes and I am willing to help with this effort. Would it be possible to have a discussion on goals to better understand things?
> I’m not sure we want to be running a signify client in a browser by loading the client as a web app. > … > Eventually we may want to deliver multiple modules from signify-ts for browser and Node but maybe not in the short term. What does everyone think? We could write a browser extension wallet similar to MetaMask. I haven’t done one yet though I want to explore that option. Has anyone tried this route or are there any reservations against a browser extension for signing at the edge?
I have no reservations at all. If we can sign the client code to protect the code delivery with KERI, that would be a great option
petteri.stenius
Hi <@U024CJMG22J>. I tried running the tests for latest code in keria and signifypy. Looks like the identifiers that get generated in my env are not stable. Could some bootstrapping config be missing?
That repo is a work in progress. I'm not sure what state the tests are in right now
petteri.stenius
I was able to work around identifier issues but run into other issues such as `AttributeError: module 'keri.end.ending' has no attribute 'siginput'` I'll wait for things to become more stable.
petteri.stenius
Signifypy sends signed http requests to keria. Is this based on IETF draft ?
Sorry Petteri if I wasn't clear but this repo is not expected to be in a state yet where other can use it. I'm pushing code there just to get started but there are changes to KERIpy that haven't been merged in yet.
I need to have a conversation with Sam next week about the changes I've made to KERIpy before I push them.
I'm hitting some unexpected problems implementing signing at the edge that is going to require more refactoring than expected.
Yes, that is the HTTP signature scheme we are using
daniel.andersson
<@U04DQE2G36F> has joined the channel
Some really good news just in time for IIW. Today I added support for multi-tenancy to the KERIA server. So a single running instance of KERIA will be able to support any number of isolated Agents that each support a Signify client. We feel like this will greatly reduce deployment complexity and enhance scalability. I'll be holding a session next week at IIW to review the KERIA architecture and Signify client design and make plans for collaboration moving forward.
Wow, that is excellent news! I will be at that session. Great work.
petteri.stenius
Sounds really good <@U024CJMG22J>. I can't make it to IIW this time. I hope you can share your presentation later.
petteri.stenius
Hi <@U024CJMG22J>. What's the state of keria and signifypy tests? I can get the keria tests to pass but almost all signifypy tests are failing.
Hi Petteri- Last week we focused on getting the KERIA repo squared away with CI, test coverage and docker image. The rest of this week we will be focusing on the same for sygnifypy. We just added a new resource to our team so we expect to start making even faster progress.
Stay tuned for PRs to SignifyPy (posted to <#C04NGM6FJ73|signify-dev>) as we come up with a solid testing approach for mocking API calls and start fixing and filling out test coverage.
I haven't really spent time to learn about signify, but there may be some similarities between this concept and something that we have been calling "client-managed secret mode" in the DID Registration specification, where we tried to separate DID operations (which can be performed by a remote service) and key operations (which are always performed locally): •
This is very cool. I liked the walk through of challenge/response, etc. The universal registrar is acting similar to KERIA and the web client, local key management, etc. are like a signify client. I’ll be interested to see what others think!
Certainly more complexity/features with KERIA/Signify but similar concept
rodolfo.miranda
Great podcast! Thanks for sharing.
rodolfo.miranda
<@U024CJMG22J>, quick question. Can you briefly tell what the `addEndRole` call does in signify/keria?
Thanks for the links, I'll check this out this afternoon
As the name (sort of) suggests, end roles provide authorization for endpoint providers to serve a given role for a controller. So for example, every witness serves in the witness role for the controller of an AID by virtue of being a witness declared in the KEL. For other roles, like the new `agent` role in KERIA, the controller has to declare the role manually by signing end role data that gets shared then with an OOBI
I don't think I've shared these yet... here are my slides on KERIA from last IIW.
rodolfo.miranda
oook. Should the `agent` role need to be added to each AID created in KERIA?
Yes it should. I originally had it happen automatically in the Signify client but that over complicated AID creation so I created a separate API call.
But it has to be initiated in the Signify client because it involves signed data.
rodolfo.miranda
got it. thx
rodolfo.miranda
When using salty key type, how is the key chain determined? Initially, the path (stem) and the passcode is required , but how the next keys are derived from there?
By creating a path that is passed to libsodium that is made up of the stem, the AID relative index with in a give "wallet" and the key index with in the identifier
rodolfo.miranda
great, thanks! Sorry for the silly question, but I couldn't find easily on the code.
rodolfo.miranda
I'm researching if we can do something with those crypto hardware wallets such as the Ledger Nano or Trazor and connect them as a HSM to signify.
Check out
That is an implementation of a SHIM (Signify HSM Integration Module) for Google Cloud KSM
Clone that and reimplement the methods in the GcpKsmShim class using the hardware wallet API
And then look at the `test_extern` method in `integration/app/integration_clienting.py` in Signify for an example of how to load a SHIM and use it to create an AID.
Let me know if you have any questions. The API for SHIMs is still experimental so any suggestions for improvements would be appreciated.
petteri.stenius
This is a helpful presentation, thanks! Could you explain in more detail the multi-tenant design? Is the workflow with the boot interface something like this: boot -> perform operations -> un-boot?
<@U024KC347B4> can you post the Signifide meeting invite (or details) here?
Signifide doesn't technically have a call
No, the `/boot` interface is not like locking and unlocked from the Mark I agent. Instead, you use the `/boot` interface to provision a new agent worker (analogous to the previous Agent) on behalf of a controller (Signify client). That call is only needed once and is out of band relative to the communication between the Signify client and KERIA service. So for example, if someone were to host KERIA a a service, they would provide a web portal for users to sign up and expose the `/boot` interface to internal infrastructure only. Once the user is signed up and provides the information from their Signify client needed to provision an agent worker, service provider calls `/boot` internally and returns connection information to the signify client. From that point forward all API requests and responses between signify client and KERIA are signed and authentication with KERI signatures and routed to the correct agent worker using the AID that signs the request.
I should have said keride?
the same would apply
okay i thought i was missing them, but you can’t miss what isn’t there ;p
we should use the cesride call to talk about it. Is the general KERI call the place to discuss things? do we want to a keride call to replace cesride? keride is my solution to potential library proliferation in the Rust ecosystem <@U04HQD29Z7E> is the only one using cesride in production I believe so he should be on the call to discuss
rodolfo.miranda
other option is to have just one broader dev call.
rodolfo.miranda
<@U024CJMG22J>, for Randy key types, in the ppt you said "Private keys, next public keys encrypted on client and stored on Agent". Which key is used to encrypt? the signifyClient key? And a second question: how rotation events on the signifyClient AID are communicated to the Agent?
rodolfo.miranda
I'm sharing some screenshot of a working trezor-shim. A SHIM is a Signify Hardware Module Extension. In this case, I implemented a shim for a Trezor Hard Wallet, those personal devices that are mostly used as cryptocurrency wallets. Private keys are generated in device and never leaves it, so the shim ask to create the signatures.
Captura de pantalla 2023-05-08 a la(s) 10.33.17 a.m..png
rodolfo.miranda
I used ed25519 keys but this model (Trezor One) also support secp256k1. Keys are deterministically derived from the main key. I still need to clean the code and review some existencial questions with Phil.
Technically SHIM stands for Signify HSM Integration Module.
This is very exciting stuff!!
rodolfo.miranda
I think those kind of devices can be really helpful. They are a good match for Signify
I updated with a (really raw) example app, changes to support browser deployment and a first pass at a SignifyClient class. <@U03P53FCYB1> and <@U0474LZ0ZLG> :eyes:
I also added github messages for the repo to <#C04NGM6FJ73|signify-dev>
rodolfo.miranda
<@U024CJMG22J>, one thing that confused me in your `gcp-ksm-shim` is that it signs the sha256 hash of the event (`hash_ = hashlib.sha256(ser).digest()`). So when I tried a similar approach signing a hash of the event, either sha256 or blake3, KERIA fails verifying the signature. However when I sign the full ser, KERIA doesn't complain. So I wonder if using a hash is OK and how you let KERIA know that.
`@types/libsodium-wrappers-sumo` - this development tool package should be in `devDependencies` block, shouldn't it?
libsodium is core to the functionality of signify-ts and not a development tool
I meant the type definition package of `libsodium-wrappers-sumo`. While `libsodium-wrappers-sumo` serves as the crypto library as a normal dependency, `@types/libsodium-wrappers-sumo` serves as a tool for development as its type definition. I had an error while I was installing npm dependencies with the current `package.json`.
Oh, ok. Unless we are exporting any types from libsodium it would be ok to move the types into devDependencies. _We accept PRs_
rodolfo.miranda
Reposting this question in case it got lost :grinning:: <@U024CJMG22J>, one thing that confused me in your `gcp-ksm-shim` is that it signs the sha256 hash of the event (`hash_ = hashlib.sha256(ser).digest()`). So when I tried a similar approach signing a hash of the event, either sha256 or blake3, KERIA fails verifying the signature. However when I sign the full ser, KERIA doesn't complain. So I wonder if using a hash is OK and how you let KERIA know that.
That is specific to the ECDSA algorithm used for the secp256 signatures.
Ed25519 does something similar but inside the signing algorithm so externally you just sign the full data
rodolfo.miranda
good to now the reason. Thanks!
Hey folks, we've been having some discussion and it seems given the direction and momentum of signing at the edge (signifypy, signify-TS, and signifide) and the drop off in the need for an edu call, alongside the completion of CESR (way to go Jason) that we could re-purpose both calls for a weekly signify dev call. We've seen increased interest from multiple parties and it seems wise to utilize this (Thursdays 10am EST) slot moving forward. The call will be focused on those implementing "signing at the edge", integration with KERIA etc, and not focused on spec Q&A (we have Tuesday calls for that). We'll likely try rotate the focus between implementations if we find the need to do so.
Looking forward to this! Lots of interest already!
It has been pointed out to me there is considerable interest around `did:keri` as well and we still need a slot for that. We might want to consider these weekly calls "KERI Dev" calls, and shift the focus.
I agree, keri-dev calls with a focus on the hottest community development efforts
I agree with Kevin and Lance. Focusing the dev calls on the hottest and most desired new developments would be ideal. I’m so glad at the success of the CESR group call and am glad to have contributed at least a little bit. Kevin and Jason did all the heavy lifting there and I’m glad I got to be along for the ride. I hope to be a significant part of Signify, KERIA, or did:keri
~Kevin and~ Jason did all the heavy lifting
:smile:
Hah there were plenty of long reviews and I believe you wrote the spike Matter and Indexer code, Kevin.
I think KERI-dev makes sense, at least from my perspective :smiley:
nuttawut.kongsuwan
When will be the first meeting?
Looks like it will be next week. This week will be the final CESR meeting
nuttawut.kongsuwan
Thanks!
I’m glad to continue providing the Zoom link for the keri-dev calls for as long as we’d like.
rodolfo.miranda
is the call today?
Next week start
No, the first one will be next week. I'll try get details out today/tomorrow to clarify things
rodolfo.miranda
:+1:
rodolfo.miranda
We published the Trezor-SHIM here: . Comments are welcome!
Why is `bran` in `Controller` the argument passed in to the `passcode` parameter in `SignifyClient`? And then in Controller the following code makes it look like passcode is being used as a salt:
self.bran = coring.MtrDex.Salt_128 + 'A' + bran[:21]  # qb64 salt for seed
I’m trying to reuse the controller keypairs I made with the KERIpy KLI in KERIA and I haven’t figured out how to do that yet.
Is the initial controller AID created for the `SignifyClient` an instance-specific AID for this particular usage of SignifyClient?
You would not want to do that
Have you read discussion 34 in KERIA?
I am reading through it now, thanks for the heads up.
I have some questions on a few things after reading through the Kevin posted in the Signify repo today. 1. How do I generate the Signify Client AID? Do I use the KLI or does Signify provide a mechanism here? 2. How do I get the signed inception event? Can I just export it with the KLI?
Also, 3. How do I sign the HTTP request with the client AID? Is it just the body of the request that needs to be signed?
All of these are provided by the signify client
That’s why it needs minimally sufficient KERI
Is there an integration or other test that walks through the three items above? Each test I’ve run has always got a 404 when issuing the initial connection request to KERIA saying
keri.kering.ConfigurationError: agent does not exist for controller ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose
I’ve got the kli witness demo network up and running as well as KERIA. I’m thinking I’m missing the out of band part in Step One defined in the protocol:
signed inception event out-of-bands to the KERIA service through the Boot interface
Yes, in SygnifyPy with a running KERIA
Do I need to run the `connect.toml` requests through KERIA?
Ok, I see, in the `def test_connect():`function in test_clienting.py. I’ll give it a shot
There is a file, `integration_clienting.py` that works when run with python against an instance of KERIA
A main at the bottom where I comment out test cases. That’s how I test it so far. No time for anything else or to document it for anyone else n
Got it, totally understand. You’re slammed. This is what I needed. I should be able to figure it out from here. Thank you.
andreialexandru98
:wave: Is the same passcode supposed to generate the same aid for all signify clients? because when I try to use the `0123456789abcdefghijk` to generate aids, I get different ones for python and typescript sdks, same "tier"
With the new Salty algorithm the salt is unique per AID. If one isn’t passed to the create call, a random salt is created for that AID
andreialexandru98
but if I pass the same salt it should create the same aid between libraries
andreialexandru98
right?
Which AID are you talking about? Client AID or or a managed AID?
andreialexandru98
client aid
This is causing a lot of people confusion. Let me write something up about it
Could anyone share a few words Why SKRAP is needed and who will use it? The text in the repo is about the What and How, not the Why and Who yet. I’d like to improve this:
rodolfo.miranda
<@U024CJMG22J>, quick questions regarding HTTP header authentication/signing: 1- response signature headers are not implemente yet, but they will, right? 2- when the headers are validated, should't we add other enforcements such as timestamp check and nonces to avoid replay attacks?
1 - Yes 2 - all of that is yet to be designed. If you have ideas please document them in issues
rodolfo.miranda
I’ll create issues…. and PRs :wink:
Thank you.
Mobile clients will be using SKRAP to connect to KERI AIDs via agents in the new, multi-tenant Mark II Agent server, KERIA.
SKRAP is a client to the KERIA server.
Also, browser extensions will use SKRAP in order to use a wallet similar to MetaMask, except it will be KERIMask, and it will be a browser extension.
KERIMask will connect to KERIA servers in order for a person to control AIDs from their browser extension.
SKRAP is also usable from HSMs and hardware wallets because the keys from the hardware wallet, along with some app code, connect through SKRAP to agents running in a KERIA server.
Signify implementers... (especially <@U0474LZ0ZLG> and <@U03P53FCYB1>), I created an initial description of documenting the client AID creation process here with a sample AID and inception event based on a passcode:
This document will be fleshed out with full details up to and including AID creation with Salty and Randy.
What is the equivalent to the `-c [AID]` argument in the current form of KERIA? In trying to run the Signify tests in `integration_clienting.py` I see the following doc comment in the `def test_salty` test:
    """ This test assumes a running KERIA agent with the following comand:

          `keria start -c ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose`

    """
I’m looking through the code of old versions of KERIA and I see the `-c` stands for `--controller` :
parser.add_argument('-c', '--controller', required=True,
                    help="Identifier prefix of the controller of this agent.")
This was then sent to `agenting.setup` as `conAid`
doers.extend(agenting.setup(name=name, base=base, bran=bran,
                                ctrlAid=ctrlAid,
                                adminPort=admin,
This further made it into Habery:
`conHby = habbing.Habery(name=conAid, base=base, cf=cf)`
And Authenticater:
`authn = Authenticater(agent=cagHab, caid=conAid)`
And the BootEnd:
`bootEnd = BootEnd(cagHab, conAid)`
That is no longer needed
Ok, I’ll just try running the tests without it, both the recorders and the ones that consume recorded requests.
To be clear, the code to sign responses exists in KERIA and the code to verify the signature on responses exists in SignifyPy, it just hasn't been tied into the response workflow on either side yet
According to that new document you just posted I think I’m missing creating the Agent AID. This seems like it has to come first in the overall process.
in SignifyPy in `test_salty` If I have the URL in the `client = SignifyClient(url=url, passcode=bran, tier=tier)` statement then I get an error `ConfigurationError('agent does not exist for controller EOgQvKz8ziRn7FdR_ebwK9BkaVOnGeXQOJ87N6hMLrK0')` If I take the `url` argument out then I get past that error, though my point here is I think I am missing some bootstrapping in the KERIA agent. I don’t mean to ask the same question over and over again. There’s something I’m just not getting or just missing on how to initialize `SignifyClient`
OMG, I got past that point. I just had to move the `url` argument from the `SignifyClient` controller to the `client.connect` call.
It looks like the call from the SignifyClient constructor will fail every time because the POST to the `/boot` endpoint hasn’t occurred yet.
Do I have that right?
I just saw your latest commit. Thanks Phil!
I’ll help fix the rest of the tests.
rodolfo.miranda
Hi Kent. For the test just run `keria start` except from the one that needs witness that you may execute `keria start --config-file demo-witness-oobis.json --config-dir ./scripts`
rodolfo.miranda
the Agent AIDs are created automatically by KERIA on each \boot request. You don't need to worry about that.
rodolfo.miranda
If you execute the `test_salty`youl'll see that after creating the SignifyClient there's a call to the `/boot` interface, and just after that is the `connect()` function that generates the first interactions between SignifyClient and KERIA.
rodolfo.miranda
<@U024CJMG22J>, I realized that the client AID generated in signifypy differs from the client AID generated in signify-ts (from same passcode and Tier). Generated keys differ as well. Were you able to make that type of comparison before? I'll dive deep into the code; should I start from the Salter?
<@U03P53FCYB1> did you double check that each client generates a deterministic AID after each run? Granted the two impls might have a difference. But make sure two runs of the same impl produces the same AID.
andreialexandru98
The same passcodes generates the same aid with the same sdk but not cross sdks. I asked the same question yesterday :see_no_evil: and Phil created the getting started doc
andreialexandru98
I noticed that the tier level grately impacts the time it takes to generate an identifier! high tier takes around 30ish seconds on my computer
rodolfo.miranda
both SDK use libsodium argon2. I understand that they should generate same keys from same salt.
andreialexandru98
That’s what I thought too
rodolfo.miranda
The tier maps two parameters on the libsodium library that are used to create entropy: - opslimit represents the maximum amount of computations to perform. Raising this number will make the function require more CPU cycles to compute a key. This number must be between crypto_pwhash_OPSLIMIT_MIN and crypto_pwhash_OPSLIMIT_MAX. - memlimit is the maximum amount of RAM in bytes that the function will use. This number must be between crypto_pwhash_MEMLIMIT_MIN and crypto_pwhash_MEMLIMIT_MAX. So, the higher the more entropy but slower.
nuttawut.kongsuwan
Do I understand correctly thy ACDCs are meant to be signed and verified at KERIA servers and not at the signify clients?
rodolfo.miranda
I found the problem in the derivation path!!
rodolfo.miranda
Still need to figure out some stuff, but the problem was there because I can now get the same keys.
rodolfo.miranda
Finally got the lovely AID "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose" in TS
No, Signify signs things at the edge. This includes ACDCs. KERIA will be used to send communications between agents. The things KERIA sends are signed by Signify.
Nice work Rodolfo.
Something so rewarding about getting the crypto/CESR right!
PRs to both KERIA and SignifyPy to enable and validate HTTP signature headers on all responses from the KERIA service by the Agent.
This shouldn't break signify-ts since you will just ignore them anyway.
nuttawut.kongsuwan
I see. Thanks for the clarification.
andreialexandru98
Does the format of the timestamp matter for checking the signature? I am noticing that JS and python display it differently?
Screenshot 2023-05-20 at 9.07.05 PM.png
rodolfo.miranda
it does not matter because. It's just copied as a string in the signing bytes. We should make the uniform though.
Thanks for the answers! See the result:
But now you’ve introduced another term: KERIMask. What is it and why should I use it?
I was riffing off of MetaMask, the Ethereum wallet that is both a browser plugin and a mobile wallet. Once we make an open source wallet implementation then we will name it something.
KERIMask isn’t the best name, it’s just the first one that came up.
Will credential issuance be a part of KERIA, Signify, or both? It would seem like the ACDCs, and any key events, in order to be signed at the edge, would have to be sent to the edge for signing or would need to originate at the edge and be sent to an agent. Is one of these options the design here for Signify or am I misunderstanding the architecture?
I am getting a sense of where to prioritize my efforts with regard to KERIA in order to have the same or similar credential issuance flow in KERIA/Signify that I do with the Mark I agent in KERIpy.
A signify client would great an `iss` event and send that to its known KERIA instance.
Events are created and signed, they go from the edge (client) to the agent (cloud) (KERIA)
This makes sense. Thanks
Do you happen to have handy a reference to where the `iss` event is created in KERIpy or how that sort of an event is managed? I see 18 references in KERIpy, most in eventing.py. I haven’t read through eventing yet though will be. I want to learn everything there is to know about `iss` events so I can add this functionality to SignifyPy because this is my current roadblock. I’ll be coordinating with Phil on this as well.
Yes, credential APIs will be ported to KERIA AND Signify
Here’s a spreadsheet comparing the REST APIs of both KERIpy and KERIA: This will help us keep track of the work that needs to be done, if something like this doesn’t already exist. From the looks of things most, if not all, of the KERI work is done in KERIA. The primary work remaining unfinished is the ACDC work.
Next steps look like: 1. keria Finishing registry inception - refactoring to a long-running Op. Refactor registrar to support Signify event creation. 2. keria Credential Issuance and Revocation Single Sig POST /credentials/{name} DELETE /credentials/{name} Multisig Group Credential Issuance POST /groups/{name}/credentials PUT /groups/{name}/credentials Multisig Group Credential Revocation POST /groups/{name}/credentials/{said}/rev PUT /groups/{name}/credentials/{said}/rev 3. keria Credential Management and Presentation POST /credentials/{name}/presentations POST /credentials/{name}/requests Credential Retrieval GET /credentials/{name} Credential Export GET /credentials/{name}/{said} 4. signifypy Codes ported to SignifyPy? GET /codes POST /codes 5. Local AID creation and management API requests 6. Multisig AID participation and management API requests
This should all be captured in the issues
I believe it is. Do you want all of those routes to be added to the issues? I’d be happy to add them.
No as long as the list of tasks in each issue is complete.
rodolfo.miranda
<@U024CJMG22J>, if from Signify I want to create an AID with witnesses that are not known by KERIA, should I introduce them using oobi interface? Or witnesses need to be known by the keria config file?
Love this! Seems like this could grow into a great reference for endpoints... from one POV it could underpin swim-lane work flow graphics, and from the other side it could be a launchpad into the source. <@U02PA6UQ6BV>
I agree, will discuss this with Kor and see what we can do.
Are there any related columns? We might need a legend for the column names and their domain
Let’s talk through it.
Yes, there are related columns, though in what sense do you mean?
I tried to make it clear in the column labels though I’m sure the labels could be improved.
Are there values in one column that are the foreign key to another one
Columns A through K refer to KERIpy. Columns O through Q refer to KERIA.
No, there are no foreign keys.
What does CODE mena
HTTP Response Code
Right, thx
What does ‘Body’ contain?
HTTP Response Body
Note that the labels were hard for me to read because of the dark background. (Couldn't see them at first!)
Some of the column values in the Body column are similar to a JSON object, some are more textual because that was a better description of things.
Yeah, the labels were hard to read. LibreOffice automatically changed the text color to white when I made the background color black yet it turns out Google Sheets wasn’t smart enough to do that. Win for open source.
I’ll look it up, should a level 2 SSI specialist have this input knowledge?
I fixed it though.
Yes, and I did the KERIA tab :slightly_smiling_face:
What is level 2 again?
Two star SSI expert: grasping autonomic identifier systems
And which input knowledge are you referring to? This entire sheet? Or a specific column?
Were you referring to the contents of Column E, HTTP Request body?
Back to your sheet: which column could contain links into the repos
I haven’t thought about that yet. It would probably be Column B since that is the granularity of a specific handler function in KERIpy or KERIA.
Column B for KERIpy and column P for KERIA.
And what about column I in the comparison tab
could it link to a certain github page?
I thought about that and I don’t think it’s necessary since the endpoints are already linked.
Column I could be linked, though it is only to the top level class.
Walk in the shoes of a newcomer, level 2
Would he / she fancy a link straight into the repo?
Yeah, likely.
Then let’s do it :slightly_smiling_face:
Let’s postpone the links in Column I until after KERIA is finished. Some of the endpoint classes will be deleted once the KERIA agent is finished.
Documentation is always “under construction”, give me one example where to find “CredentialEnd” for example and I’ll do the rest
KERIpy:
Wow! great, bullseye
Double entendre in your situation
Are there any other columns that could have direct links into any repo-file, if so pls tell me, because then we could go find and add them to the sheet as separate (hidden) columns and create infographics from the sheet.
Great work, Kent
Just checking: the KERIA-link to OOBIEnd, right?
And this one in KeriPy:
Yep, those look right.
All links inserted in the sheet, two tabs. Have a look at the orange cells, you might wanna check their content. The link is based on line-numbers and filenames, so the anchor might point to the wrong line when the file’s content changes in the future. If the filename changes we get a 404, if the class will be moved to another file (worst case), a user of the link will have to start a search again.
The signify client has to do an OOBI exchange with the witnesses they want to use. Or you can also put them in the configuration file of the KERIA process.
rodolfo.miranda
<@U024CJMG22J> I'm struggling with `test_delegation` in signifypy. How are you running it? I try with the delegator kli from `delegate.sh` but I'm not able to receive the final confirm. Hints?
Lance created a script in SignifyPy to run it all
I have not tested it yet
When I was writing that test I would comment out everything in the delegate.sh script in keripy but the delegator creation and then run the OOBI resolve and delegation confirm steps by hand.
I haven't merged it yet because it depends on a keria update that I haven't merged yet I should be able to get all that in tomorrow but see here
I'm also happy to walk you through it once I get it all committed <@U03P53FCYB1>
rodolfo.miranda
updating keripy solved my problem :upside_down_face:
Captura de pantalla 2023-06-09 a la(s) 10.40.09 a.m..png
<@U024CJMG22J> I have caught my keria PR up to your changes AND the coverage has increased :slightly_smiling_face:
rodolfo.miranda
For the Multisig test, my KERIA is not receiving the receipts confirming the signatures from the other agents (keripy) so it keep the long operation forever. Is it working OK for you <@U024CJMG22J>, <@U035R1TFEET> ?
Yes, is was working for me the last time I ran it. Did you OOBI with the AID on the agent using an agent role OOBI?
I added support for the delegation portions to the integration script in signifypy. I’ll do the same for multisig now so that it will be easy for anyone to run the full-test.
rodolfo.miranda
yes and was resolved OK. I'll keep trying...
Okay, it’s close-ish but will take a significant amount of debugging to get the prefixes, etc correct. Which means it would be best to tackle this once i can run them as unit tests instead of integration tests….. i have several tests running like that now but hadn’t done multi-sig. i was having some issues there as well, even though some of the unit tests work…. so, there is no easy answer on this. I’ll commit what I have on my branch.
I looked at the integration test for multisig in SignifyPy and it hasn't been fixed since implementing multi-tenancy in the Agent. Because we don't have a need for multisig just yet. I'll try to fix it now and get it working again, hopefully tonight.
rodolfo.miranda
You make my day with that!!!!! :slightly_smiling_face:
A few glasses of wine and couple of bourbons and it will be done. What better way to spend a Friday night.
I found the problem... during the mutli-tenancy refactor I forgot to register the multisig processing Doer.
I'll have a PR in a bit. I'll also edit the existing script in keripy. I forgot I created that one already.
The multisig is created successfully for the two command line participants. However, the Agent is still not getting the events from the other participants because the registration of Agent endpoints appears to be broken.
I am headed to the San Diego Zoo now but will finish fixing this when I get home this afternoon. I've pushed what I've done so far to branches in the 3 repos.
Still working through it. The agent OOBI resolution isn't working because the delegation relationship is not established so the agent's KEL is not resolving. I'm a little disappointed I switched to the delegation relationship because it has over complicated matters.
Remember that time I added delegation to KERIA and when creating the anchor seal I created the one for anchored TEL events and not anchored delegation events. Yeah, those were good times... :neutral_face:
I have a more generic solution for this that I am running by Sam to see we can go this way. Hopefully have it all patched by the end of the day.
rodolfo.miranda
<@U024CJMG22J> :
keria start --config-file demo-witness-oobis.json --config-dir ./scripts
The Agency is loaded and waiting for requests...
  Agent: EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei   Controller: ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose
Sending multisig event to 2 other participants
Waiting for other signatures for EE-643P7FUUG8-8ffVupf6iiMcE3VMx42chE4UUiBmWr:0...
Waiting for fully signed witness receipts for 0
Witness receipts complete, EE-643P7FUUG8-8ffVupf6iiMcE3VMx42chE4UUiBmWr confirmed.
Successful multisig????
that seems like very good output
rodolfo.miranda
yeah!
Woohoo!!! :tada:
Is that from the TypeScript client?
rodolfo.miranda
keripy + signify=TS
rodolfo.miranda
accepted on kli as well:
Alias:  multisig
Identifier: EE-643P7FUUG8-8ffVupf6iiMcE3VMx42chE4UUiBmWr
Seq No: 0
Group Identifier
    Local Indentifier:  EKYLUMmNPZeEs77Zvclf0bSN5IN-mLfLpx2ySb-HDlk4 ✔ Fully Signed

Witnesses:
Count:          3
Receipts:       3
Threshold:      3

Public Keys:
        1. DOZlWGPfDHLMf62zSFzE8thHmnQUOgA3_Y-KpOyF9ScG
        2. DHGb2qY9WwZ1sBnC9Ip0F-M8QjTM27ftI-3jTGF9mc6K
        3. DPmhSfdhCPxr3EqjxzEtF8TVy0YX7ATo0Uc8oo2cnmY9
That is freaking awesome!!!!
Next up, keripy, SignifyTS and SignifyPY
So the approach we took to credential script in SignifyPy would work here. Bash that uses kli and python against signifypy scripts.
And then however you are orchestrating the SignifyTS side
Traceback (most recent call last):
  File "/Users/eujinong/signifypy/scripts/create_person_aid.py", line 112, in <module>
    create_aid()
  File "/Users/eujinong/signifypy/scripts/create_person_aid.py", line 23, in create_aid
    identifiers = client.identifiers()
                  ^^^^^^^^^^^^^^^^^^^^
  File "/Users/eujinong/signifypy/src/signify/app/clienting.py", line 197, in identifiers
    from signify.app.aiding import Identifiers
  File "/Users/eujinong/signifypy/src/signify/app/aiding.py", line 13, in <module>
    class Identifiers:
  File "/Users/eujinong/signifypy/src/signify/app/aiding.py", line 175, in Identifiers
    def addEndRole(self, name, *, role=Roles.agent, eid=None):
                                       ^^^^^^^^^^^
AttributeError: 'Rolage' object has no attribute 'agent'
While I was testing the receiving credentials to KERIA agent AID, encountered `creating AID` issue. I am not sure what I've done wrongly. According to Keripy, Rolage does have the agent attribute.
What version of python are you using?
3.11.1
Do I have to downgrade to `3.10.x`?
Not sure. Haven't seen this error before but also haven't used 3.11 in a while. Might be worth trying.
Okay, got it.
After downgrading to 3.10.4, the same issue was raised. The issue has been fixed by fetching the latest KERIpy implementation directly from GitHub. `keri>=0.6.9` on PyPI still provides the old implementation KERI package which doesn't include updates in support of Signify client and KERIA agent (`Rolage` doesn't have `agent` attribute).
I've enjoyed the demo of demonstrating vLEI credential issuance to KERIA AID. It means a lot to me. :+1:
Ok cool. Thanks for tracking that down. Glad this work is helpful for you!!
rodolfo.miranda
<@U024CJMG22J>, some questions regarding `/challenge` method in KERIA 1. I couldn't find the `challenge verify` method. Is it just a pending task or missing for a specific reason? 2. What is the purpose of the `put` method (challenge response acceptance)? what's the equivalent on `kli`? 3. When I tried the `challenge response` (/post method) KERIA crashed. Were you able to test it? We implemented the `contacts` method in signify-ts and works perfectly.
rodolfo.miranda
OK, 1=2.
Why would `SignifyClient.connect(url=url)` cause a ValueError `"Missing or empty version string in key event…"`? This is happening in the issue-ecr.sh script, yet it hasn’t happened anywhere else for me.
Pull all the latest pushes. A change in KERIpy broke KERIA and the Signify's
Yep, that’s it. It works once I pull latest.
<@U03P53FCYB1> It looks like I already ported the notifications endpoints over to KERIA. They are available at `/notifications` and `/notifications/{said}`. The API should be available in the SwaggerUI.
This is a generic notification mailbox feature that we used heavily in KIWI and the Keep to send notifications to users for things like credential issuances showing up, credential presentation requests and multisig group notifications.
With Kent's help we have credential registry creation fully working in KERIA. I'm going to start on credential issuance and presentation now hoping to have working code to push before EOD tomorrow. That way, you could work on the client side in Signify-TS while I'm on vacation and then SigPy can catch up later. Sound good?
Thank you both, that's amazing!
Woohoo! This will be awesome! Just what we need.
rodolfo.miranda
Sounds great!
This is significant. The client needs to get the registry information and then needs to create the credential, the TEL issue event and decide whether to create a rotation or interaction event and then decide what to do about a potential multisig event.
And then sign everything.
merged with credential issue endpoint.
The endpoints for registries were also updated to match the conventions in the rest of the API. They are now `/identifiers/{name}/registries`
Draft up on KERIA for credential presentation and presentation request endpoints.
Should have it merged tomorrow morning if I survive this trip
andreialexandru98
Drafted an implementation of an “interceptor” in keria that allows it to send the events that are happening in the background to another webhook. The reasoning behind it is to have the keria agent relay information to other services rather than the signify client orchestrate who to send the data to. I noticed that there’s a notifier class but that can only be leveraged to notify other witnesses or agents and not just an http endpoint. Would love to get some feedback if there’s a better approach!
Posted a today in KERIA. The current list API for credentials in an Agent was woefully lacking important functionality that I hope to address with this PR. I still need to integrate the search object into the REST API and add a bunch more tests so the PR is in Draft for now. I wanted to get people's impressions of it ahead of finishing it up.
rodolfo.miranda
<@U024CJMG22J> Took me bit of effort to issue a VC when the issuer has witnesses. I needed to add some missing stuff in KERIA. Please, check PR . With those changes, everything works fine now.
I agree about the added witDoer and messages. Please see my comment about the `elif` and `else` changes. I don't think those changes are needed.
Merged!
rodolfo.miranda
thx!
Is this for issuing VCs from SignifyTS with KERIA agents? Or with the KLI?
rodolfo.miranda
It's for issuing VC from signify (ts and py)
rodolfo.miranda
that credential was revoked from Signify/KERIA:
{
    "sad": {
        "v": "ACDC10JSON000197_",
        "d": "EDRys0t8LGBzEwr_PEMyKB-Zum4khrfjXEEkM1bqVU-4",
        "i": "EPKRyynUGOe4M4Jw7PvDxxy4Vzg3AtDaYnHBUQcoKRSl",
        "ri": "EJzrfpXVlEP_J9aC4e83dfAPgKM4hnonOO2eEurYAAbG",
        "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao",
        "a": {
            "d": "EMS62P6fJ3zzwkUBfwgZQwcP1I9LMOb5T84-2_Bm0ydd",
            "i": "EDS4HyWpejtqKem_QcJwBKYNF1_TU0rDn0cbuNsOQjHu",
            "dt": "2023-07-13T18:48:56.736000+00:00",
            "LEI": "5493001KJTIIGC8Y1R17"
        }
    },
    "pre": "EPKRyynUGOe4M4Jw7PvDxxy4Vzg3AtDaYnHBUQcoKRSl",
    "sadsigers": [{
        "path": "-",
        "pre": "EPKRyynUGOe4M4Jw7PvDxxy4Vzg3AtDaYnHBUQcoKRSl",
        "sn": 0,
        "d": "EPKRyynUGOe4M4Jw7PvDxxy4Vzg3AtDaYnHBUQcoKRSl"
    }],
    "sadcigars": [],
    "chains": [],
    "status": {
        "v": "KERI10JSON000135_",
        "i": "EDRys0t8LGBzEwr_PEMyKB-Zum4khrfjXEEkM1bqVU-4",
        "s": "1",
        "d": "EMLacOpI6FyAn5v6G4tg9WcmbHDPgSka0Y7Ahq8U_4rE",
        "ri": "EJzrfpXVlEP_J9aC4e83dfAPgKM4hnonOO2eEurYAAbG",
        "ra": {},
        "a": {
            "s": 3,
            "d": "EGOWcSi-RCqK4XakApM94dIfWpGl9VDymWB4CaQTHN-A"
        },
        "dt": "2023-07-13T18:49:08.925000+00:00",
        "et": "rev"
    }
}
rodolfo.miranda
<@U024CJMG22J>, I also found that the last TEL dig is in the status of the credential, so there's no need to add anything on KERIA to create the `rev` TEL event.
For those waiting for multisig between Signify clients and the kli, added support for fractionally weighted thresholds to Tholder in SigTS and a series of scripts in `examples/scripts` that allows for the creation of a group multisig AID that is backed by local AIDs from SigPy, SigTS and the kli. Next I'll be making it a delegated AID (to match the requirements of a QVI AID in the vLEI ecosystem).
rodolfo.miranda
Fantastic!!!!
Is the mention of CESR native event serializations foreshadowing? I'm wondering if key/value maps have been designed yet, and what it takes to implement them? I'm just having a discussion about choosing inter-service communication message encodings
This would be an awesome discussion topic for the next meeting. Sam could go on for hours about it! But as a preview, CESR event encoding is going to rely on the fact that KERI events have static field ordering and thus we can make the protocol even more efficient than MsgPack or CBOR by eliminating field labels from the serialization.
Ahhhhh I see. Will there be a facility to use it straight up without field ordering/presence constraints to be able to encode arbitrary data with it? I mean, the `a` fields for example, contain arbitrary keys - so I guess there will be a way somewhere in it, but it would be weird to hack the system by building a bigger, fake KERI event just to encode something in CESR wouldn't it?
We can discuss at a meeting, I will try and remember to attend (feel free to shoot me a message if I forget, I'm on vacation this week, but around)
Sounds good.
That’s a good question that I don’t have an answer for. I imagine a CESR primitive for encoding a map structure is probably in order which won’t be used for known events but could for arbitrary data. We already have support for variable data encoding which could be leveraged but not ideal.
List encoding is definitely supported probably using indexed encoding.
Have a fun vacation!
I wanted to drop an update on two items mentioned in the last KERI meeting and related to my last message. 1. I just pushed changes that allow for the group multisig described above to de a delegated AID also. 2. We already hit a client library that didn't allow a body in a GET request so I had to change the credential search API to a POST against `/credentials/query`. I updated KERIA, sigPy and sigTs. If you want a description of why that endpoint, see my comment on the resource class in KERIA.
Can we get a package push of signify-ts to NPM?
joseph.l.hunsaker
You can always push one to your npm scope (username)
joseph.l.hunsaker
But an official one would be cool
Yeah, that’s what I’ll end up doing.
Easy enough:
petteri.stenius
What's the difference with oobis.get(name, role="agent") and oobis.get(name, role="witness")? I know role="agent" returns an endpoint at keria and role="witness" returns a list of endpoints at witness nodes. I'm asking because I cannot get a multisig group setup completed if I'm using role="witness". With the old Kiwi API I was always using role="witness".
I am working on OOBI support for multisig right now. It is not a straightforward problem to solve. In addition, we are getting rid of defaulting to witnesses providing mailbox support and are going to require explicit declaration of mailbox roles. The issue with multisig is that it will require each participant to approve endpoint roles for all other participants which becomes quite a hassle with Signify.
I should have something pushed by the end of the week
rodolfo.miranda
<@U024CJMG22J>, question regarding the credential query. In KERIA we have the following endpoint to query credentials `/identifiers/{name}/credentials/query"` that is a collection of credentials of the `{name}` AID. However in the `Seeker` I'm not finding that the credentials are being filter by the AID, not even passing that parameter to `find` function. Is there a way to add the AID in the filter object?
Oh yeah, the AID (from `{name}`) is used to load the right Agent (and thus DB environment) but I guess not added to the actual query. That should be very easy to fix
rodolfo.miranda
do we need to add an index for the recipient AID or it's already there? couldn't find it.
        # Index of credentials by issuer/issuee.
        for field in (ISSUER_FIELD, ISSUEE_FIELD):
            self.createIndex(field.qb64)
            subkey = f"{field.qb64}.{SCHEMA_FIELD.qb64}"
            self.createIndex(subkey)
It's here
rodolfo.miranda
ok, but not receiver of the credential if it's not the issuee.
That is not even tracked anywhere
rodolfo.miranda
... so thinking... does it make sense to have one? it need to be taken from the exn message, not sure if it's possible
rodolfo.miranda
I think the index function is called only by the SAID
This would only be for presentations so it would have to be a presentation level database to store it in and I'm not sure how that would interface with the indexing for credentials.
I would think the presentation protocol handlers would want to store their own indexes of "presentations" which could be used to associate presented credentials to AIDs.
That would make presentations a top level construct in KERIA. Not sure how I feel about that.
But could be used to track both incoming and outgoing presentations which might be useful
But I do not think that should be part of the "Credentials" API
rodolfo.miranda
the think that bothers me is that the query method is in the identifiers REST `/identifiers/{name}/credentials/query` and that won't work for presentations others than isuee
... and issuer
rodolfo.miranda
right
These are credentials that belong in some way to that AID. Credentials that are presentations from and about a third party do not belong to that AID. The presentations might
So `/identifiers/{name}/presentations/query` makes sense
rodolfo.miranda
Yes agree, in that case it's correct. One way to solve the query of received credentials is to have an alternative method to query among the full DB independently of the AID.
That's what this is. Back to your original point. the credentials endpoints lets you run it without any filter
That'll give you all the credentials
In the database OF THE AGENT
Not all of KERIA that would be a violation of security
I wouldn't want to use it this way though. Because on the client side, you'd have to query all credentials and show only those that your aren't the issuer or issuee and assume they were presentations.
I would much prefer a presentations endpoint
rodolfo.miranda
so at that time doesn't make to enforce filters by the `{name}` in the endpoint, it won't be totally correct but it's a workaround for presentations until we create a presentation endpoint. User can still add filters manually.
Depends on "correct". They are credentials in the database in which the AID is stored.
which gives you what you want. The name is required to identify the agent through the AID
A wrinkle... You will have credentials in your database that were chained to credentials that you were issued. Those credentials will fall into this bucket but NOT be presentationsl
So this logic will fail immediately for vLEIs
rodolfo.miranda
Ohhh, I like that answer :slightly_smiling_face:
We should probably add a presentations API and datastore
rodolfo.miranda
I think the same. Verifiers may be overwhelmed with VCs that need to be treated separately.
petteri.stenius
Hi <@U03P53FCYB1>. I tried running `request-present.ts` from but I cannot get it to complete. Keria is on latest main branch. Any ideas?
$ ts-node --esm request-present.ts
*** Starting REQUEST-PRESENT test ***
Client 1 connected. Client AID: ELo2ZsLl5C39ZoDNkcUurMXUyvodFi-tgTew09JM_lqw Agent AID:  EADY1vHTlvadY-6A5C3YjNZOFWlZdEx_AuaKMhJ5TGBd
Client 2 connected. Client AID: EHnU14RLuJ1mBv_9c9aksNo3ff0Lj8QqykzNdfGtaWgL Agent AID:  ELBPV0ooTSbWxYMS8h6IeNZGt1RXt5RUAgJ_RnKPKM21
Client 3 connected. Client AID: EAdm-DI46mVxxN_NRaSE8MmeGbBp1-vQLlAGELwkGW9c Agent AID:  EKbmRhB8PIxCQfIAZ9RH3bU1Gvxybr6LzfGFlBrnot3D
Issuer's AID: ENFNTTWjibbsM25hxSzBMJZAXTIgU_IEckaKo7Jv5t3h
Recipient's AID: EKkUeuzjkRDyio_GAZqBK6_WknMs09ttF2AFtFtg3q2c
Verifier's AID: EAOUKzDVmSQM6D-zZX7oGCbDk-YfuNaIXZPh5dWS9r8A
Resolving OOBIs...
Issuer resolved 3 OOBIs
Recipient resolved 3 OOBIs
Verifier resolved 3 OOBIs
Registry created
Credential issued
Credential received by recipient
SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at parseJSONFromBytes (node:internal/deps/undici/undici:6662:19)
    at successSteps (node:internal/deps/undici/undici:6636:27)
    at node:internal/deps/undici/undici:1236:60
    at node:internal/process/task_queues:140:7
    at AsyncResource.runInAsyncScope (node:async_hooks:203:9)
    at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
rodolfo.miranda
I'll check today.
rodolfo.miranda
I couldn't reproduce it. Did you know where it's failing?
petteri.stenius
On the keria side this seems to be the last http request
PUT /notifications/APBk_VRo-hZZFOGtV14NpcH_Zinwk3dxYlROKbL1KG69
petteri.stenius
Ok, my mistake. I did a `npm install` on my working copy and now things magically work... Thanks anyways
rodolfo.miranda
great!
I just ran all of the SignifyTS tests with the `signify-ts/examples/integration-scripts/run_all.sh`. Nice work Rodolfo and Alex! Most of them passed. This is really helpful to use as a reference as I build out an app.
Once I get things working I’ll be able to go update my tutorial.
I’m seeing that successive POST requests to `/identifiers` with SignifyTS with exactly the same name don’t error out. Instead they create separate identifiers. I was under the impression that the *name* property I sent into the `identifiers.create(…)` function was similar to the *alias* property using the KLI and my expectation was that the `/identifiers` would fail on creation of an AID with the same name. This seems like desired behavior unless I’m mistaken. I’d be happy to dig in to the code and submit a PR. Would this be helpful to anyone else besides me? Essentially, I want identifier creation to be idempotent from SignifyTS.
It shouldn't be idempotent, it should error on the second attempt to use the same name
yes, that’s right, it should error out. I was thinking “effectively idempotent,” though yes, it should error out.
This line from `identifiers.create()` I am thinking should error out on the second attempt:
let res = await this.client.fetch("/identifiers", "POST", jsondata)
*jsondata* has the name property, and all the rest:
var jsondata: any = {
            name: name,
...
Maybe I’m using SignifyTS wrong and just don’t realize it.
Though the client libraries could check for this, it definitely should be prevented in KERIA. I've created the following issue: but I do not have time to work in it right now.
It’s not a blocker for me since I can just avoid calling the same endpoint twice. Once I finish the initial wallet integration I may be able to get to this. I’ll put this on my internal task list.
Should a POST call to `identifiers.addEndRole()` similarly error out on the second identical call when it is the same role name (`agent` here) for the same identifier (`issuer` here) and same prefix (`client1!.agent!.pre` here) ? from SignifyTS:
await identifiers1.addEndRole("issuer", 'agent', client1!.agent!.pre)
Ends up making a `fetch()` call to:
let res = await this.client.fetch("/identifiers/" + name + "/endroles", "POST", jsondata)
Currently I’m seeing successive calls generate new `rpy` events with different digests. Is this to be expected?
*Successive calls with the same inputs
Yes, there is a timestamp in `rpy` messages to support BADA-RUN logic. New timestamp == new digest
rodolfo.miranda
I think I already corrected that issue here:
How is a nonce generated for registry creation? I see one here in `Credentials.tsx`: `AOLPzF1vRwMPo6tDfoxba1udvpu0jG_BCP_CI49rpMxK`
op1 = await client1.registries().create('issuer', 'vLEI', "AOLPzF1vRwMPo6tDfoxba1udvpu0jG_BCP_CI49rpMxK")
_Use the source, young Jedi_
def randomNonce():
    """ Generate a random ed25519 seed and encode as qb64

    Returns:
        str: qb64 encoded ed25519 random seed
    """
    preseed = pysodium.randombytes(pysodium.crypto_sign_SEEDBYTES)
    seedqb64 = Matter(raw=preseed, code=MtrDex.Ed25519_Seed).qb64
    return seedqb64
Haha, reading through it now. Thanks
Just saw the `vdr/eventing.py`
Looks like <@U03N48D5VD1> added a version to SignifyTS
export function randomNonce(): string {
    let seed = libsodium.randombytes_buf(libsodium.crypto_sign_SEEDBYTES);
    let seedqb64 = new Matter({ raw: seed, code: MtrDex.Ed25519_Seed });
    return seedqb64.qb64;
}
Thanks Arshdeep!
I was having an issue with OOBI resolution when running locally. I solved it though am posting my question here for anyone else who may run in to this issue. I’m assuming we will have a PRO plan one day so we can search all messages from the past (like Clojurians Slack in the Clojure community). It’s a tremendously valuable resource and has saved me tons of time.
Why would the following code in `aiding.py` show an empty `roleUrls` list when running KERIA through the PyCharm IDE versus running at the command line? When running in the IDE I use the following run config: Script: *keria/src/keria* Params: *start --config-file demo-witness-oobis.json --config-dir /Users/kbull/code/keri/wot/keripy/scripts* When running at the command line, from my KERIA repository root directory, I use the following command:
keria start --config-dir scripts --config-file demo-witness-oobis
And, of course, I use `kli witness demo` to run the witnesses and have cleaned out the KERI state with `rm -rfv ~/.keri && rm -rfv /usr/local/var/keri`

NOTE: I found my problem. It’s that the `demo-witness-oobis.json` in the KERIA repo contains the subsection for KERIA and the one in the KERIpy repo does not. Here’s the difference between the two files:
  "keria": {
    "dt": "2022-01-20T12:57:59.823350+00:00",
    "curls": [""]
  },
TLDR: I solved my issue, just posting for posterity.
For the repos `KERIA`, `signifypy` and `signify-ts` I created a new `development` branch that was cut from the current `main` branch and set it as the default branch for each repo. All PRs should be against `development` moving forward.
There were a couple of "visibility" changes and one rename (conflict after exporting everything) - I'm going to go ahead and merge the docs change and set up the githubpages, unless someone has a major ocncern. Speak now...
Ugh, my PR went in against main, so I'm trying to get dev up to date
github thinks main is out of sync now
Git is hard
avoids making inflammatory comment
petteri.stenius
Is there information about the /notifications API of keria? What notifications are implemented and what is planned? I'd like to understand what is required when orchestrating workflows involving multiple (human) participants, such as delegation, multi-sig etc.
The notification code from kiwiing was moved forward to KERIA as part of a general migration of functionality but with no real plan for its full implementation in KERIA. Best I can offer right now is "stay tuned" as we build out that feature.
rodolfo.miranda
At least, I tested notifications for `presentation/request`` and `/presentation` . See the integration test:
petteri.stenius
Thanks <@U03P53FCYB1>. I have seen that. In he old kiwi agent there was a number of useful notifications such as "/multisig/icp/init", "/multisig/icp/complete" and many others.
What is the purpose of the Contacts API in KERIA and Signify? Is it just for storing arbitrary data for a given AID an agent is aware of?
rodolfo.miranda
It's similar to contacts in keripy. You can store data of your contacts, the oobis, and if the have pass a challenge.
Got it. That’s helpful, thank you
Yes, assigning metadata to identifiers you are interacting with.
If you provide a `name=` query param to an OOBI before resolving it, that name will be assign in "contacts" to the resolved AID. And as <@U03P53FCYB1> mentioned, the challenge response handlers associate successful challenge responses to AIDs in contact data.
rodolfo.miranda
The name query param is a pro tip!!
Easter Egg?
Awesome, that’s really helpful, Thanks Phil. I also didn’t know the tidbit about the challenge response handlers associating successful challenge responses to AIDs in contact data. That saves me from having to put it there myself.
Even though it’s a POST `EndRoleCollectionEnd.on_post()` seems to only return data if it exists with `msg = hab.loadEndRole(cid=pre, role=role, eid=eid)`. Is that true? I am looking for a way to determine whether the ‘agent’ endpoint role has been created for a given controller and agent pair in Signify so I can avoid having to call `SignifyClient.makeEndRole`. It looks like I already don’t have to make that call since it seems that `hab.loadEndRole` only reads from the agent database so I assume creation of the agent in the first place added the agent endpoint role, effectively the result of calling `SignifyClient.makeEndRole`. Is that correct?
My goal is to ask an agent about its current state so I can avoid calling routes multiple times unnecessarily by looking at Agent state and deciding what has or has not been done.
Looks like someone added what I was looking for last week with the .
Looks like the nature of the endpoint changed to returning a long running operation in order to support multisig.
It looks like the `main` branch of KERIA depends on the `keri.app.querying` module that is currently only on the `development` branch of KERIpy. I’m getting an ImportError in KERIA on the name ‘querying’ when I use the main branch of KERIA and the main branch of KERIpy.
rodolfo.miranda
note that keria, signify (py and ts) have now the development branch as default. You should be pulling from there.
yes, i’ll pull from there, thanks.
I’m getting a KERIA 500 server error when my SignifyTS client makes a duplicate request to `/identifiers/{aid}/endroles` endpoint. Does this look familiar?
2023-08-16 18:22:21 [FALCON] [ERROR] POST /identifiers/dc_primary/endroles => Traceback (most recent call last):
  File "falcon/app.py", line 365, in falcon.app.App.__call__
  File "/Users/kbull/code/keri/wot/keria/src/keria/app/aiding.py", line 733, in on_post
    agent.hby.rvy.processReply(rserder, tsgs=[tsg])
  File "/Users/kbull/code/keri/wot/keripy/src/keri/core/routing.py", line 199, in processReply
    self.rtr.dispatch(serder=serder, saider=saider, cigars=cigars, tsgs=tsgs)
  File "/Users/kbull/code/keri/wot/keripy/src/keri/core/routing.py", line 84, in dispatch
    fn(serder=serder, saider=saider, route=r, cigars=cigars, tsgs=tsgs, **kwargs)
  File "/Users/kbull/code/keri/wot/keripy/src/keri/core/eventing.py", line 3551, in processReplyEndRole
    accepted = self.rvy.acceptReply(serder=serder, saider=saider, route=route,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/kbull/code/keri/wot/keripy/src/keri/core/routing.py", line 347, in acceptReply
    raise kering.ValidationError(f"Invalid reply from signer={spre}, no "
keri.kering.ValidationError: Invalid reply from signer=EFNtHlFG-SVN4cklD17ANPzPTBJPg-xaNeBHDxphmz5Z, no keys at signer's est. event sn=1.
What does `no keys at signer's est. event sn=1` mean? I’d like to be able to diagnose this myself.
What should the server return here instead of a 500?
I imagine a 400.
The signature on the endrole is invalid.
nuttawut.kongsuwan
I am curious if anyone has a plan for developing SignifyRust. (or perhaps SignifyOx?) Or will Signify capability be included in the KERIOX? Thanks!
rodolfo.miranda
I think this is the starting point:
nuttawut.kongsuwan
I see. I wasn’t aware of this repository.
I'd like to get to this at some point
nuttawut.kongsuwan
That would be awesome!
Does a credential issuance have to be accepted now before it will show up in an issuee’s credential list?
I noticed that on the latest development versions of KERIA and KERIpy issuance works differently than it did last week. Issuance is completing successfully for the issuer yet the credential is not yet showing up in the issuee’s credential list right away as it did last week. I assume this is due to what was discussed on today’s dev call where an issuee must accept a credential grant. Is that correct?
rodolfo.miranda
That is not implemented yet in keria. Also, due to some changes on the exn messages in latest PRs, I think that signify/keria is failing on processing some exn messages, for example on the presentations and challenge. We should wait for Phil to finish the development of this part to accommodate the code and retest.
ok, I’ll roll back my local repos and try again.
For a temporary workaround until the `exn` message work is finished here are the Git SHAs to check out for anyone needing credential issuance to work in the short term: keripy SHA: `9db4bcaf253d4e45a25cc15dd294f99d9aa7c741` keria sha: `5bf91c08d10058c237fe7ecc0e1585be7c3f2b5f` Then just do a local install and you’re good.
For some reason my long running op for creating an identifier is supposedly always returning `done: false` yet when I refresh my webpage and do a “get” on the identifier then it shows up as done. Anyone else had an issue like this?
Same thing happens on registry creation.
All in Kubernetes, of course.
Hmm, I’m also not seeing the typical logs you’d expect like `Sending TEL events to witnesses`
Are you polling until `done: True`?
They are (almost always) asynchronous operations, So you are required to poll on the operation until it indicates that it is complete.
yes, in every case
This problem seems to be related to how I’m running KERIA in Kubernetes. I was just able to get everything to work while running the witness only in K8s and running KERIA and the vLEI server locally. I must have something wrong in my KERIA K8s configuration. I’ll keep trying things. I’m sure it’s just something small.
Are the AIDs you are creating using witnesses? Are the witnesses returning receipts. When you see the AID in the `get` call, how many receipts are there?
If the events aren't receipted, they will never be "done". They will show up locally but show have zero receipts from witnesses.
Yes, the AIDs are using witnesses, and the witnesses are using receipts when KERIA is running outside of my K8s cluster (Docker Desktop).
Which GET call are you thinking of, the one for `/identifiers/<my_id>` or the long running op?
The former
A GET to `/identifiers/dc_primary` for the `dc_primary` identifier returns the following
{
    "name": "dc_primary",
    "prefix": "EOCoYugn-KTYdMbvpRTFFZLowzK1_CyJFOYuhN7ap3Fq",
    "salty": {
        "sxlt": "1AAHYY40ZAiTVZw5UEOjnrC2u47j5iWVHqezwItB3oHChlYgJ_EYWAF7zCQYj0ILRJi4rLceTNysfNB4yyQvf9DP2C3aozXvCZHl",
        "pidx": 0,
        "kidx": 0,
        "stem": "signify:aid",
        "tier": "low",
        "dcode": "E",
        "icodes": [
            "A"
        ],
        "ncodes": [
            "A"
        ],
        "transferable": true
    },
    "transferable": true,
    "state": {
        "vn": [
            1,
            0
        ],
        "i": "EOCoYugn-KTYdMbvpRTFFZLowzK1_CyJFOYuhN7ap3Fq",
        "s": "1",
        "p": "EOCoYugn-KTYdMbvpRTFFZLowzK1_CyJFOYuhN7ap3Fq",
        "d": "ELAIUJzdMs6VBAhV0vxaGhYw4IWJDmFOYaWpzzYp3-PD",
        "f": "1",
        "dt": "2023-09-04T23:36:59.415301+00:00",
        "et": "ixn",
        "kt": "1",
        "k": [
            "DPlGzbTVFzvMQfSeLRt9E39G2KabOOouvqZg56XmSblM"
        ],
        "nt": "1",
        "n": [
            "EGjoiaNo61i5sjuOAtGBB_Ojj9OSAG7rW3J0b5UpZTTQ"
        ],
        "bt": "1",
        "b": [
            "BHOcmjmmDVU0LiK94GB19sTUfh0flyELkEKUvWI9qxWe"
        ],
        "c": [],
        "ee": {
            "s": "0",
            "d": "EOCoYugn-KTYdMbvpRTFFZLowzK1_CyJFOYuhN7ap3Fq",
            "br": [],
            "ba": []
        },
        "di": ""
    },
    "windexes": []
}
This is after I refresh my webpage using SignifyTS which stops it from listening to the long running op. I suspect it’s as you said that the long running op never finishes.
You have a backer threshold of 1 and 0 windexes
That means that you have an unwitnessed event
ah
So my KERIA instance must not be communicating properly with my witness instance.
Thanks
Its so weird that it works just fine with KERIA outside of k8s and not inside k8s, even though the witness is in k8s.
When it works, are you using the witness inside of k8s?
yeah
Can anyone explain why this scripts first creates three client aids and then three multisig aids per client to then create another multisig aid that is controlled by all three clients? In other words, why don't we just use the client aids to identify the client keys that need to have control over the final multisig aid?
To simplify my question even more. Why does this log not say `Client1 joined multisig waiting for others ...`
Why did client 1 need to creat `multisig1`?
And only then create the final `multisig`
I am certain that this has something to do with signify architecture in particular because logically it makes not much sense but maybe `client1` creates `multisig1` before creating the final `multisig` because client1 has no wittnesses?
`client1` is the name of the SignifyClient varaible that creates a single sig participant AID named `multisig1` . `multisig1`, `multisig2` and `multisig3` are all SINGLE SIG participant aids in the only group created `multisig`
I understand that, however aren't `client1` `client2` and `client3` itself already single sig aids? I read this here:
So why the extra step of creating a participant aid if there is already a client aid established that could be used for the same purpose.
Here is what I mean with client aid. The `client.controller.pre`
No, that is not an AID
You are not understanding the architecture.
Just glancing over the comments on my phone, but the reason to create a new single sig aids for new contexts is how you protect yourself from correlatabilty . Joining a new multisig group? Create a new single sig for it. Why reuse and have a single point of correlation
Maybe, yes. However I think I just don't explain myself right. I read the `protocol.md` and there the first section explains that a client aid is created via the initial passcode.
<@U024KC347B4> yes that could be the answer!
The client in this case is an object created by the local Signify library that represents your connection to the agent. Behind the scenes, the connection is managed by a Controller AID and Agent AID. Those are not to be used (and aren't available to be used) for anything but signing requests between client and server. Once you create that client library object you then create AIDs that are to be used for all other purposes like credential issuance, credential presentation and yes, in this case, multisig group participation
Ah .. okay, i see. So the client aid is not represantive at all. It's just for internal communication.
Now I got it.
yes. And we verify it in these scripts because they are tests.
Normal use of the library wouldn't need to even reference it
I see. Okay. Sorry and thank you for explaining!
rodolfo.miranda
the "real" AIDs are called managed AIDs
The ones that the user shares with others.
Yes, okay.
That makes sense.
rodolfo.miranda
I'll be submitting a PR that will add coordinated interaction and rotation events to that multisig script
Thank you <@U03P53FCYB1> and <@U024KC347B4>!
<@U03P53FCYB1> I am reposting this here but I noticed something. <@U03P53FCYB1> this is a comment from you on slack: > Also, paths on the salty for the client AID are `signify:controller00` and `signify:controller10` and not `signify:controller01` I'll submit the correction You have not yet submitted a correction so I wanted to ask what is right. Is it right how it is in the protocol doc or is it right what you wrote on Slack?
I can't find the actual message anymore. It seems to be deleted.
We have limited slack history now
rodolfo.miranda
I don't remember, so I'll check the code again and correct if required to be 100% sure.
Also, maybe it makes sense to rename `multisi1` `multisig2` and `multisig3` if they are actually single sig aids.
Yes, could name them `member[1-3]` or something similar. That unfortunate naming is my fault from more than 2 years ago when I wrote the first mutlsig scripts in keripy
No worries and yes, member is a good idea!
rodolfo.miranda
Noted for the PR!
Additionally maybe it makes sense to clarify something in the docs. The multisig does not really consist of the member aids. On the kel level the multisig is just controlled by the same keys that also control the member aids.
That's been documented or discussed many times.
In meetings, recording and meeting notes
Also, if you think it could be better documented somewhere, instead of suggesting it to us I highly encourage you to submit a PR with working or documentation that you think would be better than what is already available. This is OSS, we welcome all PRs
Yeah, I know that. As someone that watches the recordings. But as someone just reading the most prominent docs it's hard to understand at first. But this is just my perception as someone new.
It would be a great way to learn, solidify your understanding
rodolfo.miranda
> that's on the code `let path = this.stem == ""?pidx.toString(16): this.stem + ridx.toString(16) + (kidx+idx).toString(16)` so ``signify:controller10` seems the correct for the next keys
Yeah but then the docs are wrong.
Darrell had this great description of OSS in one of the toip meetings today: 90, 9, 1. 90% lurkers, people who consume the content 9% are people to interact, comments, meetings, issues 1% who produce the content, code, whatever I’ve always considered folks in this community in the 9 and 1, but it does illustrate just how hard OSS can be sometimes and the commitment and level of effort the 9 and the 1 put in
First time I heard that, I thought it was neat
(And in no way a criticism of anyone, just a neat observation)
{
 "v": "KERI10JSON00012b_",
 "t": "icp",
 "d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
 "i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",  // Client AID
 "s": "0",
 "kt": "1",
 "k": [
  "DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc"  // Derived from passcode as salt, kidx = 0
 ],
 "nt": "1",
 "n": [
  "EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL"  // Derived from passcode as salt, kidx = 1, Blake3 Hashed
 ],
 "bt": "0",
 "b": [],
 "c": [],
 "a": []
}
This is an inception event from `protocol.md`. As you can see here it says the `kidx` of the rotation key is 1.
However if you look at the code for the signify controller, the passed `kidx` is 0.


`this.nsigner = creator.create(undefined, 1, MtrDex.Ed25519_Seed, true, 0, this.ridx + 1, 0, false).signers.pop()`
The example paths from the docs are `signify:controller00` for signing and `signify:controller01` for rotation. According to the code however the paths for the controller should look different because the `ridx` is 0 for signing and 1 for rotation and `kidx` is 0 for both. So `signify:controller00` and `signify:controller10`. This leads me to the assumption that not only the paths in the docs are not up to date but also the `kidx` comment in the mentioned inception event is not correct. Instead of `kidx` it should say `ridx`. Additionally it says the salty keys are generated using a composition of position in wallet and `kidx` but according to the code in signify-ts the `pidx` is no longer used.
Please open an issue. This is too much for Slack
Sorry. I don't even know if this is an issue or not.
<@U024CJMG22J> just one last quesiton. Am I correct that the `ridx` is the number of the next rotation event where an rotation key gets authority? If this is right, when you think about the example from `keri-dev` channel where not all next keys got used to rotated, `ridx` is an optional parameter because it cannot always be made clear when the key will be used in a rotation event.
0 	Crnt 	[A0, A1, A2] 	            [1/2, 1/2, 1/2]      
0 	Next 	[H(A3), H(A4), H(A5)] 	    1                      
1 	Crnt 	[A4, A6, A7, A8] 	        [0, 1/2, 1/2, 1/2]    
`A0` => `ridx = 0`
`A4` => `ridx = 1`

However `A5` => `ridx = undefined` because it is not used in the next rotation event neither do we know when this key gets authority.

In other words, in a multisig with different actors, specifying `ridx` is not possible if each actor can decide on their own, when they want to use their rotation keys and rotate (assuming a nt of 1 to simplify)
Here  for example the `ridx` is not specified, meaning the `ridx` is zero. Considering my assumption, this makes sense because there is no way to predict when this rotation key will get authority. Note: I think if the ridx is undefined you still use 0 for the path.
Where can I post this question so it can be discussed in the next keri call?
If it is a spec question then create an issue on one of the repos under trustoverip/tswg-* If it is an implementation question create an issue on one of the repos under weboftrust/* That way when (someone) creates the agenda they can include it.
We can update issues with the resolved spec changes or implementation details etc
or open PRs to fix docs/specs etc
Okay
Thanks!
I believe I found 2 bugs in `SaltyKeeper`. I will eventually create an issue. Context: Checkout how `.rotate` receives a parameter called `ncodes` to specify the number of new *signing and rotation* keys. After the rotation, we use the `.sign` function which signs with a parameter called `icodes`. (1) eventual bug: We always sign with `icodes` which itself is never changed. This is no problem as long as `icodes` and `ncodes` are the same but once someone changes `ncodes` in the rotation function it seems to be a problem because there is no line that says `this.icodes = ncodes` to specify the codes for the new signing keys in the rotate function. `.rotate`: `.sign`: (2.1) eventual bug: The rotate function of signify-ts does the following `this.ncodes = ncodes`. However in signifypy we don't seem do the same. I can't tell which of the implementations is right, it just seems like they differ in that case. `.rotate` (signify-ts): `.rotate` (signifypy): (2.2) eventual bug: As mentioned we do `this.ncodes = ncodes` in signify-ts, however I think this is at the wrong position because the public signing keys should be the previous next ones and not the new ones. At least, that's how signifypy manages it.