Merging efforts between incubation-wallet-rendering and web5-components

There’s a lot of overlap between the scope of adding playground.js and start walletrendering.js by andorsk · Pull Request #8 · TBD54566975/incubation-wallet-rendering · GitHub and the scope of GitHub - TBD54566975/web5-components. In particular, if you look at the initial proposal: TBD Incubator Proposal 1c -- Display editor easing visual presentation of VCs, conforming to Wallet Rendering spec - HackMD, you’ll see that the idea was to make reusable JS web components for rendering a Verifiable Credential, which is very similar to web5-components/VerifiableCredential at main · TBD54566975/web5-components · GitHub.

I had a great talk with Devin, and we took fundamentally different approaches to the same problem. I think there’s overlap to compliment each-other and I’d like to propose we do a better job of aligning efforts across repos.

The goal of this post is simple:

To determine if there’s a way to reduce duplication of work and consolidate efforts. To extend that point: As of right, I feel like the two repos are competing with each-other, which I’m not in favor for a number of reasons.


High Level Details on Approaches Below

  • Devin’s Approach: I would classify Devin’s approach as simple, concise, and a more direct implementation of the Credential Manifest Specs as is. It’s a great starting point. i.e Given this particular set of specifications in the Credential Manifest, here’s a tool to render it. It’s probably a better starting point for getting something out the door, something I shot myself in the foot at when I expanded the scope unintentionally. It’s essential a v1 implementation of what I was intending to build for the Wallet Rendering proposal. @Devin hope you agree with my interpretation, but feel free to push otherwise.
  • My approach, to. be frank, is not simple in implementation and can be thought of as R&D or v2 version of the proposal. It requires parsing a schema into a DAG and basically building a rendering language around it. It ended up with a proposal in DIF right now inspired by JSONForms called JROs Proposal: JSON Schema Rendering Objects (JROs) · Issue #29 · decentralized-identity/wallet-rendering · GitHub. The idea here is that it’s a core library that can build a render from a JSON based specification. It’s highly extendable, more flexible, and meant to facilitate any arbitrary objects. The interface abstracts all the complicated stuff happening underneath, and there’s also a playground. It doesn’t work quite right yet, but it’s not crazy far from being done. That being said, I’m holding off doing any more work on it until I’ve figured out where we stand here.

I can see a few paths forward here:

  1. I think we can take Verifiable Credential component for Web5 components and merge it into the Wallet-Rendering repo OR we can actually convert “wallet-rendering” repository into a jro based repository, and when it matures, use it to power the Web5 Components.
  2. I like the idea of a playground, and we can merge some of the work related to a playground with current working VC render.
  3. I think we need to do a better job communicating across orgs efforts. Devin’s and my call was a start, but I think this needs to continue. Or at least, let’s have a better way to keep up to date with efforts.

What I don’t think is a reasonable path forward is having two competing implementations of VC rendering in the same org. That seems like a lot of wasted effort and could hurt adoption.

I suggest we merge them both into the web5-components repo under different directories. It’s too early to pick one approach and declare it superior. They even may end up serving different purposes - as you noted. However, they’re both under the same category.

i dont think there’s a problem with having multiple approaches. what i built was geared towards the CM spec as it is now, whereas your work focused on a potential future design/approach (a “v2” as you put it). ultimately i think it’s prudent of us to keep them separate to highlight this distinction to avoid confusing others who might want to use this as a way to render a CM.

frankly, i think a first step for any future collaboration needs to be a unification/understanding of direction, because i think that’s maybe where some of this stems from. and IMO that might be best to happen in the W3C/DIF, as that’s ultimately where the design of this will be standardized in a spec (unless there’s some other place im unaware of?). after all, the ultimate goal of this is to provide a library for developers to use that will follow the spec (i.e. it starts with the spec).

and FWIW i do think it’s great to experiment with possible alternative approaches, but we should do that in addition to building something that handles what we have now because there’s always the possibility that we stick with what we have now and wouldn’t want to be left with nothing in that scenario

I sort of see these as two different efforts.

In web5-components @drousso has a reference implementation of rendering VCs as per the current Credential Manifest Spec.

incubation-wallet-rendering doesn’t intend to be a reference implementation for rendering VCs as per the CM spec. It’s aiming to be far more generalized (almost a superset). it may be able to support rendering VCs in the way that CM details, but the two may diverge especially given that both are very early stages, which makes me think that keeping them separate makes the most sense. Definitely correct me if i’m wrong here in my understanding of what you’re hoping to achieve @andor .

@Moe, yes and no. The intent of the repo is intended to implement the current spec as is. This means something similar to Devin’s more straight forward implementation, however it ended up going out of scope into Proposal: JSON Schema Rendering Objects (JROs) · Issue #29 · decentralized-identity/wallet-rendering · GitHub, which had some good reception at DIF and might lead toward v2. That being said: @Moe you are correct, JRO’s are a superset of WR and CM and could be thought of as a separated but closely related effort in a lot of ways.

As per the accepted incubator proposal, Devin’s current v1 implementation is mostly aligned with how it was intended to go. Ideally IMO, these commits would have gone through the incubation repo as there was already aligned efforts between TBD and Benri around a proposal and we had all agreed to that was a direction that made sense from both orgs perspectives.

From my POV: I’d like to complete our proposal and ensure we do address our original commits, to manage a repo that renders a verifiable credential with the intent to be used as a component in a larger web5 components repo. Ultimately, I do want to give people the best possible software, and making sure there’s a clear choice of what to use and how to use it is important imo.

There’s a good chance that JROs efforts might need to spin out it to somewhere else, but it seems out of scope for the initial proposal, and I’d prefer getting something out the door sooner, where a good JRO implementation is quite tricky. I think for hitting the our commits, Devin’s current work in Web5 Components with some modifications would get us pretty far within proposal.

My proposal is: Let’s lift up the VC work from the Web5 components repo into the WR repo, and manage, and improve it there. Submodule it in the web5 components repo. Then, in a separated effort (maybe a new proposal), I’m happy to continue to work on JROs as the next version of tools that powers wallet rendering.

Put together a quick POC of merged effort between the two repos on the same branch. Some issues which I’ll need to sync with Devin about. Live editor works though, so makes it pretty easy to iterate and test things quicker.

Moved my stuff to a jro.js file and moved Devins stuff to vc.js file to separate out concerns.

@drousso would be great to get some of the assets you showed me for testing as well as some guidance on how to merge this correctly.