Language & Architectural Choices

[decentralgabe]

Part of our ambition is to support, contribute to, and build upon standards-based work in an open manner. The standards field has a number of existing implementations of different libraries and components with varying degrees of openness. By openness, I mean whether the solution is tightly-coupled to a specific technology, company, or ecosystem, or more agnostic -- barebones implementations of standards that can be applied to a variety of use cases.

For example, let's consider a library for SSI primitives.

There a few public and open implementations across languages:

• Java by Danubetech - 2 contributors, 12 stars, last commit 2 months ago, 1 issue, 1 PR
  • Support for JWTs, VCs, VPs, Linked Data Proofs
• Typescript by Transmute - 8 contributors, 18 stars, last commit 6 hours ago, 38 issues, 0 PRs
  • Support for ... a lot! -- multiple DID methods and protocols, JWT/JWK, different BIPs, hashlink, credential revocations, multiple signature suites, Linked Data and more
• Aries Framework Go by Hyperledger - 174 stars, last commit 5 days ago, 346 issues, 14 PRs
  • Support for DIDs, VCs, DIDComm, KMS, Sidetree, Linked Data Suites, and more
  • API bindings for Go, REST, JS/WASM, Android, iOS
• Rust by Spruce - 12 contributors, 78 stars, last commit 3 hours ago, 58 issues, 4 PRs
  • Support for multiple DID methods, Linked Data, JWTs, ZCaps, Presentation, Issuance, Verification
  • Interfaces provided for JS, Flutter, HTTP, C, Android, Java, and more

Because the standards in the space are often moving targets, with much room for interpretation, It's hard to tell which implementations are compliant. It's even harder to determine the support these libraries have within and outside of their respective ecosystems, which makes it tough to estimate the longevity and robustness we can anticipate for each library. Some have pretty good external contribution, others none. If we wanted to, how could we contribute back? Do we have to form company-to-company partnerships? Individually sign CLAs? What if our changes aren't accepted, or our missions in development aren't aligned? Do we fork an implementation? Will their license allow that? What will our lawyers advise? What makes the most technical sense?

For our code we've gone down the path of not taking a stance, or coupling ourselves to specific use cases as much as possible. The DID SDK is a strong example of this: neutral implementations of standards. It has similar ambitions to the Transmute, Hyperledger, and Spruce libraries, with perhaps a wider focus on remaining neutral and fostering community-driven development and support. Most importantly, we are interested in building a foundation from which we can stand tall -- prove conformance and compliance with standards at different points in time -- and roll out software that is able to serve a variety of use cases.

Already, we've adopted a few different languages and toolkits. Go for the DID SDK and VC Service. Java for the tbDEX Protocol. Javascript and Typescript for the Hub SDK.

On one hand, a diverse set of implementations across languages and toolkits is important. It bolsters our offering, and demonstrates interoperability, and affirms a commitment to a wide range of support. This lowers the barrier to entry for anyone in our prospective ecosystem and should absolutely be a goal we strive towards! On the other hand, if we have a library, a sensitive library filled with cryptographic primitives and tricky signature suites with wide variation, and little demonstrated interoperability (if any), why would we focus first on re-implementing that across our young ecosystem? Why make our jobs more difficult and time consuming from the get-go?

Why not instead build up trust in our own ecosystem using our own tooling? The simplest, safest, and most straightforward option is for us to use shared tooling until we reach a certain proven point of stability and interoperability -- we're not there yet, and I'd estimate we're 3+ months away from that point. After that, we can consider using our own ecosystem (did-sdk, and other sdks we build) in other languages and ecosystems. Whether this is through compiling our library in other languages, or through compatible re-writes of our core tooling that we ourselves maintain. I recommend we pause, evaluate, and come to some form of consensus before we continue further on our path.

What do you think?

[csuwildcat]

@decentralgabe I don't want to pause Hub work, as that doesn't have any existing implementations, and given we know we want it in Web and server, it is logical to leverage JS/TS for the wealth of cross-plat packages that enable it to seamlessly run in either env.

As for the other aspects of the system:

• DID client libraries: I would use as much existing stuff we can instead of reimplementing every DID Method lib in a new lang. If there isn't a good option for a DID Method that we can pull in, then sure, implement one.
• VC component libs: same as with DID Methods - if some good components exist, why not suck them in and lessen the workload?
• VC Service: I have no preference here and don't really care, personally. I trust that you will create a great service that meets our needs using whatever you assemble/write for the constituent DID/VC components.

[decentralgabe]

I have some thoughts about hubs, but I don't want to re-focus the conversation on them too much. I will say that I think it's reasonable to build a golang hub for 'cloud-hubs' given go's strong support for concurrency. That doesn't mean no JS/TS hubs, it means hubs (and other tooling we build) will need to be supported on a variety of toolkits.

For DID client + VC component libs, I agree...but my question is - what are these libs, what are our needs, what are the terms of our engagement, how do we contribute, how do we guarantee interoperability, and so on. These are problems we need to solve -- but is now the right time to solve them?