Date   

Darrell O'Donnell and the CULedger project

Juan Caballero
 

The Glossary Group has decided to focus on the meaning of service endpoints for DIDs. 


We are looking for community input on our current definitions of 5 different endpoints and would like your input. 

https://forms.gle/SkAmGFpZLZngMi5k8


We are also ranking these endpoints by how important people feel they are to interoperability and adoption. 


We have made space on the survey to name up to 3 additional types of service endpoints you are important to DIDs. 


Our goal is to get at least 20 responses from community members. This group was formed at IIW29 and chose to nest at DIF but is seeking broad input from all the different groups in the community.  Please feel free to pass this link along to anyone you think might have constructive input.


https://forms.gle/SkAmGFpZLZngMi5k8


Looking forward to hearing from you. 


  • Kaliya Young, Adrian Gropper, Juan Caballero, Sankarshan



-------- Forwarded Message --------
Subject: Darrell O'Donnell and the CULedger project
Date: Mon, 3 Aug 2020 19:51:06 +0200
From: Juan Caballero <juan.caballero@...>
To: sds-wg@dif.groups.io


Hey SDS:

Just a quick note on our use-cases document: Has anyone chatted with Darrell O'Donnell on these matters?  I was just looking at his 2019 report on bridging identity wallets and crypto wallets and I came across this curious section.  He'll be at the EIC thing Thursday, so I was thinking of inviting him to have a little chat about it. Are people from outside the group welcome to open github issues on the use case documents or otherwise inform/discuss them, or is that an IPR no-no?   

Thanks,
--
-----------------
Juan Caballero
Research Lead,
Spherity GmbH, Emil-Figge-Straße 80, 44227 Dortmund
Next meetup 19/8: Identity Wallets for electronic authentication in the Pharma Supply Chain

Berlin-based: +49 1573 5994525 Signal/whatsapp: +1 415-3101351


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.