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
I would like to get these added to KERIA and Signify-TS as it's something my team needs. Happy to give it a try myself, perhaps apply -> offer -> agree for a normal AID to begin with (multisig, spurn later).
Understanding the existing impl:
I've taken a look at the existing grant and apply messages in KERIA. The messages are parsed, pushed onto the exchanging deck to be sent to recipients and then pushed to either the grants or admits deck in agent.ts. From what I understand: Granter will send the other necessary material such as registry events, and Admitter will parse the ACDC, issuance and anchoring events attached to the admit message.
Q: Admitter will actually first check to see if there's a grant listed (otherwise invalid) - in case the grant is missing, or there is an issue parsing the attachments (e.g. the ACDC itself) hasn't the admit message already been sent to other parties using exchanging in ipexing.py? Curious if we should should check the grant is listed before sending the message onwards.
New messages: apply and agree messages seem straight forward - do I need to do anything more other than sending the message to recipients in KERIA?
For offer I need a metadata ACDC, not sure if there's anything already available for this. Looking at the IPEX tests in keripy, it seems to just use a normal ACDC. Though it shouldn't be too hard to strip it down to a metadata ACDC and re-calculate the SAID.
The text was updated successfully, but these errors were encountered:
I would like to get these added to KERIA and Signify-TS as it's something my team needs. Happy to give it a try myself, perhaps
apply
->offer
->agree
for a normal AID to begin with (multisig,spurn
later).Understanding the existing impl:
I've taken a look at the existing
grant
andapply
messages in KERIA. The messages are parsed, pushed onto theexchanging
deck to be sent to recipients and then pushed to either thegrants
oradmits
deck inagent.ts
. From what I understand:Granter
will send the other necessary material such as registry events, andAdmitter
will parse the ACDC, issuance and anchoring events attached to the admit message.Q:
Admitter
will actually first check to see if there's a grant listed (otherwise invalid) - in case the grant is missing, or there is an issue parsing the attachments (e.g. the ACDC itself) hasn't the admit message already been sent to other parties usingexchanging
inipexing.py
? Curious if we should should check the grant is listed before sending the message onwards.New messages:
apply
andagree
messages seem straight forward - do I need to do anything more other than sending the message to recipients in KERIA?For
offer
I need a metadata ACDC, not sure if there's anything already available for this. Looking at the IPEX tests inkeripy
, it seems to just use a normal ACDC. Though it shouldn't be too hard to strip it down to a metadata ACDC and re-calculate the SAID.The text was updated successfully, but these errors were encountered: