2024-11-19 Indy Contributors Call

Owned by Char Howland
Last updated: Nov 19, 2024 by Stephen Curran
2 min read

Summary

Zoom: https://zoom.us/j/93198495358?pwd=TS80VklHVElJS3lEcjUzQjV0VHVtUT09

Recording:



antitrust-policy-notice.png

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


Attendees

  • Char Howland (Indicio PBC) <char@indicio.tech>
  • Daniel Bluhm (Indicio PBC) <daniel@indicio.tech>
  • Kim Ebert (Indicio PBC) <kim@indicio.tech>
  • Wade Barnes (BC Gov / Neoteric Technologies Inc.) <wade@neoterictech.ca>


Related Calls and Announcements

  • Sovrin Foundation is preparing for the likely ending of operations of its MainNet ledger on March 31, 2025

Release Status and Work Updates

Meeting Topics

  • Discussion about the state of Indy
    • Indy Quarterly Report: https://github.com/LF-Decentralized-Trust/governance/pull/68
    • Indicio can put resources towards PR reviews
    • Quebec Team also expressed interest in contributing resources
    • Stephen will bring to the TAC the recommendation that Indy should not be placed in a dormant state
      • We will engage with those who are running Indy networks but are not involved in the community to see if they would like to get involved and potentially contribute resources
  • Updates
  • Open Discussion

Next Meeting

  • Presentation on Indy Read Replica Project from Hyperledger Mentorship Program mentee Bryan Elee


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...

Action items