Summary
Excerpt |
---|
|
Zoom: https://zoom-lfx.platform.linuxfoundation.org/meeting/97572546272?password=5da46f0a-57dc-4de9-8831-708ba60d97ae
Recording:
LF Decentralized Trust is committed to creating a safe and welcoming community for all. For more information please visit the LFDT Code of Conduct. |
---|
Welcome and Introductions
...
- Char Howland (Indicio PBC) <char@indicio.tech>
- Renata Toktar (DSR Corporation) <renata.toktar@dsr-corporation.com>
Related Calls and Announcements
...
- Coordinating Ubuntu-22.04 release
- To Do: define initial tasks on Jan 14th call, then assign
- Get set up on Tatsu: https://tatsu.io/
- To Do
- Update the workflows to support Ubuntu 22.04: https://github.com/hyperledger/indy-node/
- Kim did Indy Plenum updates, Wade fixed the pipelines, next step was Indy Node release
- Kim integrated the updated release for plenum + other pipeline changes
- Next step is to fix the pipelines again
- Do a pass, get it up and running
- Determine next steps from there
- Indy test automation is integrated into the pipeline
- To Do: Update containers that the tests are being run on
- Currently uses whatever package the Indy build uses
- Create tickets for work items
- Fix issues on the ubuntu-22.04 branch, then merge to main
- Tools for coordination/regular updates
- Tatsu: based on Slack https://tatsu.io/
- Stephen will invite folks to Tatsu
- To Do: define initial tasks on Jan 14th call, then assign
- First thing: Enable the 22.04 branch in the workflows (only enabled on main currently)
- Change FROM line on Dockerfiles to ubuntu-22.04 (including indy automation, needs a ubuntu-22.04 branch too)
- Indy test automation issue: https://github.com/hyperledger/indy-test-automation/issues/153
- Action items
- Adam to take the deletion tasks (first two tasks in the issue)
- Stephen to create Slack channel and check with Quebec folks
- Indy Annual Report
- Due Jan 30th
- Template: https://github.com/tkuhrt/lfdt-governance/blob/20250116/tac/project-updates/0000-annual-review-template.md
- Renata to add Indy Besu progress to annual report
Adam or Stephen to complete OpenSSF Scorecard action - coordinate over slack
- Lynn to complete report by end of this week, final review on Jan 28
- GitHub Organization
- Potential requirement to move repos from Hyperledger to Hyperledger-Indy
- Impacts links, docs, GHA
- Little value from branding perspective
- Updates
Presentation on Indy Read Replica Project from Hyperledger Mentorship Program mentee Bryan Elee- Indy Besu updates and discussion
- Deploy with Kubernetes and AWS
- Finish before the end of the year
- Try Indy Besu not only locally, but deployedTest migration from existing indy network to BesuArticle: https://www.lfdecentralizedtrust.org/blog/lf-decentralized-trusts-hyperledger-indy-on-besu-joins-the-didindy-method-six-months-of-progress
- Indy on Besu in-person event in Lisbon
- Revocation - finalized technical review, processing review comments. Will be merged soon
- IaC - PR in review, DSR used for a cloud deployment
- DID Web VH
- 0v0.5 almost readyis finalized
- Updates on pre-rotation and witnesses
- Will evolve into 1.0
- Name change
- Resolver into Credo
- Resolver and registrar into ACA-Py
- Deployed did:webvh server, hosting dids there (still tdw or web)
- Talking to Bluesky
- Most controversial: portability
- Not helpful for Bluesky
- Indy Besu updates and discussion
Next Meeting
- Working on AnonCreds method update
- DID Web VH server to receive and post those files
- Updates to ACA-Py and Credo
- Open Discussion
Future Calls
- GDPR and the right to be forgotten – mitigations and approaches.
- The Indy "Corporate Firewall Problem" and the idea of a Proxy Server on Nodes? Kim Ebert
- Core issue: A mobile wallet user using a Corporate WiFi may find that they can't get to an Indy ledger because all but 80/443 ports and HTTP/S protocols are blocked
- Discussion/Options paper: https://hackmd.io/@n5FW6jwuRfCgchBDNWR3VQ/H1kNlKpmo
- Question: Is it viable to have each Indy Node also listen on port 80/443 for HTTP/S requests and arrange to have them processed?
- Option: Receive on HTTP(S) and send on to local ZMQ instance as if coming from outside.
- Answer: We think it is probably not viable, as mobile agents require HTTPS. As such, each Steward would have to get a IP-based SSL Certificate. Technically doable, but getting everyone through that is really not practical. The cost of the certificates and maintaining them would be ugly.
- Option: Add a DIDComm agent to every node, and use DIDComm to send the messages
- Similar to using HTTP(S), but use a DIDComm message. Since Mobile Agents would be using a mediator, the DIDComm message would flow through that, and the HTTPS issue would not matter. This is almost easy, but... There is no encryption public key in the genesis file, so that needs to be retrieved from somewhere else...
...