Launch Link specification discussion

[damianavila]

Context

In several conversations with @arnim, he surfaced the need (and importance) of having the link capability that currently the pBHub experience offers conserved somehow (or really good reasons to change it) because there are 3rd parties that need to start building stuff on top of this expectation/agreement.

I acknowledge this conversation is part of a bigger conversation around UX/UI defined at #1597, but it would be nice to decouple that conversation a little bit and start discussing in more detail how the launch link specification might look like, maybe even in an experimental setting like the one proposed in #1930.

One important goal/frame that might help guide the discussion: "links shared by someone wanting to spread knowledge should work without any modification (the very same repo/artifact) in myBinder, in the pBHub and in "whatever thing we are doing" (that would most likely be the proposal in #1930 and, maybe, some additional pieces).

Proposal

I would say the pre-existing capabilities outlined in the pBHub (and hence the BinderHub) experience would be a good starting point for the discussion.

Some questions:

1. How important do we think the current link-based and link-share capabilities are?
2. How do we envision that very same general link-based workflow would operate with the proposal outlined in A minimalistic proposal to replicate some of the workflows coming from the pBHub experience. #1930?
3. Is there any good reason to bet against the current link-based capability and think about a more dramatic change or do we think the workflow is established enough and spread enough that we have to take into consideration (even when future UX/UI might indicate another route?).

Updates and actions

No response

[arnim]

Thank you @damianavila

It would be good to have a specification enabling 1-click import of binder-ready repositories from galleries.
#1598 (comment)

This issue is part of #1382, #1598 and 2i2c-org/2i2c-org.github.io#118.

[yuvipanda]

The link based capability is the primary reason binderhub got really popular, and also the primary reason nbgitpuller got really popular. It allows one person to figure out the complexity of configuring what others need to launch, and just share that with others who don't have to know exactly what that link is but have it work is definitely a big part of the 'magic'. So I think we should definitely keep that.

In addition, https://www.w3.org/Provider/Style/URI :D So we can keep the current links working, but they are versioned so it is easy to change their structure with a v3 if necessary! We can keep redirects from v2 to v3 as needed. This is what we do in nbgitpuller, and it isn't too much extra overhead.

[arnim]

Indeed @yuvipanda its about ease of use :)

What we need is to strike is a balance between usability and simplification of the implementation i.e. get rid of the rather 'rich" dependency we used to have. I really like that the r2d-based implementation is very lightweight. Maybe we find a nice option to get a 1-click import in there without making it overly complicated :)

[arnim]

One thing we might have to think about is if we want to use nbgitpuller already for the initial import. How do we want to handle changes by the postBuild file that go beyond dependency installation, e.g. downloading of files, triggering additional builds ....
But maybe this use case should just be discouraged.