►
From YouTube: September 7th, 2020 Jupyter RTC Community Meeting
Description
Recording of the Jupyter Real Time collaboration public meeting.
To attend the next meeting and see a list of all the notes, see this document: https://hackmd.io/UbnBH58hS8itoWgfiWT77A
Notes are archived to a Github issue https://github.com/jupyterlab/rtc/issues/3
B
B
Done
and
so
I'd
like
to
show
you
well
the
work
for
gp2
lab
master,
so
the
latest
version
of
jupiter
lab
with
rtc
pulled
from
last
year
branches.
So
we
we
had
a
lumino
data
store.
We
had
integration
with
jupiter
lab,
but
this
has
not
been
maintained
anymore
and
jupiter.
Lab
has
evolved
well
since
one
year,
quite
in
some
areas,
and
what
I'm
going
to
show
you
is
the
latest
jupiter
lab
with
rtc,
and
so
what
you
can
see
is
a
very
simple
notebook
with
two
browser.
B
B
So
you
see
here
in
chrome,
you
have
like
a
carrot
and
if
you
go
there,
you
see
this
is
someone
which
is
anonymous
by
default.
So
this
is
someone
else,
but
we
don't
have
any
authentication
at
all.
We
don't
have
any
notion
of
who
is
doing
what
yet
reverse
yeah.
I
have
that
carrot,
which
is
a
carrot
of
the
firefox
guy.
B
B
B
It
was
not
like
a
merge,
so
I
wasn't
able
to
to
take
back
the
history
I
mean
so
I,
in
a
way
I
had
to
to
to
apply
parts
portion
by
portions
of
patch,
so
I
was
not
like
merge
or
rebase.
I
mean
it
was
completely
for
me
not
possible
to
do
that,
and
I
think
the
goal
is
just
to
to
to
now
to
have
something
more
moderate.
So
we
can
link
to
to
the
evolution
of
what
we
do
in
rtc.
B
B
No,
it
was
working
yeah.
What
I
have
done
also
is
disabled
new
extensions.
I
mean
the
dark
table
of
content
as
the
debugger
the
lot
console,
because
yeah
the
model
has
changed
and
the
way
your
objects
are
constructed,
notebooks
and
so
on
I
mean
in
that
implementations.
The
construction
of
the
object
has
changed,
so
it
broke
in
a
way
using
the
new
charts,
the
new
debuggers,
the
new
log
console
and
the
new
cell
tags.
B
This
is
something
I'm
working
on
not
very
far
yet
you
need
to
to
build
some
slides
because
it's
a
talk,
a
25
minute
door,
so
my
goal
is
just
to
to
present
what
we
have
so
far.
I
mean
the
examples,
the
the
repository,
our
goal
and
maybe
the
lab
so
far,
and
maybe
what
you
have
done,
I
still
don't
know,
I'm
still
I'm
just
building
stuff
slides.
So
if
anyone
wants
to
to
write
a
comment
on,
there
is
an
issue
I
have
open
and
anyone
can
put
something
there.
B
A
A
So
it's
sort
of
like
an
in-memory
representation
that
we
currently
have
in
jupiter
lab
but
stored
on
the
server
side,
so
yeah.
If
we
we
start
that
up,
so
we
have
our
normal
jupiter
server
and
then
we
can
launch
this
graphql,
editor
dlio
and
so
I've
only
added
a
few
things,
one
so
far
from
the
jupiter
server.
One
thing
is
the
kernel
specs,
so
I
can
get
all
the
kernel
specs
and
their
names
and
ids
etc.
A
A
A
A
Information
about
executions
and
such
through
graphql
through
subscriptions
and
so
yeah.
I
added
some
notes
on
what
the
next
steps
there
are,
but
also
and
nick
posted
some
information
about
how
he
hooked
up
tornado
and
graphql.
So
that
was
useful.
I
cribbed
some
of
that
and
updated
it
a
little
bit.
So
that's
good
that
that's
working
and
then
yeah.
So
I
guess
from
the
high
level.
A
A
But
then,
for
a
more
interactive
experience,
say
like
in
jupiter
lab.
The
idea
would
be
to
explore
how
we
could
layer
sort
of
an
rtc
component
on
top
of
that
to
make
live,
editing,
collaboration,
easier
sort
of
the
rationale
is
that
graphql
is
already
a
very
well
defined
spec.
So
we
have
like
our
our
schema
here
for
jupiter,
and
so
we
have
things
like
the
kernel,
spec,
etc,
and
so
the
nice
thing
about
this
is
we
can
document
this
and
then
different
clients
can
implement
this
endpoint.
A
However,
they
like
so
it
it's
a
nice
way
to
be
really
explicit
about
what
the
protocol
is,
that
we're
defining,
because
we
can
leverage
all
the
work
already
being
done
in
the
graphql
community
to
basically
type
what
data
is
available
and
how
to
fetch
different
data
from
the
server
yeah.
So
that
was
the
demo.
I
had
happy
to
answer
any
questions
or,
if
any
other
folks
have
thoughts
on
this
approach.
C
A
Yeah,
the
schema
is
shared,
I
guess,
between
the
clients
and
the
server.
So
as
the
server,
you
need
the
schema
to
declare
what
endpoints
you
expose
and
then
as
a
client
you'll.
Probably
you
don't
need
the
schema
to
query
things
but,
as
we
were
saying
like,
you
could
generate
sort
of
client
code
to
access
the
api
in
a
type
safe
way,
using
the
schema,
if
that
makes
sense
and
each
component.
What
do
you
mean
by
a
component.
A
B
B
Yeah,
so
so
you
developed
a
jupiter
server
extension
for
that
I
think
yeah
very
good,
but
for
now
it
is
about
asking
the
kernels
and
probably
after
requesting
the
execution
of
code,
it
is
about
replacing
the
rest
api
today.
It
is
about
that,
but
tomorrow,
what
do
you
want
to
achieve?
Do
you
want
to
to
ask
graphql
to
do
rtc
for
us,
or
do
you
want
to
to
use
that
below
our
implementation.
A
A
A
If
two
clients
are
both
connected
to
the
crdt
server,
they
would
be
exchanging
changes
through
that,
like,
like
you,
were
showing
right
with
jupiter
lab
and
then
at
some
point
it
would
synchronize
to
the
graphql
server
so
either
every
change.
It
would
maybe
send
both
like
the
graphql
server
sort
of
like
the
long
living
state,
and
then
I
see
that
the
crdt
server
is
just
about
sort
of
the
shorter
term
right,
it's
more
like
hey,
I'm
typing
right
now:
you're
typing.
A
Okay,
we
can
synchronize
all
these
changes
and
now
we're
at
the
same
state,
and
now
one
of
us
or
both
of
us
or
some
server
node
right,
says
all
right
server.
The
current
state
of
the
document
is
this,
and
that
maybe
is
some
kind
of
like
collapsed
version
of
hey.
We
did
all
these
changes
now.
Take
this
bundle
and
say
hey:
this
is
the
current.
A
I
don't
know
that's
like,
as
you
can
see
kind
of
preliminary,
but
just
trying
to
think
about
ways
yeah
that
we
can
layer
it
on
top
that
is
sort
of
like
tangential
to
jupiter
itself
right.
That
is
more
just
about
hey.
I
have
some
graphql
schemas
and
maybe
there's
some
and
mutations
and
there's
some
way
to
layer
a
real-time
component
on
top
of
those.
So.
C
Basically
blobs,
so
one
thing
that
we
want
to
see
our
dt
is
the
state
database
so
that
we
can
get
rid
of
workspaces
and
really
you
just
have
the
same
workspace
open
in
20
windows.
They
all
modify
it
and
it's
fine.
But
in
order
to
get
that
to
work,
we
don't
control
the
contents
of
the
state
database.
Each
extension
does
so.
Would
this
support
that
kind
of
use
case.
A
So
I
guess
I
hadn't
thought
that
much
yet
about
how
we
store
jupiter
lab
state
with
this
system
at
least
starting
with
just
how
do
we
store
jupiter
state
and
then
the
question
of
oh
well,
I'm
an
extension-
and
I
have
my
own
state
right
that
I
want
to
persist.
Yeah.
I
think
that
needs
more
thought
about
how
that
works.
Basically,
I
mean
it's
in
the
current
system,
with
the
data
store
and
all
that
kind
of
stuff.
It
makes
sense
right
because
in
that
system,
you're,
basically
shipping
all
the
changes
to
everyone.
A
So
everyone
has
the
same
database
of
everything
and
that's
really
nice
for
things
like
ui
state
right,
but
for
things
like
server
state
like
the
state
of
a
notebook
or
execution,
you
don't
really
want
everyone
to
have
everything,
because
it
maybe
is
too
big
or
you
need
some
way
to
say
hey.
I
only
want
this
notebook
or
etc.
A
So
that's
sort
of
where
the
graphql
part
is
helpful
because
it's
like
I
don't
want
all
my
data
everywhere
right,
that's
just
too
much
that
would
be
nice
and
if
we
could
do
that,
it'd
be
a
lot
easier,
but
it's
not
really
viable.
At
least
that's
what
it
seems
like.
We
need
to
implement
some
kind
of
pagination
or
sharding
or
something
at
some
point.
So
the
idea
was
all
right.
A
C
The
api
for
the
state
database
itself
will
probably
have
to
change
right.
The
state
database
just
says,
give
me
a
key
and
a
value,
and
the
value
is
basically
untyped.
I
can't
remember
if
it's
arbitrary
object
or
or
if
it's
a
string,
that
it's
going
to
parse
or
something
but
whatever
it
is,
it's
untyped.
C
A
A
B
Yeah,
maybe
so
to
add
to
to
the
idea
of
central
state,
which
is
some
from
time
to
time
updated
by
the
clients.
Well,
it
makes
me
think
I
didn't
mention
that
why
I
was
showing
the
demo,
but
I've
been
a
bit.
Well,
maybe
it
was
expected,
but
I've
been
a
bit
surprised
when,
with
the
history,
when
you
open
a
notebook,
what
it
does,
it
pulls
a
complete
history
of
that
notebook
so
with
today,
luminous
data
store-
and
I
think
it
has
been
raised
on
the
issues
at
some
point.
B
But
when
you
open
the
notebook
if
the
notebook
is
has
been
updated
since
days
or
months,
you
will
get
that
month's
history
and
no
choice.
For
that
I
mean
you
get
all
the
beats
and
and
movement
and
changes
and
the
client
has
to
to
reconciliate
and
to
merge
all
that.
So
he
has
to
place
a
complete
history
which,
with
what
you
described
with
the
central
server,
which
is
from
time
to
time,
updated
with
the
state,
it
could
be
something
which
will
help
with
that.
A
Definitely
yeah
that
was
another
motivation
from
talking
to
william
stein,
too
right
around
ko,
calc
and
yeah.
That
sort
of
we
need
and
two
systems,
one
that's
the
short
term
system
and
then
the
longer
term
checkpointing
kind
of
like
system
and-
and
so
I
think,
yeah-
that's
we'll
have
to
figure
that
tune
that
in
some
way,
but
yeah
and
I-
and
so
I
think
those
are
all
the
interesting
questions.
So
I'm
hoping
to
get
through
this
sort
of
like
sort
of
rote
but
needed
part
of
building
out
this
graphql
server.
A
That
just
reflects
everything
on
the
jupyter
server.
Like
that's
pretty,
there's
not
really
many
decisions
there.
I
think
it's
just
mainly
you
know
implementing
things
and
then
I
think
once
that's
done,
then
the
more
interesting
and
or
you
know,
more
unknown
parts
we'll
have
to
dive
into
like
how
do
we
keep
them
in
sync?
And
how
do
they
work.
A
C
A
I
think
it's
seems
like
the
right
way
of
going
based
somewhat
based
on
technology,
but
more
based
on
community
I'd,
say
than
anything,
and
that
the
fact
that
there's
a
lot
of
good
discussions,
it
seems
like
happening
around
the
graphql
spec
and
different
packages
that
interact
with
it
that
are
all
kind
of
focused
on
the
same
questions
we're
trying
to
tackle
around.
How
do
we
ship
data
from
client
to
the
server?
And
how
do
we
specify
that
so
yeah?
A
C
C
No,
I
don't,
I
don't
know
the
space
well
enough
to
have
a
an
opinion
here,
so
I'm
I'm
mostly
curious.
I
don't
you
know
like
there's
a
there's,
a
level
of
confidence.
You
need
to
fear
when
you
pick
a
technology
that
you
think
is
going
to
last
you
maybe
the
last
like
it's
going
to
sort
of
make
you
commit
to
about
like
10
years
or
something
that's.
You
know
like
that's
the
order
of
magnitude
we're
talking
about,
so
I
neither
have
a
strong
opinion
about
which
way
to
go.
C
A
Yeah
I
mean-
I
guess
all
of
this
is
still
provision.
I
mean
there's
a
lot
of
there's
a
lot
of
stakeholders
in
this
space
of
different
clients
and
users
etc.
So
I
think
all
of
this
is
still
provisional
until
there's
buy-in
from
folks
and
until
we
can
say
hey
that
you
can
actually
build
a
product
out
of
this,
that
solves
user
needs
right,
it's
all
provisional,
I
would
say.
Even
then
you
know
it's
still
provisional
until
it
gets
until
we
say
all
right,
let's
make
a
jet
for
this
and
standardize
it.