Re: Repo Name
toggle quoted messageShow quoted text
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