Page Comparison

Summary:

...

Recordings From the Call:    

Widget Connector
url http://youtube.com/watch?v=7QLkEA9sW3Q

Welcome, Introductions and Announcements

...

• New maintainers – Thiago and Mourits - #3239
• Dealing with artifacts and naming:
  • Any flashes of inspiration on the name? "acapy"
  • Need an immediate update to the README to begin to announce the move and process.
  • Create a "move2owf.md" file that we will maintain with guidance about the move.
  • Repo name will be "acapy", associate repos would be "acapy-..." as in "acapy-plugins" and so on.
  • What do we rename "aries_cloudagent" to?  Suggestion is "acapy_cloudagent"? Leave it the same?-agent".
  • Create PR to change "things", then move to OWF, create a fork at the old location (see below) then merge the PR, then clean up.
  • Can we keep publishing to PyPi "aries_cloudagent" after we make such a change?  Can we use an alternate name for a PyPi package?
    • PyPi – leave deprecation messages – warning.
    • One more release from Hyperledger with the deprecation notice.
    • Then an immediate release from OpenWallet Foundation with a new package name of "acapy-agent".
  • Assuming we can get permissions, can we keep publishing to GHCR – e.g.ghcr.io/hyperledger/aries-cloudagent-python:py3.12-1.0.0
    • Should For LTS – we will keep publishing to this GHCR
    • Move the repo, create a fork of ACA-Py at it's current https://github.com/hyperledger/aries-cloudagent-python  location with an updated README so we can keep the GHCR?fork using the old name, update the README to send the users to the new repo, and continue to publish PyPi and GHCR releases from the fork – which will never be merged. 
      • No new issues on the fork. 
  • Documentation – what file should we create?  Just put it at the top of the README in screaming letters?
    • Document that details the change – published on https://aca-py.org 
    • Discord
    • Aries Mailing List
  • Any concerns about the plugins?
    • Redirect should take care of a lot of this – we hope.
    • Worst case documentation, and people will have to update their deployments.
  • Any other concrete things we can do?
  • Timing:
    • Should we update the documents across the board first or move the repo first?First thing is a README update and announcements.
    • Next is a final Hyperledger Aries release.
    • PRs to prepare changes
    • Move.
• PRs and Issues –
  • #3184 (connection protocol – and next version number and how to document
  ?),
  • ?)
    • Immediate release of what we have as 1.0.1 – with a deprecation notice.
      • Could be last Hyperledger release.
    • Merge the connection protocol PR
    • Remove Issue Credential / Present Proof v1.0 and put them into a plugin (or not?)
      • Indicio to remove and create a plugin
      • BC Gov to test the plugin and tweak.
    • All three will go into the subsequent release – 1.1.0 either from Hyperledger or OWF as we decide.
  • #3246 (multikey management)
    • Try to finish off, review again and merge today and include in 1.0.1.
    • #3181 – creates two routes to add a proof to a JSON document.
  • #3243 (in-memory wallet)
  , 
• Any thoughts on #3240 – extending the --seed  to include what DID method to use with the seed?
  • Conceptually – a wallet import to create the right private keys in ACA-Py to enable appropriate signing.  Know the keypair/DID in advance, but want to use it in ACA-Py.
• Progress on other initiatives:
  • OpenID4VCs plugin - Indicio team focus
  • Other?
• Open Discussion
  • Urgent request to complete did:indy support (e.g., JSON-LD VCs based on did:indy DIDs) – triggering learnings about DID handling.  Daniel Bluhm to assemble those learnings and share as work proceeds.

...