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.

Join didcomm-wg@DIF.groups.io to automatically receive all group messages.