Open mixmix opened 1 year ago
update .... we're working on this now with a grant! First step is "Holder initiated connections"
@mixmix , so should this issue be assigned to you?
@mkbreuningIOHK what does "assigned" mean in your org context? In orgs I've been in it means "is going to take this work on". It's unclear what sort of Open Source project this is at the moment - is Identus collaborating with outsiders, welcoming PRs, contributions to direction setting? If yes then those things would need resourcing - people and time on Identus side to weave others work in (I've been on the other side where we have under-resourced this and it's a bad time)
cc @elribonazo here is an example of me asking for more power at the "edge" (shift towards fully p2p agents)
Getting back to this to make some real progress.
On our most recent improvements we've included SDK to SDK verification through DIDS and didcomm. Also have integrated ConnectionLess flows.
Let's re-open this thread and try to make some progress. We still need to make Connectionless flows re-usable thats last thing i can think of right @mixmix ?
Yes! @chereseeriepa and I have been working on getting the new SDK woven into Ahau. We have integrations tests passing, and it's beautiful! Next up from us:
Proposed feature
For our use-case in Ahau, we want presentations to be part of our Tribe Registration process. We have secure end-points (public keys you can encrypt messages to) where it is safe to send messages to Kaitiaki (custodians/ guardians/ admins of a Tribe).
Here:
At the moment we have an slightly annoying workflow which goes:
Each of those steps could have significant delays. The applicant may be applying from their phone/ laptop, and the kaitiaki is maybe reviewing applications from their laptop. They are not assumed to be both online at the same time, so each asynchronous step could make significant hold-up for a process
Feature description
The steps we would prefer:
Anything else?
NOTE: we use scuttlebutt messages to communicate state-progression (which initiates actions) between the applicant (a Holder using the SDK) and the kaitiaki (Verifier, using a hosted Agent via https APIs)