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.





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