This meeting uses UnSync conventions and takes place on our Discord channel; transcript of actual meeting chat published here. [ charter | meeting archive | schedule ]
Nothing fancy needed; just a wave. This helps us tell whether we have a quorum, interpret silence, hold people accountable, and know who we're collaborating with.
Have a look at this URL: https://didcomm.org/book/v2/. Click the "Why" link. Then click the link immediately underneath it, "Choosing libraries and tools." Notice that the first goes to a web page; the second goes to raw markdown.
I believe we need to be removing the .md extension from all our links in the book to avoid this problem. However, is there someone in our group with more Gatsby knowledge that can tell us if there's a better way?
We have two open PRs from Rodolfo (THANK YOU!). Please have a look and leave comments.
Rodolfo pointed out in our last meeting that "Web5" was getting a lot of buzz because Jack Dorsey started talking about it. It's exciting to have such a high-profile spokesperson for stuff we've all worked on. However, he's touting did:ion and decentralized web nodes (a successor to DIF's "hubs" idea) -- and hubs are being positioned as a direct competitor to DIDComm. What should we do about this, if anything?
I (Daniel H) was doing an analysis this week of how verbose some DIDComm v2 messages are, and one of the recurring patterns I saw was that we may repeat fairly long DID strings multiple times -- e.g., once to refer to a DID, and then again to refer to a key or endpoint inside that DID's DID doc. I'm wondering if it would be worth establishing a convention inside a given DIDComm message (not necessarily elsewhere), that multiple references to the same DID can take advantage of a convention to shorten. Specifically, perhaps something like, first mention of a DID:
did:method:a_very_very_long_string_with_lots_of_entropy_in_it`
And then, later, another reference to it:
did:~it
...meaning: reference to a DID value already seen, ending in "it".
When DID values are quite long (as is the case for did:peer numalgo 2, and also for did:ion and some other interesting types), the clipped reference saves a lot of repetition...
Of course, this is a form of compression, and one argument against doing this is that general compression will be almost as good and is far more broadly useful.
Another argument against doing this is that it makes individual fields of a DIDComm message no longer self-contained. And if a DIDComm message is large and gets streamed, and serialization doesn't happen in order, you could see a reference before you see a full form.
So I'm not necessarily in love with this idea. But I've been doing DIDComm over NFC, and the bandwidth of NFS is so, so low (about 1-1.5 kb/sec); it is really bothering me that we are wasting hundreds of bytes being so verbose. So that's what motivated me to ask the question, at least.
Proposed closure: discuss on chat and revisit in two weeks, when our thinking may be mature enough to vote.
At this week's DIDComm WG, @Telegramsam described a mechanism that allows agents to sync on complex, long-running, multiparty interactions in the way that we'd need to build a competitor to Slack/Discord/WhatsApp/WeChat/Signal on DIDComm. This supersedes the work I did a while back on GOSSYP. I think it would be worth resharing here. @Telegramsam, can you share a link to the recording of that meeting, and a time offset? And/or, can you share a link to the HackMD doc that contains your idea, so we can engage on it?
Did you think this meeting was effective? How could we improve?
Proposed closure: Please leave your ideas in chat.