►
From YouTube: OCapN: Interop Among CatTP Systems
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
Hey
so
yeah,
so
we
are
here
to
talk
about
kept
captip
interoperability
under
the
working
name.
Oh
captain
for
this
generation
of
cap
tp
type,
stuff
and
friends.
So
I
think
the
general
purpose
of
this
call
is
to
kind
of
get
our
sense
of
what
we
think
is
possible
compatibility
wise,
where
we
think
the
sticking
points
are
and
etc.
C
C
D
C
You
like
to
introduce
your
your
what
your
involvement
and
interest
in
cap
tps
ian
right.
E
So
I'm
ian
my
main
sort
of
angle
on
this
is
I'm
one
of
the
more
active
sandstorm
contributors
and
since
we
already
have
sort
of
what
is,
I
think,
currently
probably
the
most
widely
deployed
cap
tp
implementation.
It
would
be
sad
if
this
new
thing
were
not
compatible,
or
at
least
bridgeable
to
what
we're
using
that's
kind
of
my
angle
on
it
I
had
kind
of
I
was.
E
I
was
the
one
who
sent
the
email
kind
of
starting
this
and
I
originally
just
sent
it
to
chris
to
my.
My
own
interest
is
more
directly
with
the
the
goblin
stuff,
since
I
think,
there's
probably
more
community
overlap
between
that
and
and
sandstorm
than
there
is
with
agorik,
but
obviously
be
nice
to
have
fewer
in
incompatible
protocols.
More
generally,
so.
C
Great
so
at
that
point
I
think,
and
is
there
anybody
that
you
don't
know
ian
is
that
you
would
like
to
be
introduced
to
from
the
list.
F
Yeah,
I'm
not
sure
either
I'm
working
with
mark
and
chris
cowell
and
I'm
doing
a
lot
of
the
low-level
swing
set
kernel
kind
of
stuff.
Okay,.
C
A
Good
question:
does
anybody
mind
posting
it
publicly,
since
what
we're
doing
here
is
trying
to
converge
on
common
standards?
I
think
that
posting
it
publicly
would
probably
be
a
good
thing.
C
I'm
good
with
it:
okay!
Well,
in
that
case,
I'll,
continue
next,
so
I'm
christopher
lammer
weber,
I
am
current.
I've
got
interested
in
ocaps
because
of
all
the
things.
I
realized
that
we
couldn't
yet
do
in
the
decentralized
social
media
stuff
that
I
was
working
on
and
I
got
have
been
implementing
something
called
sprightly
and
specifically
the
component
sprightly
goblins,
which
is
kind
of
like
mark's
e
language,
mark
and
friends,
language
meet
scheme
and
I've
been
implementing
a
version
of
cap
tp.
C
So
I
have
kind
of
a
generalized
view
of
all
these
things,
so
not
a
complete
working
on
everybody
else's
stuff,
and
I
think
at
the
moment,
in
this
kind
of
new
generation
of
cap
tp,
I've
implemented
a
few
features
that
everyone
agrees
we
want,
and
that
was
already
implemented
in
ease
stuff
back
in
the
day,
such
as
the
garbage
collection,
stuff
and
handoffs,
but
otherwise
also.
I
think
that
it's
it's
there.
C
There
are
a
lot
of
similarities
between
the
way
that
sprightly
goblins
is
doing
things
and
the
way
that
gork
stuff
has
been
doing
things
so
mark.
Why
don't
you
go
next.
A
Okay,
I
did
the
first
captain
p
with
collaborators
first
and
elected
communities
and
then
with
the
open
source
e-rights
effort
around
the
e-language.
It
was
a
wonderful
experience
and
it
worked
well.
It
was
actually
for
me
something
like
the
fourth
generation
of
distributed
capability
protocol,
the
first
one
being
with
dean
for
joule,
and
I'm
very
you
know
proud
to
see
that
it's
sort
of
the
ancestor
of
all
of
these
other
efforts.
A
The
having
there
be
a
capd
family
of
protocols
is,
is
you
know
something
I'm
proud
of,
but
if
we
can
get
into
our
operation
of
bridging,
as
kenton
said,
that
would
be
even
better.
I'm,
the
chief
scientist
of
the
gorick
is
doing
their
own
capdp.
A
The
captip
that
we're
doing
is
necessarily
somewhat
biased
towards
being
friendly
to
javascript,
to
a
javascript-based
programmer
and
there's
a
certain
degree
of
compromise
that
I
think
I'm
willing
to
do
for
that
sake,
but
but
hopefully,
without
going
too
deep
into
violating
language
neutrality.
So
that's
that's
much
what
I
expect
we'll
be
negotiating
today
and
in
any
case,
gorick,
is
at
beta
with
testnet
and
we're
rapidly
moving
towards
real
production
deployment
of
the
cap.
Tp
and
there's
two
levels
that
I
think
are
significant
to
talk
through.
A
One
is
the
concrete
syntax
of
it,
which
I
think
is
easily
changeable
and
then
the
other
one
is
the
abstract
semantics
that
maps
onto
that
concrete
syntax,
which
is
where
I
think
the
the
difficult
negotiations
are
going
to
come
from.
C
By
the
way
before
we
continue
on
the
list,
I
just
got
an
update
from
baldr
that
he
is
frustrated
by
the
disusability
of
of
of
the
the
sign-in
process
on
this
particular
meeting,
and
so
has
he's
gonna
hang
out
in
the
other
ocap
meeting
that's
happening
at
the
moment.
So
that's
unfortunate
we'll
we
should
try
to
we.
I
think
it
would
be
important
to
get
balder
in
future
meetings,
though
so,
but
anyway,
let's
continue
on
with
brian
warner.
Why
don't
you
give
your
oh
wait?
C
F
In
addition
to
all
the
stuff
we're
doing
now,
I
worked
on
fools
cap,
which
was
an
attempt
at
doing
a
captain
p
like
thing
in
python,
on
top
of
twisted
and
yeah.
That's
enough.
C
Okay,
chris
sorry
cr
alternate
chris.
I
forgot
what
your
other
name
was
that
you're
gonna
use
here
chris
kowal.
D
When
another
chris
is
in
the
room,
I
can
be
called
calbert
to
disambiguate
the
about
almost
15
years
ago.
I,
when
mark
and
I
were
mutual
randos
on
the
internet.
I
said
to
mark
hey
I'd
like
to
propose
a
javascript
module
system
and
mark
said:
hey:
have
you
heard
of
promises
and
we've
kind
of
helped
each
other
succeed
for
a
while?
Now
and
and
that's
how
I
became
interested
in
cap
tp,
that's
it.
B
Sure
yeah,
I'm
kenton,
I
I
am
the
original
author
of
cat
and
proto
founded
sandstorm
some
time
ago
and
now
work
at
cloudflare
on
cloudflare
workers,
which
is
heavily
using
cap
and
proto
in
a
a
javascript
environment.
So
captain
proto
is
the
both
a
a
serialization
protocol
and
then
an
rpc
layer.
That
is,
I
would
call
it
heavily
based
on
captp.
A
Just
as
the
coiner
of
the
term
capdp
the
way
I
think
of
it-
and
you
can
tell
me
if
this
is
fine
with
you-
is
that
at
this
point
there
is
a
capdp
assertive
and
I
an
idea
for
how
to
do
a
a
distributed
capability
protocol
and
there's
a
family
of
protocols
that
that
are
within
that
idea,
and
the
captain.
Proto
is
one
of
the
protocols
in
that
family.
B
Fair
enough,
then
I
guess
it's
an
implementation
of
cap
tp,
captain
proto,
I
guess
what
I
see
is
the
big
difference
between
it
and
a
lot
of
these
other
ones
is
that
it's
based
on
a
strongly
typed
schema
system.
So
right
now
sending
dynamically
typed
javascript
around.
B
On
top
of
that
would
be
awkward
for
a
number
of
reasons,
but
guess
what
we
need
to
solve
that
at
cloudflare
as
well,
because
our
our
actual
platform
is
javascript
based
and
we
expect
people
to
be
able
or
to
want
to
send
around
javascript
structures
containing
capabilities.
At
some
point.
D
Correct
me,
if
I'm
wrong
is
also
a
memory
arena.
Protocol
right
is
that
is
that
a
fair
description.
E
So
it's
a
serialization
format
that
is
designed
to
not
have
an
explicit
decoding
step.
So
you,
you
have
a
code
generator
that
generates
classes.
If
you,
if
it's
c
plus
plus
you
know,
depending
on
your
language,
maybe
something
else
with
getters
and
setters
that
value
the
date
point
before
they
follow
them.
Follow
them.
So
there's
no
need
to
do
an
upfront,
parsing
step,
and
so
the
on
on
wire
format
and
the
in
memory
format
in
typical
usage
are
the
same.
It
doesn't
have
to
be
the
case.
It's
sometime.
E
B
So
it
is
true
that
for
zero
copy
serialization,
it
becomes
important
to
think
about
exactly
how
you
allocate
memory
so
that
you
end
up
with
a
message
that
is
in
contiguous
memory
that
you
can
then
write
out,
but
that's
all
the
serialization
side
of
captain
proto,
which
actually
has
little
to
do
with
cap
tp.
There's
these
two
layers
serialization
in
the
the
rpc
protocol.
D
I
I
should
also
point
out
from
my
background,
because
it's
come
probably
relevant
for
this
conversation
is
that
when
I
was
at
uber,
I
was
briefly
tech
lead
for
the
rpc
team
and
ended
up
rewriting
thrift
a
couple
of
times
so
there
so
there's.
So
I
have
some
experience
with
the
serialization
side,
which
is
actually
probably
the
most
meaningful
area.
I
can
contribute
in
the
conversation
now
that,
unlike
last
time,
I
talked
to
kenton
about
this
now.
I
know
what
it
looks
like
to
work
with
an
item.
C
So
so
why
don't
we
open
this
up
then
about
talking
about
kind
of
the?
C
So
the
the
in
a
certain
sense
this
is,
we
could
say
that
abstractly.
There
may
also
be
another
layer
which
is
abstractly
us
negotiating.
What
the
you
know,
the
future
like
if
there's
a
convergence
one,
but
we
but
so
the,
but
I
think
it
would
be
good
to
get
to
just
do
a
quick
summary.
If
I
can
about
what
I
perceive
of
as
the
core
differences
between
these
three
so
kenton,
I
think
already
raised
it
for
the.
C
What
I
think
is
the
biggest
difference
is
what
calbert
has
said
to
idle
or
not
to
idl
right
like
to
idle
or
not
to
idl,
as
like
kind
of
the
first
fundamental
decision
right.
So
if
you're
looking
at
the
lambda
cube,
are
you
starting
with
an
efficient
coding,
encoding
of
the
typed
lum
to
calculus
and
then
moving
and
then
perhaps
layering
a
an
untyped,
lumbda
calculus
type
approach
on
top
of
it,
or
are
you
starting
with
the
untyped
bomb
to
calculus
and
then
possibly
building?
C
C
So
those
are,
I
think,
those
are
kind
of
the
two
that
one
is
probably,
I
think,
the
biggest
area
of
contention,
the
other
on
the
on
the
other
side,
there's
agorik
and
sprightly
goblins,
having
implemented
two
things
that
I
think
are
very
similar
because
they
both
started
from
kind
of
the
untyped
lambda
calculus
perspective.
C
They
both
started
from
a
dynamic
lane
or
better
to
say
a
dynamic
language,
they're
still
typing
in
there
right,
but
there's,
but
it's
dynamic
typing
and
the
you
basically
have
a
core
set
of
agreed
upon
types
that
all
parties
are
going
to
have
some
sort
of
way
to
represent
and
then
and
then
you
basically
build
abstractions
on
top
of
that
right
and
there's
one
other
area
of
possible
distinction
that
we
had
talked
about
that.
C
I
think
before
this
call
we
have
already
resolved
is
probably
probably
not
a
big
distinction,
which
is
whether
or
not
you
have
a
big
distinction,
as
in
terms
of
the
memory
management.
So
mark
was
concerned
earlier
that
cap
and
proto
was
doing
a
was
doing
kind
of
manual
release
style
stuff
that
might
be
incompatible
with
the
perspective
of
the
the
cooper.
So
I'm
gonna
avoid
saying
distributed
garbage
collection
to
avoid
that
acyclic
thing
in
the
middle
as
much
as
it's
saying,
distributed
cooperative
garbage,
so
cooperative
garbage
collection.
C
I
think
it
may
be
a
bit
more
useful
at
the
moment,
mark's
still
looking
skeptical,
so
so
we
can
say
distributed
acyclic
garbage
collection.
I
feel
like
it's
a
bad
marketing
move
because
you're
throwing
this
caveat
into
the
middle
every
single
time
and
nobody
really
has
distributed
cyclic
garbage
collection.
C
But
the
main
point
is:
is
that
it's
possible
to
do
distributed,
acyclic,
garbage
collection
and
but
we
and
it's
even
theoretically
possible
to
do
distributed
cyclic
garbage
collection
in
a
very
complicated
way
that
none
of
us
are
currently
implementing
and
the
the
question
is
whether
or
not
those
are
two
different
mechanisms.
It
seems
as
if
and
tension
it
would
be
good
to
get
a
confirmation
against
an
andean
that
effectively
what's
happening
in
cap
and
proto.
Is
it's
using
the
same
mechanism
anyway?
C
It's
just
that
if
of
the
basically
reference
counting
at
the
border
for
messages
that
are
in
transit
plus
one
last
count
for
releasing
the
final
thing
basically,
and
then
it's
just
that
the
manual
release
is
just
that
last
step
being
basically
removing
the
final
one.
Is
that,
but
just
as
a
possibly
manual
step?
Is
that
roughly
correct
so.
B
Let
me
address
this,
the
so
yes,
captain
proto
uses
reference
counting
in
the
same
way
that
the
original
cap
tp
did.
B
But
what
I
found
is
the
applications
written
on
captain
proto
very
commonly
use,
explicit
destruction
as
a
feature
like
so
a
lot
of
protocols.
I've
designed
on
captain
proto
they
they
have
objects
where
it
says
when
this
object
is
destroyed.
This
will
happen,
but
that's
an
application
decision.
That's
not
actually
a
protocol
level
decision.
I
found
it
to
be
very
useful
and
I
don't
I
actually
don't
really
know
how
I
designed
some
of
these
protocols.
If
I
didn't
have
that
so
there's
that.
F
I'll
add
a
complication
in
there.
Some
work
we've
been
looking
at
in
the
last
month
to
support
we
weak
maps
on
either
end
and
allowing
one
side
to
know
when
somebody
else
can
no
longer
provide
the
key
that
was
in.
There
has
prompted
me
to
sort
of
implement
a
second
level
of
garbage
collection
messages.
F
So
there's
gonna
be
one
message
that
says
I
can
no
longer
provide
this
key
and
there's
a
different
message
that
says
I
can
no
longer
recognize
this
key
and
I've
realized
that
we
needed
both
of
those
in
order
to
actually
do
gc
of
of
of
things
that
involved
weak
refs
on
either
side,
and
if
you
didn't
have
things
that
could
involve
weak
graphs
in
some
fashion,
you
could
stick
to
the
the
simple
drop
one.
The
one
level
thing.
B
C
I
I
think
so
this
sounds
like
something
new
that's
being
discussed,
and
I
think
that
we
should
talk
about
that.
But
it
sounds
like
something
to
put
on
the
agenda
for
a
future
moment
because
right
now
we're
trying
to
distinguish
between
what
the
current
differences
are.
But
I
feel
like
that's,
that's
important
and
it's
good
to
know
about
that,
because
I
I'm
unfamiliar
with
that-
and
I
still
don't
understand
it
actually.
But
let's
let's
table
that
for
the
moment
it's
good
to
it's
good
to
know.
C
C
Okay,
that
would
still
be
that
would
be
helpful
as
well.
Okay,
great
so
the
so.
The
final
difference
is
really
the
difference
between
the
goblins
implementation
and
the
agorik
implementation.
So
this
one,
a
lot
of
this,
I
think,
is
kind
of
surface
level
like
there's
certain
things
about,
like
you
know,
how
do
you
represent?
C
C
If
we
do
things
right,
it
should
hopefully
be
possible
to
swap
out
the
serialization
system
from
at
least
of
dynamic
language
or
sorry,
the
dynamic
language
kind
of
approach
thing
as
kind
of
a
late
decision
right
like
now.
Obviously,
there's
a
huge
caveat
to
that,
which
is
that
if
people
start
using
and
depending
on
these
things-
and
it
does
become
harder
to
switch
but
from
the
perspective
of
like
ignoring
whether
or
not
people
have
picked
it
up
and
stuff
like
that,
and
we
were
saying
okay,
this
is
pre.
C
You
know
kind
of
like
major
adoption
swapping
out
the
particular
serialization,
whether
or
not
it's
json
or
syrup
or
really
even
a
cap
and
proto
encoding
should
hopefully
not
be
that
big
of
a
decision.
I
wonder
if
anybody
particularly
disagrees
with
that.
E
Well
so
there's
the
one
caveat
which
you
know
I
kind
of
when
I,
when
I
sort
of
first
weighed
in
on
the
issue
number
one
I
was
kind
of
advocating
for
let's
just
layer,
this
whole
thing
on
top
of
captain
proto.
So
we
don't
have
to
worry
about
bridges
or
anything
like
that
and
I
think
there's
an
argument
for
that.
I'm
more
open
now
to
let's
not
impose
the
full
complexity
on
cap
and
proto
serialization
on
every
implementation
as
a
possible
counterpoint.
E
But
if
we
do
that,
then
we
have
the
additional
constraint
that
we
have
concrete
protocol
messages
that
are
a
little
set
in
stone
already
for
for
the
the
two-party
case.
So
that's
the
caveat
there,
but.
C
Okay,
I
think
there's
one
more
thing
to
bring
up
here,
but
I
want
to
see
if
there's
any
comments
on
this,
but
I
think
this
is
actually
a
bigger
topic,
so
brief
comments
before
we
we
move
on
to
the
I
think,
the
last
point
of
order
or
last
point
of
this
distinction.
I
should
say.
D
Yeah
I
like
like
I
I
do
not
disagree.
I
think
that
the
concrete
serialization
format
isn't
important
at
this
stage
of
the
conversation.
The
much
more
interesting
conversation
is
what
reflected
types
we
should
be
able
to
support
and
being
able
to
discuss
that
concretely
was
helpful,
but
not
necessary,
like,
for
example,
I'd
like
to
establish
whether
we're
going
to
support,
for
example,
binary
data.
Are
we
going
to
support
symbols?
Are
we
going
to
support
enums
and
field
nums,
and
that
kind
of
thing
those
are
and
a
lot
of
that?
E
Well,
yeah,
I
mean
it's
also,
I
think,
there's
some.
This
also
comes
up
to
some
extent
in
the
discussion
with
like,
even
if
we
bridge
captain
proto,
probably
the
way
you
know
going
in
one
direction
calling
into
the
dynamically
type
stuff
from
a
cap
and
proto
bridge
is
kind
of
easy,
because
you
just
pick
an
interface
for
dynamically
typed
stuff
that
has
this
one
ast
for
the
data
model
and
you're
kind
of
done
going.
A
So
so
let
me
just
bring
up
what
I
think
our.
A
I
I
what
I'd
really
like
to
see
as
an
achievable
goal,
is
that
for
any
capability,
that's
made
available
over
any
one
of
these
systems
that
the
that
you
know
the
methods
on
that
cable,
the
methods
on
that
interface,
whatever
you
want
to
call
them,
the
methods
of
an
interface
can
be
invoked
by
code,
written
written
for
the
other
systems.
A
So
but
then,
what
I
think
is
beyond
what's
achievable.
What's
what
I
think
we
should
resign
ourselves
to
be
not
achievable
is
with
regard
to
the
naturalness
of
it.
A
Just
starting
with
the
discussions
we've
already
had
between
chris
webber
and
dusted
agorik,
the
scheme
style
will
produce
interfaces
that
are
stylistically
quite
different
than
the
job.
Then
the
style
which
we've
been
using
javascript.
A
So
even
if
we
ensure
that
anything
exported
by
scheme
can
be
invoked
by
javascript
and
vice
versa,
it
will
be,
I
think,
quite
apparent
in
the
nature
of
the
interface
was.
This:
was
this
interface
authored
by
someone
who
was
thinking
in
javascript
terms
or
thinking
in
in
scheme
terms,
and
I
I
would
expect
that
kind
of
mismatch
to
continue
but
being
able
to
bridge
awkwardly
is
is,
is
still
a
substantial
thing
to
achieve.
C
Yep,
I
agree
so
I
mean
it
just
doesn't
it's
a
is
a
simple
example.
That's
extremely
surface
level,
let's
assume
that,
even
if
both
sides
were
using
methods,
the
decision
about
you
know
the
casing
of
the
methods.
Are
you
using?
You
know
like
mixed
case
camel
case
you
know
like
or
like
you
know,
lower
case
and
dashes
or
lowercase
and
underscores
those
are
very
different
about
across
programming
languages.
C
C
There
may
be
come
a
time
where
we
decide
to
build
some
of
these
things
that
we
want
multiple
sides
to
be
able
to
implement,
such
as
the
let's
say
that
we
had
some
ertp
things
where
we
wanted
both
the
javascript
and
the
scheme
stuff
to
be
actually
talking
to
each
other
over
ertp
and
stuff,
like
that,
we
might
have
to
implement
the
same
interface
and
there
may
be
a
large
amount
of
biases
in
terms
of
who
moves
first,
and
we
might
even
agree
that
for
the
stuff-
that's
very
common
between
these,
we
might
actually
just
agree.
C
C
Choices
are
always
going
to
end
up
being
obvious
at
the
borders.
A
Yeah
and
I'm
very
hopeful
from
what
you
guys
have
already
said
about
storage
management,
that
the
de-allocation
deallocation
issue.
That
kenton
was
raising
falls
into
this
thing
about
very
strong
stylistic
differences,
but
not
an
impediment
to
enable
things
written
for
one
to
be
able
to
be
used
from
the
other.
E
Yeah,
I
agree
it
does
have
one
implication
that
probably
even
gc
oriented
implementations
do
have
to
have
a
way
to
say
drop.
All
of
my
references
to
this
object
from
this
vat.
E
Even
if
it's
like
not
super-
and
we
have
this
in-
like
the
node
implementation
of
captain
proto
already,
I
probably
need
to
add
this
to
the
haskell
implementation
already,
even
though
it's
not
supernatural
in
those
languages
that
needs
to
exist
it
again.
Yeah
it'll
be
one
of
these
things
that
clearly,
whoever
designed
this
api
was
thinking
in
c
plus
or
rust,
but
yeah.
B
Yeah
you'll,
when
using
protocols
that
are
designed
to
do
things
on
when
a
capability
is
dropped,
you're,
calling
it
from
a
garbage
collected
language.
You
need
some
explicit
way
to
do
that
and,
whereas
so
so
you
mentioned
naming
styles
like,
I
actually
have
a
fair
amount
of
experience
with
like
bridging
between
naming
styles,
that
that
I
would
consider
a
reasonably
solved
problem,
but
yeah
this.
The
the
something
much
deeper
like
explicit
destruction
is
seems
a
lot
trickier.
C
Well
another
another
example
that
I
think
is
interesting
is
whether
or
not
maps
slash
hash
map,
slash
dictionaries,
whatever
you
want
to
call
them
what's
permitted
in
the
keys
right
like
do
you
permit
right
now,
it's
permitted
in
ra
the
racket
cap
tp
stuff,
where
you
could
have
a
key
that
actually
is
a
list
of
strings
or
something
like
that
right
and
that's
permitted,
but
there's
no
sensible
way
for
my
understanding
for
that
to
be
represented
on
the
javascript
side
and
that's
an
example
of
something
that
we
might
at
least
have
to
figure
out
what
to
do
in
that
kind
of
scenario.
A
Well,
I
want
to
introduce
some
terminology
here:
the
in
from
the
javascript
side.
We've
got
a
notion
that
I'm
going
to
call
a
record,
it's
very
confusing
that
javascript
itself
calls
it
an
object,
but
I'm
going
to
call
it
a
record,
which
I
think,
maps
actually
quite
directly
to
what
I
remember
of
captain
proto,
which
is
it's
basically
a
past
by
copy
thing
of
string
named
fields
where
the,
where
the
values
of
those
fields,
the
value
of
each
field,
can
be.
A
But
the
names
of
the
fields
are
only
strengths,
and
so
that's
on
the
one
hand,
and
I
think
that's
what
you're
calling
what
chris
webber
is
calling
a
dictionary,
and
I
want
to
distinguish
that
from
maps
which
come
up
at
a
different
level,
abstraction
for
us
and
that's
an
arbitrary
mapping
from
comparable
objects
as
keys
to
values
where
the
keys
can
be
a
much
broader
set
of
things,
and
I
think
it's
important
to
keep
those
distinguished.
C
A
C
So
the
correspondence
I
I
think
we'd
have
to
add
a
type
because
what
the
correspondence
is
in
and
I'm
fine
with
doing
that,
the
correspondence
in
actually
we
have
a
thing
in
syrup.
That's
also
called
record.
The
difference
is
so.
This
is
actually
there's
another
interesting
topic
here,
which
is
about
now
it's
appearing
in
the
data
structure
sense,
but
this
also
appears
in
the
invocation
sense,
positional
arguments
versus
keyword,
arguments
which
is
really
that's,
that's
a
effectively
the
same
thing
but
as
in
terms
of
slots.
C
So,
like
the
so
the
we
we
have
the
notion
of
something
that
I've
added
to
syrup
and
it's
has
a
kind
of
loose
mapping
and
scheme,
but
not
something
that
I've
exported
over
the
wire,
that
of
something
called
structs,
basically
and
in
or
records
in,
but
they
use
positional
arguments
and
here
you're
using,
I
think,
string
based
arguments
and
I
think
that
it
might
just
be
worthwhile
to
have
effectively
keyword
records
and
positional
records
as
as
two
things
that
might
be
supported.
C
B
It's
important
to
make
a
distinction
between
records
where
the
the
names
of
the
fields
are
essentially
statically
known
versus
ones
like
arbitrary
maps
of
arbitrary
strings
that
aren't
known
in
advance
to
other
things
in
javascript.
Their
their
objects
are
used
in
both
ways,
and
it
would
have
completely
different
implications
for
what
you
do
in
cap.
Proto.
E
This
might
be
something
where
we
end
up
having
in
the
case
where
somebody
like
is
loosely
using
like
lists
as
keys
or
something
like
that
we
might
have
to
have
something
other
than
a
javascript
object
represent
that
and
that,
I
think,
might
end
up
being
a
sort
of
idiomatic
problem
rather
than
a
than
than
a
strict
interoperability
problem.
D
The
so
there
there
are
good
news
and
bad
news.
The
good
news
is
that,
as
far
as
agoric
is
concerned,
the
use
of
an
object
as
a
dictionary
would
strictly
be
in
the
struct
case
there,
where
they're
we
we
would
never
use
them
for
dynamically,
adding
and
removing
keys.
So
that
would
using
an
object
as
a
map
in
javascript
is
just
something
that
we
don't
need
to
support
in
the
in
the
distributed
semantics.
D
Having
a
map
that
has
and
and
even
in
the
map
case,
we
we
would
probably
constrain
it
to
an
immutable
version.
The
the
bad
news
is
that
this
is
where
that
watershed
between
two
idl
and
not
to
idl
comes
in
is
the.
If
we
did
have
an
idl,
there
would
be
much
fewer
semantic
problems
when
translating
across
when,
when
bridging
languages
that
have
that
are
that
use
these
object.
Destructs.
D
C
It's
actually
interesting
to
look
at
c
style
structs
as
kind
of
something
that
does
both
of
these,
where
people
write
down
their
code
as
in
terms
of
defining
the
c
style
struct,
they
initially
write
it
down
by
naming
each
one
of
those
fields.
It
ends
up
becoming
encoded
in
memory
in
a
very
efficient
way,
but
also
when
in
when
actually
constructing
one
in
code.
It's
done
by
arity
right,
it's
done
by
positional
arity.
So
it's
interesting
to
see
that
that
encompasses
all
of
those
types
of
things.
C
So
it
might
be
useful
to
recognize
that
we're
what
we're,
what
we're
kind
of
switching
between
a
bunch
of
types
of
things.
What
we're
really
semantically
thinking
about
is
something
akin
to
something:
that's
we're
all
kind
of
thinking
about
similar
to
c-style
structs,
even
if
represented
in
memory.
It's
not
actually
that
thing.
E
D
It
would
probably
be
satisfying,
for
the
purposes
of
a
protocol
for
dynamic
language,
to
dynamic
language,
to
do
something
similar
to
what
va
does
internally
for
hidden
classes,
where
the
description
is
transmitted
once,
but
and
and
then
thereafter
that
there
no
symbols
appear
in
instances,
but
that
it
is
more
complicated
to
like.
What's
what's
the
retention
scope
for
the
hidden
class
is
is
complicated,
yeah.
C
Yeah,
so
so
I
I
think
I'd
like
to
so
I
we
didn't
really.
I
don't
remember
if
we
set
this
for
an
hour,
I'm
guessing
we
did,
but
I
yeah
it
looks
like
we.
It
looks
like
we
did
so
I
want
to.
Actually
I
want
to
try
to
get
to
a
couple
of
things,
which
is,
I
think,
we've
laid
out
kind
of
what
some
of
the
core
differences
are.
C
Oh
and
the
final
difference
that
that
hasn't
been
discussed
yet
is
the
the
the
two
features
that
I
I
is
that
actually
probably
the
biggest
feature
is
the
handoff
stuff,
which
I
think
in
this
generation.
Goblins
is
the
only
one
that's
actually
implemented
handoffs.
C
C
C
So
with
all
of
that
acknowledged,
I
think
that
the
question
is:
what
do
we
want
to
do
from
here,
and
I
think
that
there's
probably
two
things
one.
We
have
a
set
of
issues
that
would
be
good
to
go
over.
We
don't
have
time
to
go
over
them
in
this
particular
meeting
two.
C
It
would
be
the
biggest
next
step
from
my
perspective,
and
I
think
it's
easy
to
misinterpret
what
I'm
saying
here
as
something
other
than
what
I'm
actually
saying
is
a
demonstration
of
interoperability
between
two
of
these
things,
the
fastest
of
which
I
think
we're
going
to
get
by
being
between
some
code
in
a
gorek
style
ecosystem
and
some
code
and
goblins
of
style
system,
ecosystem
and
them
talking
to
each
other
and
doing
something
interesting.
C
You
know
even
just
a
hello
world
across
them
and
the
main
reason
why
I'm
arguing
that
is
that
my
experience
is
it's
easier
to
feel
very
disconnected
as
in
terms
of
whether
or
not
this
is
even
possible
before
a
demonstration
of
something
that
feels
concrete
and
actual
between
between
two
things
from
an
interoperability
perspective,
once
we've
done
that
it
might
actually
help
us
mentally,
even
if
we're
not
going
to
commit
to
that
being
the
direction
of
the
way
we're
doing
interoperability
as
in
terms
of
a
mental
starting
point
around
which
the
other
kind
of
issues
can
end
up
kind
of.
E
E
If
I
were
to
do
it
and
then
it's
a
pretty
simple
matter
of
just
writing
a
membrane
and
that
doesn't
give
you
in
calling
into
captain
p
from
the
other
side,
but
it
does
give
you
the
the
direction
of
calling
into
goblins
from
captain
p.
E
So
that's
a
pretty
quick
way
for
us
to
get
like
some
ability
to
play
with
the
captain
p
other
stuff
direction,
the
other
the
rest
of
it
involves
implementing
introspection
which
we
haven't
done
yet
so
that's
more
work,
but
I
do
think
we
can
get
kevin
p
on
the
in
on
this
early
demo
without
a
dramatic
amount,
more
work.
D
Yeah,
I
certainly
think
that
that's
a
viable
exercise
it
would,
it
would
certainly
be
viable
for
us
to
come
up
with.
D
With
an
I,
with
a
captain,
proto
idl,
that
is,
that
describes
the
same
bank
of
types
that
we
intend
to
be
interoperable
between
agorak
and
goblins,
but
it,
but
it
has
the
shelf
life
of
that
project.
Is
that
it?
It
really
does
end
at
talking
in,
but
never,
and
it
would
never
never
be
useful
for
talking
out.
D
Or
but
but
that's
I
mean
compare
that
to
what
protobuf3
does
for
jason.
Thankfully
protobuffen
protobuf3
at
least
has
a
well
thought
out:
mapping
between
an
arbitrary
protobuf
idl
and
an
adjacent
representation
of
it,
but
then
it
also
has.
It
also
has
some
intrinsic
problems
about
the
about
the
design
decisions
that
exist
to
the
left
and
the
right
of.
Do
you
have
an
idl
right?
D
If
you,
if
you
do,
have
an
idl,
it
makes
sense
for
enumerations
to
be
represented
numerically
on
the
wire,
and
if
you
do
not
have
an
idl
it
doesn't,
it
makes
no
sense
for
or
for
field
names
and
enumerations
to
be
represented
numerically
on
the
wire.
They
must
be
strings
and-
and
therein
lies
a
missed
opportunity.
I
think
that
there's
a
possibility
that
that
the
idl
can
be
it's
that
when
an
idl
is
that
when
you,
when
you're
writing
between
agorak
and
goblins,
there
is
an
imaginary
ideal.
D
It's
not
ideal
free,
it's
just
imaginary
and
unstated
it's
tacit,
and
if
you
were
to
state
that
idl,
it
would
allow
you
to
translate
seamlessly
between
the
the
symbolicated
protocol
that
agora
can
goblins
use
to
talk
amongst
themselves
to
a
desymbolicated
protocol.
D
That's
you
that
can
be
used
to
talk
to
languages
that
prefer
natively
to
have
code
generated
clients
that
that
model
these
things
numerically,
and
I
think
that
there
is
a
possibility
of
a
one-to-one
translation
across
that
boundary
in
the
cases
where
having
an
idl
is
useful,
it
just
wouldn't
happen
to
be
protobuff's
idl.
I
think.
B
So
definitely
to
to
translate
to
bridge
between
captain
proto
and
a
dynamically
typed
language.
You
must
have
a
schema
that
represents
all
the
things
you
actually
want
to
be
able
to
communicate.
So
it
kind
of
forces
you
to
be
statically
typed,
but
once
you
have
that,
I
think
you
can
translate
both
ways.
I
don't
think
translating
one
way
is
harder
than
translating
the
other
way
we
have,
for
instance,
just
like
proto3
does
a
cap
proto
has
a
way
of
translating
structs
into
java
or
into
json
and
back.
B
B
Language
or
representation.
The
interesting
thing
here,
though,
is
when
you're
going
between
two
dynamically
typed
languages.
Do
you
need
a
schema
to
be
able
to
do
that
translation
reasonably?
I
think
that's
a
really
interesting
question
and
it
probably
depends
on
how
close
they
are
to
each
other.
A
So
between
scheme
and
javascript,
which
was
stylistically
quite
different
so
far,
it
has
not
looked
like.
We
need
a
scheme.
F
I
will
say
that,
in
my
experience
having
a
schema
of
some
sort
allowed
us
to
discover
problems
earlier
when
somebody
was
sending
something
unexpected
discovering
it
on
the
sender
side
rather
than
when
the
receiver
emits
an
unknown
method,
message
was
sometimes
convenient.
C
So
can
I
can
I
jump
in
here
with
one
thing
that
I
think
has
been
useful
about
the
kind
of
aside
syrup
conversation
that's
been
happening
recently
and
especially
with
calbert,
having
both
cupboard
and
balder
having
implemented
their
own
versions
of
syrup
in
the
last
couple
of
weeks
and
calbert's
implementation
of
syrup
actually
taking
some
departures
and
that
that
were
kind
of
departures
that
are
now
up
for
discussion.
I
think
it's
actually
forced
us
to
look
at
if
we
were
going
to
represent.
C
C
The
the
I
think
that
the
big
part
of
so
I
think,
if
we
can
write
down,
we
have
two
different
issues,
one
of
them
for
writing
down
the
abstract
kind
of
core
types
of,
let's
say
things
that
are
invoked
going
back
and
forth
like
what
are
the
arguments
passed
to
different
capabilities
is
one
thing
and
then
the
other
one
is
what
are
the
effectively
high
level
types
of
the
messages
representing
or
not
the
messages.
C
The
types
representing
the
the
cap
tp
operations,
which
balder
has
put
in
issue,
one
a
a
list
of
kind
of
the
abn
f
that
he
was
anticipating
from
based
on
looking
at.
You
know
these
implementations.
So
I
think
if
we,
if
we
take
the
abnf
and
what
are
the
core
types
as
a
starting
point
that
might
that
might
actually
and
actually
if
we
can
just
actually
do
the
entire
thing
as
an
abnf,
then
that
actually
might
be
sufficient.
C
So,
in
a
I
mean
the
difference
between
a
b
and
f
and
an
idl
are
obviously
not
huge,
but
the
the
the
difference
is
is
that
I
think
cap
and
proto,
maybe
inserts
very
strongly
a
idea
of
moving
from
something.
That's
like
an
abnf
down
to
a
particular
arrangement
of
bytes
and
kind
of
taking
a
step
back
from
that
and
really
paying
attention
from
the
abnf
really
emphasizing
the
a
of
abstraction
might
be
youthful
to
some
degree.
C
B
So
I
want
to
make
a
quick
comment
here
to
note
that
in
cloudflare
workers,
when
we
start
having
the
ability
to
do
rpc
between
workers,
we
will
almost
certainly
base
it
on
what's
called
structured
clone
in
in
the
web
standards
world
because
yeah,
I
know
it
it
it's
it's
ugly,
but
it
is
a
thing.
That's
well
defined
and
we're
gonna
probably
use
v8
serialization
to
implement
it,
because
it's
already
there
and
that's
a
really
easy
way
for
us
to
say.
B
Okay,
you
can
pass
a
relatively
arbitrary
javascript
values
between
between
servers.
B
C
Okay,
yeah,
that
seems
it
seems
so
so
that
that
makes
me
kind
of
so
that
actually
seems
like
a
highlighting
of
the
thing.
That's
made
me
most
nervous
about
cap
and
proto
so
far,
which
is
that
it's
I've
tried
looking
for
some
sort
of
specification
about
what
the
memory
layout
is
and
stuff
like
that.
That's
and
it's
it.
It
hasn't
really
seemed
to
me,
like
I've,
been
able
to
find
a
clear
document
and
some
amount
of
conversation
with
ian.
C
Sure
sure
the
the
the
the
point
here
that
I'm
trying
to
make
is
I
I
I.
What
I
would
really
like
to
do
is
avoid
doing
anything
that
is
too
heavily
influenced
by
the
guts
of
a
particular
low-level
implementation.
Like
that,
that
that
would
make
me
very
nervous.
I'd
like
to
have
something.
That's
very
well
described
as
in
terms
of
being
implementable
by
somebody
starting
from
kind
of
a
greenfield
approach,
structured.
B
Clone
is
part
of
web
standards.
It
is
described
abstractly
in
web
standards.
All
browsers
support
it.
That's
why
I
brought
it
up
is
because
it
is.
It
is
something
that
describes
semantics
without
describing
the
actual
serialization
and
each
browser
has
its
own
serialization.
It
uses
to
represent
the
same
semantics.
It's
used
for
things
like
post
message
between
frames
and
for
local
storage.
I
think.
E
But
this
is
also
conceptually
separate
from
the
and
proto
wire
and
for
wire
format
is
absolutely
well
documented
and
I
can
send
you
the
link
to
the
encoding
documentation
if
you've
not
found
it.
You
know
I
have.
I
have
written
this
from
scratch
without
having
looked
at
at
any
existing
implementation.
I
can.
I
can
testify
that
the
wiring
coding
is
well
documented
and
unambiguous.
Okay,.
C
Good,
I'm
glad
to
be
wrong
about
that
particular
thing.
My
main,
my
main
point
here
is:
I
would
I'm
worried
that
the
serialization
discussion
in
general
ends
up
getting
a
certain
amount
of
over
focus.
It's
very
easy.
It's
kind
of
along
with
naming
things.
C
Serialization
is
kind
of
the
ultimate
bike
shed
right
like
and
it's
it's
kind
of
the
thing
that,
from
my
perspective,
should
be
the
easiest
thing
to
swap
out,
and
I'm
worried
is
also
the
easiest
thing
to
suck
up
all
the
time,
so
so
that
that's
just
my
source
of
nervousness
for
for
present
and
future
meetings.
D
I
could
propose
to
take
a
step
toward
kenton
that
when
we
have
a
figure,
when
we
figure
out
what
the
subset
of
reflectable
types
between
goblins
and
agora
and
possibly
others
is,
it
may
transpire
that
that
maps
closely
to
what
structure
clone
can
do,
but
it
but
structured
clone,
does
raise
interesting
questions
about
ibids
in
particular
on.
D
So
I
think
so.
I
think
that
there's
there's
an
open,
open,
high
level
design
question
like
do
we
support
ibids
and
what
the
scope
of
ibids
would
be
because
structure
clone,
I
believe,
does
allow
for
you
to
import
non-tree
but
dag
type
structures
to
be
transmitted,
and
I
think
that
that
is
the
high
level
design
issue.
I
think
agoric
is
moving
very
far
very
far
away
from
very
quickly.
I.
A
Think
we
started
off
being
able
to
encode
where
the
past
my
copy
part
of
the
what
was
being
serialized
could
actually
not
only
have
dags,
but
it
could
have
cycles,
and
we
are
moving
completely
away
from
that
to
say
that
the
pass
by
copy
is
def
is
only
tree
structures
and
we're
very
happy
with
that.
B
Yeah,
I
I
agree
with
that.
That's
the
philosophy
that
captain
proto
has
always
had
too
is
like.
If
people
ask
all
the
time
for
the
ability
to
have
dags
or
even
cycles-
and
I
say
well,
look
here's
all
the
things
we
can't
do
anymore.
If
we
do
that,
you
can't
take
one
part
of
a
message
and
copy
it
into
another
message
because
it
might
pull.
You
know
everything
from
the
original
message
like
it
gets
impossible
to
deal
with
right.
E
D
I'll
catch
up
with
you
all
next
time,
may
I
suggest
chris
that
the
shape
of
the
conversation
like
well,
we
should
probably
for
one
time
box
this
conversation
and
also.
I
think
that
we
should
have
a
strong
notion
of
what
the
schedule
of
the
conversation
is
and
towards
the
beginning
of
the
conversation.
D
I
think
that,
like
like
you're
trying
to
emphasize
what
should
we
talk
about
at
each
stage
at
the
earliest
stage,
I
think
that
what
we
should
come
up
with
is
first,
first
and
foremost,
is
what
are
the
design
goals
and
non-goals
and
come
up
with
an
agreement
on
that
before
we
step
into
anything
else,
and
then
the
next
after
that
is
what
are,
what
are
the
distributed
semantics?
C
So
so
my
my
general,
so
I
think
that
this
meeting
actually
went
much
more
productively
and
much
more
usefully
than
I
even
anticipated,
and
those
are
good
steps
now
that
we've
seen
that
the
first
meeting
went
so
well
too.
Right,
like,
as
in
terms
of
I
think,
this
meeting
kind
of
got
scheduled
in
a
very
ad
hoc
way,
and
thank
you
again
ian
for
suggesting
that
we
do
it,
and
even
the
oh
cap
and
document
and
everything
and
everybody's
starting
talking
about
implementation,
stuff
and
everything
like
that.
C
In
many
ways,
this
conversation
has
moved
much
faster
than
I
anticipated,
and
I
actually
think
that
that's
a
a
good
sign,
but
it
is
important
now
that
we
realize
that
things
are
moving
quickly,
that
they
don't
get
moved
quickly
in
a
way
that
gets
derailed,
and-
and
so
I
think
that
your
your
cowbert
suggestions
are
good
and
we
should
try
to
capture
them
so
that
we
do
another.
One
of
I
would
like
to
do
another
one
of
these
and
try
to
actually
capture
those
things
fast.
C
I
would
suggest
we
not
try
to
pull
in
other
projects
too
soon
on
this,
because
one
of
the
biggest
mistakes
that
I
think
we
could
make
is-
and
I
think
this
happened-
and
the
decentralized
identifiers
work
in
some
ways-
and
I
guess
it's
publicly
recorded
so
now-
I'm
on
record
of
having
said
that,
but
oh
well,
it's
fine
is
that
it
would
be
much
safer
and
easier
to
have
a
a
small
number
of
talking
to
each
other
implementations
earlier
than
later
in
this
process,
because
it
reduces
the
amount
of
space
of
people
coming
in
and
kind
of
upending.
D
D
We
want
to
reach
us
with
a
successful
and
and
workable
solution
at
the
end
of
this,
and
if
the
scope
is
every,
if,
if
the
scope
is
communication
among
every
language
and
et
cetera,
et
cetera
that
each
each
increase
increases
probability
that
it
won't
come
to
an
end,
but
also
the
if
the
scope
is
too
small,
what
we
get
at
the
end
might
not
be
useful.
D
A
I'm
confident
that,
with
these
three
projects
represent
three
sufficiently
different
points
in
the
design
spins
that,
by
the
time
we've
brought
before.
E
B
A
Okay,
okay,
okay,
so
with
with
those,
then
I
think
we've
got
enough
pressures
on
us
in
to
accommodate
things
that
are
sufficiently
architecturally
different
while
having
the
abstract
idea
in
common
that
by
the
time
we've.
If
we
can
bridge
between
these
four,
I'm
not
worried
about
the
fact
that
that
other
possibilities
didn't
come
in
until
after
that.
D
Okay,
I
agree-
let's,
let's
put
that
in
the
notes
that
the
objective
of
this
this
story
arc
is
for
these
specific
four
things
to
be
able
to
talk
to
each
other.
C
Okay,
good
so
calvert,
since
you
raised
the
idea
of
this
kind
of
pattern
for
locking
things
down,
could
I
suggest
that
you
and
I
take
a
small
amount
of
time
to
make
to
try
to
actually
capture
that
before
we
set
up
the
next
meeting
and
to
try
to
kind
of-
and
you
know,
and
actually
I
think
that
you
I
would
even
be
willing
to
hand
some
of
that
work
over
to
you,
as
in
terms
of
saying
hurting
the
cowberts
and
hurting
the
hurting
the
cows,
whatever
whatever
the
joke
would
be.
C
The
sorry
that
was
a
horrible.
I've
been
doing
a
pretty
good
job
with
puns
recently,
and
I
think
I
I
might
have
jumped
the
jump,
the
shark
or
the
cow
on
this
one.
You're.
D
C
Okay,
one
once
light
quick
question
since
we,
since
both
since
you
did
do
an
implementation
of
the
syrup
stuff
over
this
last
week,
would
anybody
be
troubled
by
me:
crea
actually
moving
the
syrup
repository
over
to
under
the
oak
cap
in
space?
Not
so
it
would
be
ocap
and
slash
syrup
not
saying
that
we're
committing
to
that,
but
just
that
cupboard
and
I
have
an
easier
place
to
be
able
to
kind
of
debate
what's
core
there.
A
C
Okay,
good
all
right,
then
I'll.
Do
that
today,
all
right
great!
Well,
then
thank
ever
thanks,
everybody
and
mark.
If
you
could,
let
me
know
when
this
video
goes
public.
That
would
be
great.