a GUI for issuing VCs and DIDs

[michaelneale]

Inspired by the excellent tutorial at: https://frankhinek.com/getting-started-with-tbds-ssi-service/

Using streamlit (https://streamlit.io/) - this is a easy-to-tinker GUI that lets people issue VCs, DIDs etc (and evolving work). this could run as a separate container when a developer is running via docker-compose. For exploration purposes (similar to swagger etc, not for production usage).

Streamlit is popular for showing off data centric applications, but uses python in a fairly simple scripted fashion (so you don't have to be an expert to tinker with it).

In this case I am also loading (externally) the list of available schemas from schema.org.

Some visuals:

[decentralgabe]

This is awesome! A few thoughts:

• We had planned a UI for the service to be developed in house. We debated whether it should live alongside the service code, in this repo, or be external. We landed on external - though we have not started on the code yet.
• You stated this is not for production purposes, but for experimentation - which is great. I'm wondering if this means it does have a place alongside the code, and could perhaps be expanded going forward to be an admin dashboard of some kind, or if it's better served to be for playing around
• In terms of language choice, I do like python, but I am biased. I have a strong aversion to the JS/TS ecosystem, and this I think is a much lower bar to enter for folks writing go code to play around with light UI code.

I'm inclined to merge as-is and handle the where it lives, what's its vision down the road since I think this can be immediately useful to folks wanting to play around with it.

What do you think?

[codecov-commenter]

Codecov Report

Merging #89 (00d2326) into main (139e384) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #89   +/-   ##
=======================================
  Coverage   26.63%   26.63%           
=======================================
  Files          13       13           
  Lines         751      751           
=======================================
  Hits          200      200           
  Misses        521      521           
  Partials       30       30           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[michaelneale]

This is awesome! A few thoughts:

• We had planned a UI for the service to be developed in house. We debated whether it should live alongside the service code, in this repo, or be external. We landed on external - though we have not started on the code yet.

Would this gui be for exploratory/developer use or end users?

• You stated this is not for production purposes, but for experimentation - which is great. I'm wondering if this means it does have a place alongside the code, and could perhaps be expanded going forward to be an admin dashboard of some kind, or if it's better served to be for playing around

I think admin dashboard is closer to this for sure, a starting point that isn't "curl".

• In terms of language choice, I do like python, but I am biased. I have a strong aversion to the JS/TS ecosystem, and this I think is a much lower bar to enter for folks writing go code to play around with light UI code.

Yes I am similar: I haven't seen anything quite like this in JS/TS or golang ecosystems, but it may well exist (just not sure what to google for) as ideally it would be golang to not add something else (even if it is a sidecar-ish container)

I'm inclined to merge as-is and handle the where it lives, what's its vision down the road since I think this can be immediately useful to folks wanting to play around with it.

What do you think?

Yes I think if its clear that it is of similar QoS to say swagger etc, that may be ok (and it can change implementations over time if something better comes along)

[decentralgabe]

Would this gui be for exploratory/developer use or end users?

We imagined it being more end-user focused, though a developer/admin console is certainly necessary. May be best as separate products.

I'd like to get some of our other team members to weigh in before merging. I'll aim to return to this (if I don't hear from them) EOD Thursday.

[michaelneale]

yes I could see it being separate (this dashboard type thing could even be in a seperate repo - although if its a dashboard type of thing ideally you want it in sync with the ssi-service repo at all times showing off all features).

it depends on the type of user/developer that fires up ssi-service, via docker-compose, it is nice if they have some in built thing to guide them through perhaps? (I was also thinking a notebook type approach could be interesting to guide people through API scenarios and let them experiment, but that may be a bit weird for most developers).

[decentralgabe]

agreed - going to merge this in, it's a great addition.
I think a notebook approach for APIs would be cool to see too.