[FEA] Running Graphistry & Voilà on Binder

[jukkahuhtamaki]

I would like to create a Jupyter Notebook that uses Graphistry and Voilà and run it on Binder.

However, I do not perceive a way to share Graphistry credentials in a way that does not reveal them publicly.

I am aware that this is not a Graphistry-specific question. However, I am sure there are others with similar interests and objectives.

[lmeyerov]

Hi @jukkahuhtamaki , a couple of thoughts:

-- Can you generate & embed a plot, then remove your credentials? If helpful, you can get the url by opening in a new tab, or programmatically via url = g.plot(render=False) By default, plots are public-read, just with an unguessable url, so published notebooks should have the live plot

-- Is there another pattern that would be helpful to support?

[jukkahuhtamaki]

Nice, thanks for the tip @lmeyerov! We should make that work at least in some of our use cases.

Another pattern I came to think is that Graphistry would allow a user to log in once they fire up a visualization, here a notebook where Voilà is running Graphistry on Binder). That should work because you are controlling the Graphistry component, right?

Edit: the proposed pattern is probably either difficult or impossible to implement. However, I'll leave it here as food for thought.

[lmeyerov]

Hmm, interesting. I can imagine a few variants here to smooth running someone else's cells:

UX:

• [ ] explicit login graphistry.login() / graphistry.logout() vs auto-triggering on .plot() ?
• [ ] login box as part of cell output vs as a popup ?
• [ ] login box also support new users via fast signup (social, ...)
• [ ] should non-logins count as cell fails, so people can run all without plots? some way to pick, and what is the default?

Security:

• [ ] Login gives the nb control of your graphistry account; should we force login per kernel, or persist across jupyter sessions?

Any thoughts/prefs on those?

---

Separately, we're also thinking through 2 things:

1. Near-term: Secure sharing, such as by inviting users to a viz by email address, initially via sharing button in the viz. When they see the previously embedded plot and try to run it, the viz will ask them to login etc. to authenticate. The authentication info is inaccessible to the notebook, so the notebook can't muck with your graphistry account. In notebook settings, authorized users might want to update the data in the shared viz (replot, ...) without losing shared state like the access list, which we're thinking through.

2. Long-term: Delegation, where you might enable anyone with some sort of limited reuse of your account ('generate plots up to X big, use Y GPU time, but not read my other graphs'). A few more things need to happen on our side in prep for that.

[jukkahuhtamaki]

Awesome, major thanks @lmeyerov. With Voilà, it is probably easiest to have an auto-triggering popup as part of the actual viz view because it seems to be difficult to coordinate text input files with code that runs the visualization.

I should be able to create a demo notebook on what we want to achieve. I'll add it here when I get a chance to work on it.

[lmeyerov]

Great -- and thoughts on your use case:

• should logged out user .plot() cells 'fail', or continue with a 'warning' (cell: 'login and rerun cell to generate plot')? Failing would halt run all flows, which is good for attention to the need, but can also be annoying.

Separately, the security risk of login per notebook kernel vs per notebook server (e.g., across notebooks) is less obvious, I'm wondering if there is security precedent...

[lmeyerov]

Based on various discussions, sounds like we should enable a notebook mode:

• When in Jupyter (autodetect) or explicitly enabled via .register(mode='login_widget') (default: auto, alt: api)
• Plot call, if not logged in or JWT expired, will show an ipywidget for user/pass login & replot upon login
• The notebook will proceed without halting

TBD:

• Whether the login should apply for the kernel session, or use a browser cookie and persist across the origin, which would mean other notebooks and pages on the same domain