Date   
follow-up on populating http://didcomm.org

Daniel Hardman
 

I sent an email to this group a while back where I was discussing how to link PIURIs in DIDComm (the special URIs used to identify protocols and message types) with a URL namespace under http://didcomm.org. I suggested that we needed some sort of CI/CD pipeline at the Hyperledger Aries project that could feed content to this webserver.

Apparently this gave the wrong impression.

Aries isn't the only source for application-level protocols built atop DIDComm; whatever we do for Aries should also be available to anybody else who begins producing high-quality content about protocols. Indeed, a measure of success for both HL and DIF is that other communities emerge and begin doing just that. Thus, I envision that http://didcomm.org ends up containing lots of cool content from lots of places, all hosted by DIF. However, in the near term, Aries is the only source of such material that I know about, so all of my worry for the time being was how to make content publication work with source=Aries.

I hope that alleviates possible concerns that Daniel H is trying to prejudice didcomm toward Aries.

initial-state and length of identifiers

Daniel Hardman
 

Today we discussed whether we can use an initial-state matrix parameter on DIDs to pass info in a DIDComm message in the JSON field where a recipient is identified (where a simple DID would sometimes go). One of the concerns I raised was that we might change the length of these fields, from ~100-ish characters to maybe several KB. The consensus on the call was that this wasn't necessarily problematic.

However, I was reading the OIDC spec soon after we spoke, and reviewing the fields in the id token that it sends to authenticate someone. This is what it says about one of its required fields (see section 2 in https://openid.net/specs/openid-connect-core-1_0-final.html):

sub
REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.

In other words, the longest identifier we can use in OIDC identity tokens is 255 characters.

This does not necessarily mean our discussion was wrong. It's not clear that the DID+matrix-parameters values we want to pass in DIDComm should flow directly into OIDC id tokens. However, I think it's a useful cautionary note; there are definitely specs in the identity space, that we might want to interoperate with, that impose limits we should be aware of. I'm not sure a huge initial-state value is super smart.

Re: meeting today

margalit.lior@...
 

Oops, missed to notice the daylight savings change.
Thanks

Re: meeting today

Daniel Hardman
 

Yes, but it shifted due to daylight savings changes over the weekend in the US.


On Mon, Mar 9, 2020 at 2:10 PM <margalit.lior@...> wrote:
Is there a meeting today?

meeting today

margalit.lior@...
 

Is there a meeting today?

PR in for Routing - Meeting Discussion Topic

Sam Curren
 

Daniel Hardman has submitted our first content PR related to Routing. Here is the link to read the PR content:

https://github.com/decentralized-identity/didcomm-messaging/blob/f642db1a09c79ba5db01b84bdad44ca143806e56/routing.md 

We'll be discussing this during the meeting. It is long, but even reading part of it will help the discussion.

Thanks!, -Sam

Re: DID-TLS

Daniel Hardman
 

That's an excellent question.

My opinion is that DIDComm TLS should be part of *a* spec produced by this WG, but I think it would be a different spec than the one about DIDComm Messaging that's currently getting our energy. The reason is that DIDComm Messaging attempts to put security with the message, whereas DIDComm TLS would put the security in the transport.

Do others agree?

DID-TLS

margalit.lior@...
 

Hi,

I am looking into the transports section of the spec.

For the case of transmitting the message using TLS based protocols, is the definition of DID-TLS part of this spec?

Kyle's notes from previous outreach to other groups doing secure messaging

Daniel Hardman
 

As discussed on today's call...

Homework for next Monday: Spec Outline

Sam Curren
 

Daniel Hardman has written up a suggested outline, and we'll be discussing that on  Monday's call. Please read it prior to the call:


Note that we don't have to 'approve' this or get it perfect. Getting started with some sections allow contributions to the doc by section, which can help us get started faster.

Thanks. -Sam 

Re: Repo Name

Tobias Looker
 

I won't die on this hill, but given we are currently calling DID Messaging, DIDComm, I'm predicting our tendency is going to be to continue with that :) which will make clarification of what DIDComm means as an umbrella term harder in future. The term DIDComm-TLS (decentralized identifier communication transport layer security) sounds muddled to me, I like DID-TLS a bit better. Is the implication of `DIDComm messaging` setting a convention that all children of the DIDComm WG or communication technologies that use dids must inherit the DIDComm prefix?

+1 to a tightly scoped repo using tags to link it to the working group.

Thanks,
Mattr website 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@...
Mattr websiteMattr on LinkedInMattr on TwitterMattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Fri, Jan 17, 2020 at 6:01 AM Stephen Curran <swcurran@...> wrote:
+1 to both of Sam's notes from me.  For sure on the DIDComm, and starting with a single repo for now and we can evolve if it becomes obvious that was a bad choice.

On Thu, Jan 16, 2020 at 7:03 AM Sam Curren <telegramsam@...> wrote:
On including the -comm suffix: I ack the worry, but I think we can manage it by preferring it always, such as DIDComm-TLS or DIDComm Multicast. Calling it DIDComm also cleanly differentiates it from DID work while maintaining the desired association. 

On monorepos:
 
Most of the benefits listed for monorepos are applicable to Very Large Projects, which will not apply well to our work. The primary benefit the seems to apply best is coordinated updates between the spec (usually in the form of clarifications) and the reference codebase. 

Also worth considering is the needs of future work (DIDComm Streaming, etc.) in terms of shared code (between streaming and messaging) and workflow needs and degree of overlap between involved parties.

For the sake of expediency, I think we should draw the line between those projects, and focus on the needs of DIDComm Messaging. I propose a repo called didcomm-messaging where we begin the spec work. We can decide in later discussions if that will also include the ref code or not.


On Wed, Jan 15, 2020 at 5:58 PM Tobias Looker <tobias.looker@...> wrote:
Hi,

The rationale for potentially dropping the comm part and calling it DID messaging, mainly came from the thought of what we as a working group will tend to shorten the name of this work to? If it is DID Comm messaging, won't the tendency be to shorten it to DIDComm? In that case when we do want to build DID-TLS or DID multicast the relationship to the umbrella term of DIDComm may get lost?

The language I was thinking is:

"DIDComm refers to a related set of technologies with a common aim of developing robust communication protocols using decentralized identifiers. The DIF DIDComm WG is where this effort is concentrated and the immediate focus of the WG is around furthering the development of a messaging based protocol called DID Messaging"

Thanks,
Mattr website 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@...
Mattr websiteMattr on LinkedInMattr on TwitterMattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Jan 16, 2020 at 12:02 PM orie <orie@...> wrote:
I'd love to see something like https://tools.ietf.org/html/rfc7520 for DIDComm Messaging.

I agree with Daniel regarding the potential complexity of didcomm (as an umbrella concept).

Not every project that uses monorepo structure has a well defined spec associated with it, here are some popular javascript frameworks that use the mono repo pattern:

https://github.com/babel/babel
https://github.com/facebook/react
https://github.com/angular/angular
https://github.com/trufflesuite/truffle

These all use lerna, which I am the most familiar with... There is also: 

https://github.com/korfuri/awesome-monorepo

Which talks a bit more about CI/CD, Code Ownership, etc...

When I start a new project, I try and avoid upfront modularization until I have a clear understanding how things relate. I'm a huge fan of microservices and reusable modules and components, but I think it's best to start with a monolith and refactor to a modular architecture once you find yourself feeling the pain of DRY, KISS, insert your favorite development paradigm... over architecting upfront can paint you into a corner where your modules start driving your thinking instead of the business objectives, and it's easy to put something aside if there is a place to put it. 

Regarding which reference implementation type do we want for didcomm, since didcomm appears to be built on JOSE, and I'm an obvious javascript fanboy, I would love to see a TypeScript  reference implementation. 

I think having a type system will help us a lot in terms of explaining interfaces, but because javascript is not very performant, I think this leaves room for a RUST or GO or WASM binary to be a clearly superior production version.

Whatever approach we decide for the reference implementation, it really should have 100% test coverage. Its an instant confidence killer to see that a reference implementation has poor coverage, and it's a good sign that it's gonna be close to useless for implementers.

I very often will implement something written in one language, in another, by simply recreating their unit and integration tests... this makes making a new version of the software very easy to tackle in small chunks, and you have confidence that you are compliant w.r.t. the reference implementation as you go.


DIF is geared towards hosting code and specs. I think we have an opportunity to set the "Gold Standard" for how DIF manages a complex software and spec project that is IPR protected, and easy to contribute to, but we will have to have the appetite for such a commitment, and I'm not sure if there is enough of an interest for member companies to support this approach for didcomm.

As Daniel noted, the complex the reference implementation will come at the cost of more friction. It will take more effort to keep the spec and reference implementation aligned, I'm not sure we have the engineering resources or member company commitment to do so.

These are all just suggestions, I'm not attached to a particular outcome.

OS



On Wed, Jan 15, 2020 at 3:08 PM Daniel Hardman <daniel.hardman@...> wrote:
Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am not making a claim about what's possible; it's possible to do all kinds of things with automation + human conventions, including making a release span multiple repos, or making a repo hold things that don't release together. This is an assertion about which tradeoffs are optimal because they generate the net least amount of friction, overall, over the lifetime of a rich project. (When FB offers a monorepo for react, it is because they're trying to provide a one-stop-shop to all developers who want react; the needs of the many [external devs] outweigh the needs of the few [maintainers], so monorepo friction is a cost worth paying. That might be right for them, but I don't think this WG is trying to produce a one-stop-shop for all things DIDComm. I thought the charter was about writing specs--not sample code, non-reference impls, demos, etc. Am I wrong?)

My assertion is debatable, of course. I don't have any proof of it other than my own experience. But if there is intense disagreement, I'd rather just shrug my shoulders and go silent. I don't think the stakes are so high that we have to be perfectly optimal, and I've said my piece now... :-)

But if you think my assertion is reasonable, the follow-on question is: What do we want to "release together"?

I'm pretty confident that different specs don't release together. They have entirely different lifecycles and maturities, and entirely different bug tracking, maintainers, etc. This argues for a different repo for each spec.

I am ambivalent about whether a spec and a reference impl should release together--and I think it's because Orie and I may have very different ideas about what a reference impl entails.

The unicode spec includes a reference impl of UTF-8 encoding. IIRC, it's about 35 lines of C code. A snippet of just the procedure for building an encrypted envelope might be analogous in DIDComm. Putting this type of stuff in with a spec feels great to me. I'm 100% in favor. You can even write unit tests that guarantees that the code stays in sync with the descriptive text.

But DIDComm is way, way more complex than UTF-8 encoding. If we're expecting a reference impl to exhibit all possible DIDComm features--routing through arbitrary layers of relays and mediators, multiplex encryption, support for multiple key types and multiple DID methods, message trust contexts, return route optimization, message timing, recovery from lost and out-of-order messages, asymmetric channels--we're talking about many thousands of lines of code, with subdirectories and project structure all of its own. It would have an elaborate build and test procedure of its own, very dissimilar from the procedures used by specs. Its maintainers would be different, and so would its code review process. If that's the kind of reference impl we're talking about, I'm far less comfortable keeping it with a spec, because it could create enough friction to slow down the spec.

So which ref impl type do we imagine?

On Wed, Jan 15, 2020 at 1:08 PM John Jordan <john.jordan@...> wrote:
+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global>   [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [Mattr on Twitter] <https://twitter.com/mattrglobal>    [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.







--
ORIE STEELE
Chief Technical Officer
www.transmute.industries



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Re: Repo Name

Stephen Curran
 

+1 to both of Sam's notes from me.  For sure on the DIDComm, and starting with a single repo for now and we can evolve if it becomes obvious that was a bad choice.


On Thu, Jan 16, 2020 at 7:03 AM Sam Curren <telegramsam@...> wrote:
On including the -comm suffix: I ack the worry, but I think we can manage it by preferring it always, such as DIDComm-TLS or DIDComm Multicast. Calling it DIDComm also cleanly differentiates it from DID work while maintaining the desired association. 

On monorepos:
 
Most of the benefits listed for monorepos are applicable to Very Large Projects, which will not apply well to our work. The primary benefit the seems to apply best is coordinated updates between the spec (usually in the form of clarifications) and the reference codebase. 

Also worth considering is the needs of future work (DIDComm Streaming, etc.) in terms of shared code (between streaming and messaging) and workflow needs and degree of overlap between involved parties.

For the sake of expediency, I think we should draw the line between those projects, and focus on the needs of DIDComm Messaging. I propose a repo called didcomm-messaging where we begin the spec work. We can decide in later discussions if that will also include the ref code or not.


On Wed, Jan 15, 2020 at 5:58 PM Tobias Looker <tobias.looker@...> wrote:
Hi,

The rationale for potentially dropping the comm part and calling it DID messaging, mainly came from the thought of what we as a working group will tend to shorten the name of this work to? If it is DID Comm messaging, won't the tendency be to shorten it to DIDComm? In that case when we do want to build DID-TLS or DID multicast the relationship to the umbrella term of DIDComm may get lost?

The language I was thinking is:

"DIDComm refers to a related set of technologies with a common aim of developing robust communication protocols using decentralized identifiers. The DIF DIDComm WG is where this effort is concentrated and the immediate focus of the WG is around furthering the development of a messaging based protocol called DID Messaging"

Thanks,
Mattr website 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@...
Mattr websiteMattr on LinkedInMattr on TwitterMattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Jan 16, 2020 at 12:02 PM orie <orie@...> wrote:
I'd love to see something like https://tools.ietf.org/html/rfc7520 for DIDComm Messaging.

I agree with Daniel regarding the potential complexity of didcomm (as an umbrella concept).

Not every project that uses monorepo structure has a well defined spec associated with it, here are some popular javascript frameworks that use the mono repo pattern:

https://github.com/babel/babel
https://github.com/facebook/react
https://github.com/angular/angular
https://github.com/trufflesuite/truffle

These all use lerna, which I am the most familiar with... There is also: 

https://github.com/korfuri/awesome-monorepo

Which talks a bit more about CI/CD, Code Ownership, etc...

When I start a new project, I try and avoid upfront modularization until I have a clear understanding how things relate. I'm a huge fan of microservices and reusable modules and components, but I think it's best to start with a monolith and refactor to a modular architecture once you find yourself feeling the pain of DRY, KISS, insert your favorite development paradigm... over architecting upfront can paint you into a corner where your modules start driving your thinking instead of the business objectives, and it's easy to put something aside if there is a place to put it. 

Regarding which reference implementation type do we want for didcomm, since didcomm appears to be built on JOSE, and I'm an obvious javascript fanboy, I would love to see a TypeScript  reference implementation. 

I think having a type system will help us a lot in terms of explaining interfaces, but because javascript is not very performant, I think this leaves room for a RUST or GO or WASM binary to be a clearly superior production version.

Whatever approach we decide for the reference implementation, it really should have 100% test coverage. Its an instant confidence killer to see that a reference implementation has poor coverage, and it's a good sign that it's gonna be close to useless for implementers.

I very often will implement something written in one language, in another, by simply recreating their unit and integration tests... this makes making a new version of the software very easy to tackle in small chunks, and you have confidence that you are compliant w.r.t. the reference implementation as you go.


DIF is geared towards hosting code and specs. I think we have an opportunity to set the "Gold Standard" for how DIF manages a complex software and spec project that is IPR protected, and easy to contribute to, but we will have to have the appetite for such a commitment, and I'm not sure if there is enough of an interest for member companies to support this approach for didcomm.

As Daniel noted, the complex the reference implementation will come at the cost of more friction. It will take more effort to keep the spec and reference implementation aligned, I'm not sure we have the engineering resources or member company commitment to do so.

These are all just suggestions, I'm not attached to a particular outcome.

OS



On Wed, Jan 15, 2020 at 3:08 PM Daniel Hardman <daniel.hardman@...> wrote:
Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am not making a claim about what's possible; it's possible to do all kinds of things with automation + human conventions, including making a release span multiple repos, or making a repo hold things that don't release together. This is an assertion about which tradeoffs are optimal because they generate the net least amount of friction, overall, over the lifetime of a rich project. (When FB offers a monorepo for react, it is because they're trying to provide a one-stop-shop to all developers who want react; the needs of the many [external devs] outweigh the needs of the few [maintainers], so monorepo friction is a cost worth paying. That might be right for them, but I don't think this WG is trying to produce a one-stop-shop for all things DIDComm. I thought the charter was about writing specs--not sample code, non-reference impls, demos, etc. Am I wrong?)

My assertion is debatable, of course. I don't have any proof of it other than my own experience. But if there is intense disagreement, I'd rather just shrug my shoulders and go silent. I don't think the stakes are so high that we have to be perfectly optimal, and I've said my piece now... :-)

But if you think my assertion is reasonable, the follow-on question is: What do we want to "release together"?

I'm pretty confident that different specs don't release together. They have entirely different lifecycles and maturities, and entirely different bug tracking, maintainers, etc. This argues for a different repo for each spec.

I am ambivalent about whether a spec and a reference impl should release together--and I think it's because Orie and I may have very different ideas about what a reference impl entails.

The unicode spec includes a reference impl of UTF-8 encoding. IIRC, it's about 35 lines of C code. A snippet of just the procedure for building an encrypted envelope might be analogous in DIDComm. Putting this type of stuff in with a spec feels great to me. I'm 100% in favor. You can even write unit tests that guarantees that the code stays in sync with the descriptive text.

But DIDComm is way, way more complex than UTF-8 encoding. If we're expecting a reference impl to exhibit all possible DIDComm features--routing through arbitrary layers of relays and mediators, multiplex encryption, support for multiple key types and multiple DID methods, message trust contexts, return route optimization, message timing, recovery from lost and out-of-order messages, asymmetric channels--we're talking about many thousands of lines of code, with subdirectories and project structure all of its own. It would have an elaborate build and test procedure of its own, very dissimilar from the procedures used by specs. Its maintainers would be different, and so would its code review process. If that's the kind of reference impl we're talking about, I'm far less comfortable keeping it with a spec, because it could create enough friction to slow down the spec.

So which ref impl type do we imagine?

On Wed, Jan 15, 2020 at 1:08 PM John Jordan <john.jordan@...> wrote:
+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global>   [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [Mattr on Twitter] <https://twitter.com/mattrglobal>    [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.







--
ORIE STEELE
Chief Technical Officer
www.transmute.industries



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Re: Repo Name

Sam Curren
 

On including the -comm suffix: I ack the worry, but I think we can manage it by preferring it always, such as DIDComm-TLS or DIDComm Multicast. Calling it DIDComm also cleanly differentiates it from DID work while maintaining the desired association. 

On monorepos:
 
Most of the benefits listed for monorepos are applicable to Very Large Projects, which will not apply well to our work. The primary benefit the seems to apply best is coordinated updates between the spec (usually in the form of clarifications) and the reference codebase. 

Also worth considering is the needs of future work (DIDComm Streaming, etc.) in terms of shared code (between streaming and messaging) and workflow needs and degree of overlap between involved parties.

For the sake of expediency, I think we should draw the line between those projects, and focus on the needs of DIDComm Messaging. I propose a repo called didcomm-messaging where we begin the spec work. We can decide in later discussions if that will also include the ref code or not.


On Wed, Jan 15, 2020 at 5:58 PM Tobias Looker <tobias.looker@...> wrote:
Hi,

The rationale for potentially dropping the comm part and calling it DID messaging, mainly came from the thought of what we as a working group will tend to shorten the name of this work to? If it is DID Comm messaging, won't the tendency be to shorten it to DIDComm? In that case when we do want to build DID-TLS or DID multicast the relationship to the umbrella term of DIDComm may get lost?

The language I was thinking is:

"DIDComm refers to a related set of technologies with a common aim of developing robust communication protocols using decentralized identifiers. The DIF DIDComm WG is where this effort is concentrated and the immediate focus of the WG is around furthering the development of a messaging based protocol called DID Messaging"

Thanks,
Mattr website 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@...
Mattr websiteMattr on LinkedInMattr on TwitterMattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Jan 16, 2020 at 12:02 PM orie <orie@...> wrote:
I'd love to see something like https://tools.ietf.org/html/rfc7520 for DIDComm Messaging.

I agree with Daniel regarding the potential complexity of didcomm (as an umbrella concept).

Not every project that uses monorepo structure has a well defined spec associated with it, here are some popular javascript frameworks that use the mono repo pattern:

https://github.com/babel/babel
https://github.com/facebook/react
https://github.com/angular/angular
https://github.com/trufflesuite/truffle

These all use lerna, which I am the most familiar with... There is also: 

https://github.com/korfuri/awesome-monorepo

Which talks a bit more about CI/CD, Code Ownership, etc...

When I start a new project, I try and avoid upfront modularization until I have a clear understanding how things relate. I'm a huge fan of microservices and reusable modules and components, but I think it's best to start with a monolith and refactor to a modular architecture once you find yourself feeling the pain of DRY, KISS, insert your favorite development paradigm... over architecting upfront can paint you into a corner where your modules start driving your thinking instead of the business objectives, and it's easy to put something aside if there is a place to put it. 

Regarding which reference implementation type do we want for didcomm, since didcomm appears to be built on JOSE, and I'm an obvious javascript fanboy, I would love to see a TypeScript  reference implementation. 

I think having a type system will help us a lot in terms of explaining interfaces, but because javascript is not very performant, I think this leaves room for a RUST or GO or WASM binary to be a clearly superior production version.

Whatever approach we decide for the reference implementation, it really should have 100% test coverage. Its an instant confidence killer to see that a reference implementation has poor coverage, and it's a good sign that it's gonna be close to useless for implementers.

I very often will implement something written in one language, in another, by simply recreating their unit and integration tests... this makes making a new version of the software very easy to tackle in small chunks, and you have confidence that you are compliant w.r.t. the reference implementation as you go.


DIF is geared towards hosting code and specs. I think we have an opportunity to set the "Gold Standard" for how DIF manages a complex software and spec project that is IPR protected, and easy to contribute to, but we will have to have the appetite for such a commitment, and I'm not sure if there is enough of an interest for member companies to support this approach for didcomm.

As Daniel noted, the complex the reference implementation will come at the cost of more friction. It will take more effort to keep the spec and reference implementation aligned, I'm not sure we have the engineering resources or member company commitment to do so.

These are all just suggestions, I'm not attached to a particular outcome.

OS



On Wed, Jan 15, 2020 at 3:08 PM Daniel Hardman <daniel.hardman@...> wrote:
Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am not making a claim about what's possible; it's possible to do all kinds of things with automation + human conventions, including making a release span multiple repos, or making a repo hold things that don't release together. This is an assertion about which tradeoffs are optimal because they generate the net least amount of friction, overall, over the lifetime of a rich project. (When FB offers a monorepo for react, it is because they're trying to provide a one-stop-shop to all developers who want react; the needs of the many [external devs] outweigh the needs of the few [maintainers], so monorepo friction is a cost worth paying. That might be right for them, but I don't think this WG is trying to produce a one-stop-shop for all things DIDComm. I thought the charter was about writing specs--not sample code, non-reference impls, demos, etc. Am I wrong?)

My assertion is debatable, of course. I don't have any proof of it other than my own experience. But if there is intense disagreement, I'd rather just shrug my shoulders and go silent. I don't think the stakes are so high that we have to be perfectly optimal, and I've said my piece now... :-)

But if you think my assertion is reasonable, the follow-on question is: What do we want to "release together"?

I'm pretty confident that different specs don't release together. They have entirely different lifecycles and maturities, and entirely different bug tracking, maintainers, etc. This argues for a different repo for each spec.

I am ambivalent about whether a spec and a reference impl should release together--and I think it's because Orie and I may have very different ideas about what a reference impl entails.

The unicode spec includes a reference impl of UTF-8 encoding. IIRC, it's about 35 lines of C code. A snippet of just the procedure for building an encrypted envelope might be analogous in DIDComm. Putting this type of stuff in with a spec feels great to me. I'm 100% in favor. You can even write unit tests that guarantees that the code stays in sync with the descriptive text.

But DIDComm is way, way more complex than UTF-8 encoding. If we're expecting a reference impl to exhibit all possible DIDComm features--routing through arbitrary layers of relays and mediators, multiplex encryption, support for multiple key types and multiple DID methods, message trust contexts, return route optimization, message timing, recovery from lost and out-of-order messages, asymmetric channels--we're talking about many thousands of lines of code, with subdirectories and project structure all of its own. It would have an elaborate build and test procedure of its own, very dissimilar from the procedures used by specs. Its maintainers would be different, and so would its code review process. If that's the kind of reference impl we're talking about, I'm far less comfortable keeping it with a spec, because it could create enough friction to slow down the spec.

So which ref impl type do we imagine?

On Wed, Jan 15, 2020 at 1:08 PM John Jordan <john.jordan@...> wrote:
+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global>   [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [Mattr on Twitter] <https://twitter.com/mattrglobal>    [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.







--
ORIE STEELE
Chief Technical Officer
www.transmute.industries



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Re: Repo Name

Tobias Looker
 

Hi,

The rationale for potentially dropping the comm part and calling it DID messaging, mainly came from the thought of what we as a working group will tend to shorten the name of this work to? If it is DID Comm messaging, won't the tendency be to shorten it to DIDComm? In that case when we do want to build DID-TLS or DID multicast the relationship to the umbrella term of DIDComm may get lost?

The language I was thinking is:

"DIDComm refers to a related set of technologies with a common aim of developing robust communication protocols using decentralized identifiers. The DIF DIDComm WG is where this effort is concentrated and the immediate focus of the WG is around furthering the development of a messaging based protocol called DID Messaging"

Thanks,
Mattr website 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@...
Mattr websiteMattr on LinkedInMattr on TwitterMattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Thu, Jan 16, 2020 at 12:02 PM orie <orie@...> wrote:
I'd love to see something like https://tools.ietf.org/html/rfc7520 for DIDComm Messaging.

I agree with Daniel regarding the potential complexity of didcomm (as an umbrella concept).

Not every project that uses monorepo structure has a well defined spec associated with it, here are some popular javascript frameworks that use the mono repo pattern:

https://github.com/babel/babel
https://github.com/facebook/react
https://github.com/angular/angular
https://github.com/trufflesuite/truffle

These all use lerna, which I am the most familiar with... There is also: 

https://github.com/korfuri/awesome-monorepo

Which talks a bit more about CI/CD, Code Ownership, etc...

When I start a new project, I try and avoid upfront modularization until I have a clear understanding how things relate. I'm a huge fan of microservices and reusable modules and components, but I think it's best to start with a monolith and refactor to a modular architecture once you find yourself feeling the pain of DRY, KISS, insert your favorite development paradigm... over architecting upfront can paint you into a corner where your modules start driving your thinking instead of the business objectives, and it's easy to put something aside if there is a place to put it. 

Regarding which reference implementation type do we want for didcomm, since didcomm appears to be built on JOSE, and I'm an obvious javascript fanboy, I would love to see a TypeScript  reference implementation. 

I think having a type system will help us a lot in terms of explaining interfaces, but because javascript is not very performant, I think this leaves room for a RUST or GO or WASM binary to be a clearly superior production version.

Whatever approach we decide for the reference implementation, it really should have 100% test coverage. Its an instant confidence killer to see that a reference implementation has poor coverage, and it's a good sign that it's gonna be close to useless for implementers.

I very often will implement something written in one language, in another, by simply recreating their unit and integration tests... this makes making a new version of the software very easy to tackle in small chunks, and you have confidence that you are compliant w.r.t. the reference implementation as you go.


DIF is geared towards hosting code and specs. I think we have an opportunity to set the "Gold Standard" for how DIF manages a complex software and spec project that is IPR protected, and easy to contribute to, but we will have to have the appetite for such a commitment, and I'm not sure if there is enough of an interest for member companies to support this approach for didcomm.

As Daniel noted, the complex the reference implementation will come at the cost of more friction. It will take more effort to keep the spec and reference implementation aligned, I'm not sure we have the engineering resources or member company commitment to do so.

These are all just suggestions, I'm not attached to a particular outcome.

OS



On Wed, Jan 15, 2020 at 3:08 PM Daniel Hardman <daniel.hardman@...> wrote:
Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am not making a claim about what's possible; it's possible to do all kinds of things with automation + human conventions, including making a release span multiple repos, or making a repo hold things that don't release together. This is an assertion about which tradeoffs are optimal because they generate the net least amount of friction, overall, over the lifetime of a rich project. (When FB offers a monorepo for react, it is because they're trying to provide a one-stop-shop to all developers who want react; the needs of the many [external devs] outweigh the needs of the few [maintainers], so monorepo friction is a cost worth paying. That might be right for them, but I don't think this WG is trying to produce a one-stop-shop for all things DIDComm. I thought the charter was about writing specs--not sample code, non-reference impls, demos, etc. Am I wrong?)

My assertion is debatable, of course. I don't have any proof of it other than my own experience. But if there is intense disagreement, I'd rather just shrug my shoulders and go silent. I don't think the stakes are so high that we have to be perfectly optimal, and I've said my piece now... :-)

But if you think my assertion is reasonable, the follow-on question is: What do we want to "release together"?

I'm pretty confident that different specs don't release together. They have entirely different lifecycles and maturities, and entirely different bug tracking, maintainers, etc. This argues for a different repo for each spec.

I am ambivalent about whether a spec and a reference impl should release together--and I think it's because Orie and I may have very different ideas about what a reference impl entails.

The unicode spec includes a reference impl of UTF-8 encoding. IIRC, it's about 35 lines of C code. A snippet of just the procedure for building an encrypted envelope might be analogous in DIDComm. Putting this type of stuff in with a spec feels great to me. I'm 100% in favor. You can even write unit tests that guarantees that the code stays in sync with the descriptive text.

But DIDComm is way, way more complex than UTF-8 encoding. If we're expecting a reference impl to exhibit all possible DIDComm features--routing through arbitrary layers of relays and mediators, multiplex encryption, support for multiple key types and multiple DID methods, message trust contexts, return route optimization, message timing, recovery from lost and out-of-order messages, asymmetric channels--we're talking about many thousands of lines of code, with subdirectories and project structure all of its own. It would have an elaborate build and test procedure of its own, very dissimilar from the procedures used by specs. Its maintainers would be different, and so would its code review process. If that's the kind of reference impl we're talking about, I'm far less comfortable keeping it with a spec, because it could create enough friction to slow down the spec.

So which ref impl type do we imagine?

On Wed, Jan 15, 2020 at 1:08 PM John Jordan <john.jordan@...> wrote:
+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global>   [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [Mattr on Twitter] <https://twitter.com/mattrglobal>    [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.







--
ORIE STEELE
Chief Technical Officer
www.transmute.industries



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Re: Repo Name

orie
 

I'd love to see something like https://tools.ietf.org/html/rfc7520 for DIDComm Messaging.

I agree with Daniel regarding the potential complexity of didcomm (as an umbrella concept).

Not every project that uses monorepo structure has a well defined spec associated with it, here are some popular javascript frameworks that use the mono repo pattern:

https://github.com/babel/babel
https://github.com/facebook/react
https://github.com/angular/angular
https://github.com/trufflesuite/truffle

These all use lerna, which I am the most familiar with... There is also: 

https://github.com/korfuri/awesome-monorepo

Which talks a bit more about CI/CD, Code Ownership, etc...

When I start a new project, I try and avoid upfront modularization until I have a clear understanding how things relate. I'm a huge fan of microservices and reusable modules and components, but I think it's best to start with a monolith and refactor to a modular architecture once you find yourself feeling the pain of DRY, KISS, insert your favorite development paradigm... over architecting upfront can paint you into a corner where your modules start driving your thinking instead of the business objectives, and it's easy to put something aside if there is a place to put it. 

Regarding which reference implementation type do we want for didcomm, since didcomm appears to be built on JOSE, and I'm an obvious javascript fanboy, I would love to see a TypeScript  reference implementation. 

I think having a type system will help us a lot in terms of explaining interfaces, but because javascript is not very performant, I think this leaves room for a RUST or GO or WASM binary to be a clearly superior production version.

Whatever approach we decide for the reference implementation, it really should have 100% test coverage. Its an instant confidence killer to see that a reference implementation has poor coverage, and it's a good sign that it's gonna be close to useless for implementers.

I very often will implement something written in one language, in another, by simply recreating their unit and integration tests... this makes making a new version of the software very easy to tackle in small chunks, and you have confidence that you are compliant w.r.t. the reference implementation as you go.


DIF is geared towards hosting code and specs. I think we have an opportunity to set the "Gold Standard" for how DIF manages a complex software and spec project that is IPR protected, and easy to contribute to, but we will have to have the appetite for such a commitment, and I'm not sure if there is enough of an interest for member companies to support this approach for didcomm.

As Daniel noted, the complex the reference implementation will come at the cost of more friction. It will take more effort to keep the spec and reference implementation aligned, I'm not sure we have the engineering resources or member company commitment to do so.

These are all just suggestions, I'm not attached to a particular outcome.

OS



On Wed, Jan 15, 2020 at 3:08 PM Daniel Hardman <daniel.hardman@...> wrote:
Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am not making a claim about what's possible; it's possible to do all kinds of things with automation + human conventions, including making a release span multiple repos, or making a repo hold things that don't release together. This is an assertion about which tradeoffs are optimal because they generate the net least amount of friction, overall, over the lifetime of a rich project. (When FB offers a monorepo for react, it is because they're trying to provide a one-stop-shop to all developers who want react; the needs of the many [external devs] outweigh the needs of the few [maintainers], so monorepo friction is a cost worth paying. That might be right for them, but I don't think this WG is trying to produce a one-stop-shop for all things DIDComm. I thought the charter was about writing specs--not sample code, non-reference impls, demos, etc. Am I wrong?)

My assertion is debatable, of course. I don't have any proof of it other than my own experience. But if there is intense disagreement, I'd rather just shrug my shoulders and go silent. I don't think the stakes are so high that we have to be perfectly optimal, and I've said my piece now... :-)

But if you think my assertion is reasonable, the follow-on question is: What do we want to "release together"?

I'm pretty confident that different specs don't release together. They have entirely different lifecycles and maturities, and entirely different bug tracking, maintainers, etc. This argues for a different repo for each spec.

I am ambivalent about whether a spec and a reference impl should release together--and I think it's because Orie and I may have very different ideas about what a reference impl entails.

The unicode spec includes a reference impl of UTF-8 encoding. IIRC, it's about 35 lines of C code. A snippet of just the procedure for building an encrypted envelope might be analogous in DIDComm. Putting this type of stuff in with a spec feels great to me. I'm 100% in favor. You can even write unit tests that guarantees that the code stays in sync with the descriptive text.

But DIDComm is way, way more complex than UTF-8 encoding. If we're expecting a reference impl to exhibit all possible DIDComm features--routing through arbitrary layers of relays and mediators, multiplex encryption, support for multiple key types and multiple DID methods, message trust contexts, return route optimization, message timing, recovery from lost and out-of-order messages, asymmetric channels--we're talking about many thousands of lines of code, with subdirectories and project structure all of its own. It would have an elaborate build and test procedure of its own, very dissimilar from the procedures used by specs. Its maintainers would be different, and so would its code review process. If that's the kind of reference impl we're talking about, I'm far less comfortable keeping it with a spec, because it could create enough friction to slow down the spec.

So which ref impl type do we imagine?

On Wed, Jan 15, 2020 at 1:08 PM John Jordan <john.jordan@...> wrote:
+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global>   [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [Mattr on Twitter] <https://twitter.com/mattrglobal>    [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.







--
ORIE STEELE
Chief Technical Officer
www.transmute.industries


possible outline for DIDComm messaging spec

Daniel Hardman
 

I'd like to offer this doc as a starting place for an outline for a DIDComm messaging spec.

https://docs.google.com/document/d/1Hn4ofl7ubRy22Xv1Yj1g77OkJWlWkDh88O3Od-yp8Cg/edit

I put sample content in 1 or 2 places, and notes about possible content in more places--but the content is less what I'm interested in than the general flow. What I want the WG to discuss is whether the general flow feels coherent and complete. My assumption is that if we can get an outline more or less into a shape we like, we can then have people volunteer to write drafts of major sections of the spec as parallel efforts, instead of asking for a single draft of the whole doc, (quite a daunting job).

Re: Repo Name

Daniel Hardman
 

Regarding monorepos: I am of the opinion that the optimal scope for a repo is the set of stuff that a consistent group of people is committed to (nearly) always release together. Please note that I am not making a claim about what's possible; it's possible to do all kinds of things with automation + human conventions, including making a release span multiple repos, or making a repo hold things that don't release together. This is an assertion about which tradeoffs are optimal because they generate the net least amount of friction, overall, over the lifetime of a rich project. (When FB offers a monorepo for react, it is because they're trying to provide a one-stop-shop to all developers who want react; the needs of the many [external devs] outweigh the needs of the few [maintainers], so monorepo friction is a cost worth paying. That might be right for them, but I don't think this WG is trying to produce a one-stop-shop for all things DIDComm. I thought the charter was about writing specs--not sample code, non-reference impls, demos, etc. Am I wrong?)

My assertion is debatable, of course. I don't have any proof of it other than my own experience. But if there is intense disagreement, I'd rather just shrug my shoulders and go silent. I don't think the stakes are so high that we have to be perfectly optimal, and I've said my piece now... :-)

But if you think my assertion is reasonable, the follow-on question is: What do we want to "release together"?

I'm pretty confident that different specs don't release together. They have entirely different lifecycles and maturities, and entirely different bug tracking, maintainers, etc. This argues for a different repo for each spec.

I am ambivalent about whether a spec and a reference impl should release together--and I think it's because Orie and I may have very different ideas about what a reference impl entails.

The unicode spec includes a reference impl of UTF-8 encoding. IIRC, it's about 35 lines of C code. A snippet of just the procedure for building an encrypted envelope might be analogous in DIDComm. Putting this type of stuff in with a spec feels great to me. I'm 100% in favor. You can even write unit tests that guarantees that the code stays in sync with the descriptive text.

But DIDComm is way, way more complex than UTF-8 encoding. If we're expecting a reference impl to exhibit all possible DIDComm features--routing through arbitrary layers of relays and mediators, multiplex encryption, support for multiple key types and multiple DID methods, message trust contexts, return route optimization, message timing, recovery from lost and out-of-order messages, asymmetric channels--we're talking about many thousands of lines of code, with subdirectories and project structure all of its own. It would have an elaborate build and test procedure of its own, very dissimilar from the procedures used by specs. Its maintainers would be different, and so would its code review process. If that's the kind of reference impl we're talking about, I'm far less comfortable keeping it with a spec, because it could create enough friction to slow down the spec.

So which ref impl type do we imagine?

On Wed, Jan 15, 2020 at 1:08 PM John Jordan <john.jordan@...> wrote:
+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global>   [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [Mattr on Twitter] <https://twitter.com/mattrglobal>    [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.





Re: Repo Name

John Jordan
 

+1 for DIDComm-messaging

+1 for separate repos — they can be associated to each other with GitHub Topics (tags)



________________________________
From: didcomm-wg@dif.groups.io on behalf of Sam Curren via Groups.Io <telegramsam=gmail.com@groups.io>
Sent: Wednesday, January 15, 2020 11:46
To: didcomm-wg@dif.groups.io
Subject: Re: [didcomm-wg] Repo Name

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?

On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...<mailto:daniel.hardman@...>> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
[Mattr website]<https://mattr.global>
Tobias Looker

Mattr
+64 (0) 27 378 0461
tobias.looker@...<mailto:tobias.looker@...>
[Mattr website]<https://mattr.global> [Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal> [Mattr on Twitter] <https://twitter.com/mattrglobal> [Mattr on Github] <https://github.com/mattrglobal>



This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...<mailto:telegramsam@...>> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam






This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Re: Repo Name

Sam Curren
 

Your point (reminder) about the -comm I think is well made. DID messaging rolls off the tongue

didcomm-messaging is the frontrunner then.

Orie proposed the monorepo alternative. Any last opinions about that approach?


On Mon, Jan 13, 2020 at 5:23 PM Daniel Hardman <daniel.hardman@...> wrote:
I'm pretty aligned with this--but I want to ask a question.

Tobias, when you and I discussed the notion of making room for other didcomm variants (e.g., for streaming or multicast), I thought "didcomm" was imagined as the uber term for all of them. Right?

Given this, I thought the narrower terms would be things like "didcomm messaging" and "didcomm streaming" --- not just "DID messaging" or "DID streaming". So my question is, how did we lose the "-comm" part?

On Mon, Jan 13, 2020 at 3:38 PM Tobias Looker <tobias.looker@...> wrote:
Thanks Sam, as I said on the call I think a pattern has already begun to emerge at DIF where a WG creates a repo for a distinct work item giving it an appropriate name and tagging it with the working group name. With that pattern in mind I would suggest the following convention.

Calling the repo did-messaging and tagging it with wg-didcomm on github.

To add further weight to this, I also think a similar pattern is present at places like the w3c-ccg, where a new repo is created per distinct work item, this has the benefit of keeping things like issues scoped to the topic rather than spanning all work items of a WG.

To aid in educating newcomers to the did-comm WG I think we should leverage a wiki which lists the work items of a WG and links to them.

Thanks,
Mattr website 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@...
Mattr websiteMattr on LinkedInMattr on TwitterMattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Tue, Jan 14, 2020 at 10:09 AM Sam Curren <telegramsam@...> wrote:
At the end of today's call, we had a mostly open question about the name of the repo to create to host our initial work. The two proposed names are did-messaging and didcomm-spec.

did-messaging would contain the specs related to DID messaging. Other specs (streaming etc.) would need a new repo.

didcomm-spec would host multiple specs under the same repo.

Please continue to voice your opinion here, so we can get the repos created soon.

Sam





This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

Re: Signing up for DIDcomm (legal)

Rouven Heck
 

Hi Kendra, yes - everything is completed for Workday. 

Balazs is going to share a Google sheet in the next 48 hours with the WG chairs which list all companies which have signed the WG Charter and therefore are formal WG members. It will also include the list of names who have signed the other IPR documents to be able to participate as individuals. 

Best,
Rouven

On Mon, Jan 13, 2020 at 11:18 PM Kendra Bittner <kendra.bittner@...> wrote:

Jon just confirmed signing. Please let me know if there are any issues.

 

Thanks!

Kendra

 

From: <didcomm-wg@DIF.groups.io> on behalf of Balázs Némethi <balazs@...>
Reply-To: "didcomm-wg@DIF.groups.io" <didcomm-wg@DIF.groups.io>
Date: Monday, January 13, 2020 at 11:29 AM
To: "didcomm-wg@DIF.groups.io" <didcomm-wg@DIF.groups.io>
Subject: Re: [didcomm-wg] Signing up for DIDcomm (legal)

 

Dear all,

I just sent the DocuSign links to the above listed legal representatives of your companies. Please notify them that they received it from Balazs@... (sometimes it boggles up in filters). 

I look forward for our call soon, 

 

On Thu, Jan 9, 2020 at 6:43 PM Balázs Némethi <balazs@...> wrote:

Dear all,

Happy New Year! 


We are very close to set up everything and start to work properly. 
I am sending this email as a first step to make sure that DIDcomm has IPR protection. There is a separate message for members and for those who will individually contribute.

 

-----for members------

As of now, we are still waiting for JDF to share with us the DocuSign link for the finalized and SC approved charter. However, to make the process smoother by the time we receive the DocuSign (hopefully today, tomorrow).

 

Please notify the people listed below with the message that I will reach out with a DIDcomm DocuSign link in the coming days. The goal is to get the documents signed asap making sure that it is done before the meeting.  

 

I collected (from the mailing list) the DIF member companies, whose legal representatives (listed below) will need to sign DIDcomm's charter (or someone else also can who legally represents the company).

 

Workday -  Jon Ruggiero

Evenym - Drummond Reed

mattr.global - Tobias Looker

Streetcred - Riley Hudges

Microsoft - Ankur Patel 

Consensys -  Matt Corva

Sovrin - Sam Curren

Gov.bc.ca - John Jordan

SecureKey - Gordon Ackyord

 

If someone knows another DIF member who is interested to attend the call, ask them to reach out directly to me asap. (for the reasons above) 

 

----for individuals-----

 

Good news, this is working. :)

 

When participating as an individual, you contribute on behalf of yourself and not on behalf of an employer (if there is one). 

 

Please register through this form 

https://forms.gle/wWeiWD8vguWmVHjt8 and you will automatically receive the feedback agreement DocuSign document, please sign it asap, before the meeting. [Do not share this form, if someone outside of those who are on this mailing list would like to join, please make them reach out to me.] 

 

------

Let's try to make the Monday call IPR protected! :) 

 

 

Thanks for all the support and it is the right time to make DIDs communicate! 

best regards,

 

--

 

Balázs Némethi

Operations @ DIF


 

--

 

Balázs Némethi

Operations @ DIF