The PR, #69, is merged with the main, but it doesn't seem to be available in production at https://didcomm.org/

Looks like some build errors for most.

On the pickup protocol v3.0

Why is the 'thid' only shown in the example for delivery (Message Delivery type)?
Does that mean that is the only place not optional?

Is not clear if messages-received message can exist without the 'thid' field.

Since the "message_id_list is a list of ids of each message received. The id of each message is present in the attachment descriptor of each attached message of a delivery message." and "The id is an opaque value, and the recipient should not infer anything from the value."

The recipient can not assume the 'id' is unique. The way that the protocols are described, the 'id' will only make sense in the reply.

IMO 'thid' should be optional on all message types of this protocol. Which means the execution of the protocol can start anywhere.
But for that, the recipient needs to assume the attachment's 'id' is unique to the mediator.

In the Delivery Request, we have:
If no messages are available to be sent, a status message MUST be sent immediately.

IMO we should just remove this line.
Why are we changing the behavior in this condition (assuming that by immediately you mean instead)
Sending a status doesn't bring any extra value.
For the recipient is the same have a status saying that you have zero messages or have a delivery with zero messages. But for the developer implementing a state machine is more complicated.

It would be useful to be able to query and disclose support for DID Methods using the Discover Features protocol. Where should this documentation go?

In the Aries world, I'd create an RFC describing the necessary things that would apply to the Discover Features protocol. Here on didcomm.org, we don't have a place for non-protocol documents.

So, where should this go? Should we update the Protocol definition to include this new type of feature and the details of expression? Should we add a way to include non-protocol documents? What's the right answer here?

Interoperability refers to the ability of different systems or software to work together seamlessly. In order to achieve interoperability, it is necessary to ensure that each system or software component is capable of communicating with the others in a standardized way. One of the most effective ways to achieve this standardization is through the use of a test suite.

A test suite is a collection of tests designed to ensure that a system or software component meets a set of requirements or specifications. These tests can be used to verify that the system or software component is capable of communicating with other systems or components in the expected way.

I want to create my own implementation of DIDComm v2. To be type-safe and idiomatic for functional programming in Scala.

• So I did an implementation
• I tested against all of the test vectors from the spec.
  Which was hard but really satisfying when I was able to read messages from other people not only my own messages.
• Then I found problems when I was reading messages from other JVM implementations of DidComm.
  Basically, the problem was that the Base64 encoding of the character '' was done in a legacy mode. My implementation did not support that at the time. It doesn't matter and I also don't expect the test Suite 2 to cover everything.
• Now I'm trying to have simple execution of the trust ping protocol with the roots-id/didcomm-mediator.
  I had to dig into the code of their dependencies to find what the problem seems to be. sicpa-dlab/didcomm-python#93

I'm assuming that they are not following the specification.
But the point is I shouldn't have to look at and understand the code of other implementations.
I should be able to test against a test suite.

How can we be talking about having interoperability between agents if we don't even test (or have a good way to test) interoperability at the DID Comm library level. Seems even a bit ironic.

Considering DID Comm specs a meta protocol this is even before starting to talk about the protocols. I don't know which libraries implement which version of DID Comm, what extensions they support, etc.

Don't take me wrong. I pretty much still believe in DID Comm.
Otherwise, I wouldn't have spent most of my free time from the last 12 months. Doing an implementation of DID Comm for Scala/ScalaJS. If I didn't believe how well ScalaJs fits the development of Dapp for web3 and how communication is a crucial part of it.

They are also other problems that need to be addressed:

• There is a clear lacking of tools to develop and debug agents. Which makes the creation and adoption of any advanced protocol almost impossible.
• There seems to be redundant data on the encrypted message and the content inside. (like field 'to' 'from' etc)
  • Which concerns me on the security level. Have the implementations the necessary checks?
  • Also concerns me about computer resources special because it is redundant. (On a simple message the 'to' and 'from' can easily count for three-quarters of the data...)
• At the current state of DIDComm specs and current protocols. I believe DID Comm wouldn't work if someone took down the DNS. Which defeats the whole point of being decentralized... Feel free to point me wrong.
• It's also crucial that Did Comm gains attraction before being obsolete. I mean creating stuff for the common user:
  • Chat apps
  • Simple games
  • Useful tools like https://www.random.org/ (How many have used this when giving prices at a conference? Anytime we need a random number this site is always used. How great would be to show a QRcode (OOB) on the screen that takes to a webpage capable of bootstrapping a DIDComm communication with everyone on the presentation, and then follow some protocol to randomize and decide on a winner? This would work for virtual conferences. The user would have the guarantee that the winner is really random, and not just another thing that I need to blindly trust if I want to participate.)
  • I don't understand why everyone is only looking into DIDComm to transfer verifiable credentials. yeah, that is a nice use case it can be sold to big entities and organizations. But this only wouldn't be enough to gain attraction IMO. Therefore would be obsolete before people start using it everywhere.

In summary, the need for a test suite is crucial to ensure interoperability between different systems or components by verifying their compliance with the same set of standards, protocols, and specifications.

The Problem: DIDComm V2 problem-reports REQUIRE a pthid value, even though that may not always be possible to include.

problem-report spec for reference

Section of note:

pthid - REQUIRED. The value is the thid of the thread in which the problem occurred. (Thus, the problem report begins a new child thread, of which the triggering context is the parent. The parent context can react immediately to the problem, or can suspend progress while troubleshooting occurs.)

Consider the following scenario:

In this scenario, since Bob cannot unpack Alice's message, he has no idea what that message's thid is. Therefore, any problem-report he constructs is out of spec.

This is just one scenario in which this issue occurs. The spec itself identifies the possibility of problem-reports being triggered by events other than receipt of problematic messages:

ack - OPTIONAL. It SHOULD be included if the problem in question was triggered directly by a preceding message. (Contrast problems arising from a timeout or a user deciding to cancel a transaction, which can arise independent of a preceding message. In such cases, ack MAY still be used, but there is no strong recommendation.)

In this case, it's not that the appropriate thid is inaccessible to Bob; it simply does not exist. As such, any problem report generated in this manner is automatically out of spec.

The links in the text below are not very obvious, and I think that should help. No visual change is needed for those links, but just the associate cursor change should work.

Hello World documentation for the DIDComm v2 book is outlined in the README

@dhh1128 gave us additional directions in the unsync as follows:

1. look at the IIW slides that was given by DSR in Oct 2021. The actual narration/video of their presentation might be (more) helpful....
   Here is a recording that goes along with the PPT and the demo code from DSR, that might be useful in Hello World.
   They walked people through sending and receiving a message. You could possibly link to their recording as an extra resource, and/or use the same workflow. One nice thing about it is that the libraries they used have the same interface in 3 or 4 different programming languages, so the Hello World writeup could be almost identical no matter which language a programmer likes.
2. Seed documentation from that demo and presentation that shows a sender in python and a receiver in java. https://github.com/sicpa-dlab/didcomm-demo/blob/main/didcomm-demo-python/didcomm_demo/didcomm_demo.py
3. Since they gave this preso, they finished the Rust work, and they have a wrapper for WASM and Swift, so JavaScript (browser, server-side) and iOS are now possible targets for the same demo.

example: https://didcomm.org/coordinate-mediation/2.0/mediate-request

It looks like the /book/v2 page is a 404. It might work to change the README.md to index.md but I'm not sure. Thoughts?

It was briefly mentioned on the call today by @dhh1128 that the expected principles to be followed by maintainers when accepting new protocols to the website would be to remain relatively permissive similar to a package manager for a programming language like crates.io or npm. This would mean that we'd probably need some other signalling mechanism in place to differentiate between protocols that are in heavy use versus new, unused, or in progress protocols. What would be some good methods measurable aspects that we should consider for this?

One idea that were mentioned on the call today was to have a self attested method for this. Is there anything better that may be worth considering?

In the shorten-url protocol there is an anchor link to https://didcomm.org/shorten-url/1.0/#goal-codes however there is no such section. There is no examples of shorten url goal_codes and I can't find it in any aries RFC either

The DIDComm Mediator-Coordinator protocol spec (possibly other specs) has examples that all have this long (emoji related) img tag in the middle of the DID. I'm assuming this is just a rendering error (it interprets the :key: portion of did:key:whatever as 🔑 and tries to render as an emoji but fails), but it would be great to fix this as it makes the examples quite a bit harder to read.

I don't know if anyone really wants to spend time tracking down and fixing this render error, but maybe we could just replace did:key: with did:example: wherever it's found to avoid the error?

I want to create a protocol for someone to send a request saying, "what credential types do you have available to issue?" and then an issuer will respond with the credential types they offer. I am only in the conception stage and am gathering prior art. Is there anything like this in an Aries RFC @swcurran or do you know of anything @dhh1128? I am imaging it will be using DIF Credential Manifest like in the use cases

See https://didcomm.org/basicmessage/1.0/

This loads, and is then cleared by an error page. This is the first protocol we list with multiple versions, if that makes a difference.

The current link from #27 points to hyperledger. It's a long post which is fine but we should talk about building a protocol within the didcomm.org domain

In current spec, Recipient DIDDoc for Test Vectors does mention https://www.w3.org/ns/did/v2 in its @context field. However, this URL returns 404.

And also, even if I don't see any mention to it in the spec, DIDComm V2 context supposed to be found at https://didcomm.org/messaging/contexts/v2 is also not found. Maybe should be moved to site/content directory?

I have made this outline to the question I initially created with the answer from Daniel included, just washed in the form of we the didcomm.org group.

Have a look and comment

https://docs.google.com/document/d/1lwLuuDaaQqlS0L4LgnkwhcelH6wdUr8Sp4NbQgDvhJQ/edit

Also, let me know where can I now enter this text as a PR? Its not clear to me

On the Mediator Coordinator Protocol after a Mediate Request -> Mediate Grant

Should the DID requestion assume that the mediator will receive Forward Messages to him? Or needs a recipient-update and add himself again before being able to receive any Forward Message?

Yesterday there were some merges but apparently they weren't published due to a CI error. Log states:

/usr/bin/git push -f https://***@github.com/decentralized-identity/didcomm.org.git master:gh-pages
fatal: could not read Password for 'https://***@github.com': No such device or address
Error: The process '/usr/bin/git' failed with exit code 128

Assumption

I'm assuming that there should be some correspondence between the published https://didcomm.org/ URL Paths and the URI defined within.

Current Behavior

Examples (not attempt to be exhaustive):

Expected Behavior

It looks like the context document has been created already, but I can't find the public URL that it's available at so we can publish this URL in the did spec registries. This is an issue to track fixing that.

When opening a protocol uri with the message type in your browser a 404 error is shown.

This means when you want to view the documentation for the message message in the basicmessage protocol you need to go to the following url:

# this does work
https://didcomm.org/basicmessage/2.0

instead of the following url

# this doesn't work
https://didcomm.org/basicmessage/2.0/message

This link is currently in the top right, but links to this github repo. I think it would work better on an 'about didcomm.org' page.

https://w3c.github.io/did-spec-registries/#didcommmessaging

This is caused by gh-pages branch not containing /messaging/contexts/v2/index.json cc @awoie