0.6 Release #1861

That seems to be very useful! I think that removing didcomm from core (and making any protocol such as basic-messages, proofs, etc, a separate module) can help, but of course it does not add granularity in terms of messages. Maybe this could be a protocol module-specific setting? (e.g. in didcomm-credentials module we use a config parameter to determine the roles we want to support.

Another somehow related thing is about selective feature disclosure based on each connection setting: e.g. suppose I don't want to support basic-messages for a certain connection, so I don't return this feature when they ask me for it. This would be good to be done in a way that we also reject any incoming message for a given connection if we don't support it, but I imagine it can be complex to handle.

Nice! Lots of good stuff, we can think on prioritizing them and also classify them in terms of complexity

The middleware concept, already mentioned in the early days of AFJ, is something I would like to revisit, since it can be useful for things like this and many others. For instance we can easily hook into it to add some specific metadata to both inbound and outbound messages (e.g. creation date or a flow_id or any custom field we want depending on our specific needs), and also we can use to prevent duplicated messages (by inspecting message id and returning in such a way that agent will stop processing).

Finally, this has been addressed in #1896 and part of 0.5.5 release.

I agree. I'll submit the PR for #2262 today, so if you're able to push #2466 will be great. Also we have #1819 which can be merged alongisde these.

For the rest of the outstanding work, we can leave for a 0.6.1 (e.g. W3C revocation status list) or a 0.7.0 that hopefully will not take so long as usual.

With push I was actually meaning to not include them. If we skip #1819, we won't have any breaking storage changes and thus we also don't need #2466 in this release (but can include it in next release).

This may make the already very large 0.6 release only breaking in code, not breaking in storage.

But now I'm thinking whether #2262 will require a migration, and we will need #2466 anyway?

Sorry, after I wrote my message I was suddenly starting to feel sick and was out 🤒 . But I think you have a good point that feels safer to do this big release without any storage changes, especially considering that these PRs are not so critical right now.

For #2262 I think the most annoying part is on the issuer, since usually we don't want to keep the Credential Exchange record to prevent PII to be stored permanently. So I took the branch I was working on, and just left the API changes on sendRevocationNotification to accept a connectionId instead the credentialExchangeRecordId. Holder still needs to keep the Credential Exchange to process notifications, but since the PII is already on the credential record, it wouldn't be that bad. I think this can be enough for now. The PR is at #2525

Hope you feel better now!

The PR is now merged, so I think we're ready to see the latest alpha release as a "release candidate" for 0.6.x.

We have already updated our wallet to almost the most recent versions of Credo, and we're currently updating the Paradym platform as well, to ensure everything works as intended and the APIs/exports are correct. Since we now use package.json exports, we can' import from subpaths, and we've also noticed some issues with ESM, so we'll check if these are working correctly.

We'll do the same with Hologram app and our backends this week. Let's see if there is anything unexpected.

I'll see if i can get it added over the weekend. It seems the release is non-breaking, so it won't be an issue if we don't get it in for 0.6.0

Yes -- non-breaking. A Rust update and some internal tweaks -- nothing changes with the API.

This has been resolved!