►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2019-08-12
Description
A weekly meeting to sync up on all IPLD (https://ipld.io) related topics. It's open for everyone and recorded. https://github.com/ipld/team-mgmt
A
Welcome
everyone
to
this
week's
I
thought
the
sink:
reading
it's
August
12
2019
and
it's
the
weekly
deaf
meeting
for
the
iCarly
team
and
today
we
plan
to
go
over
the
specs
repo
and
go
over
the
stuff.
And
should
we
start
with
this
and
then
see
if
we
have
in
the
end
time
for
other
things
or
should
be
first,
two
other
things.
B
A
A
The
krupa
token
yeah
all
right
so
yeah
I
start
with
myself
so
and
this
week
past
week,
I
did
most
of
the
time
most
of
the
my
time,
I
spent
on
trace
a
if
s
stuff,
because
he
I
tried
to
integrate
IP
LD.
The
new
iPad
me
version
with
mayor
stuff,
and
they
have
a
few
problems
with
acing
await
stuff,
but
yeah.
A
C
Think
everything
I
did
was
boring
in
a
good
way.
Most
of
Hannah's
branches
about
selectors
are
merged
to
master
now,
and
they
just
as
far
as
I,
know
work.
So
that's
awesome.
I
need
up
continue
to
go
deep
on
a
performance.
Rabbit
hole
this
week
that
was
kind
of
spurred
by
last
week
and
I
tried
to
fix
a
small
comment
in
one
line
of
one
piece
of
documentation
and
trying
to
figure
out
what
was
really
going
on
there.
C
It
took
me
several
days
and
so
I
wrote
a
really
long
book
about
performance,
and
hopefully
this
is
going
to
be
useful
information
in
the
future.
So
anybody
else
writing
ago
wants
to
learn
about
how
the
GC
feels
about
fades.
Little
egg
for
you
and
a
bunch
of
naming
every
factors
have
landed
so
rod
you
might
have
to
apply
said
to
any
work-in-progress
you've
got,
but
it
should
be
easy.
It's
just
textual
naming
change,
that's
about
it.
D
Okay,
so
more
go
learning
focused
on
getting
my
test.
Fixture
archive
format,
thing
working,
so
I've
got
my
JavaScript
and
go
versions
are
done
and
published
and
yeah
you
can
pack
in
all
sorts
of
arbitrary
blocks
into
a
single
file
and
store
them
as
test
fixtures,
which
is
really
nice
so
confirm
that
it's
working
same
data
on
both
I
was
fixing
a
serialization
bug.
You
found
in
Dague
PB
I'm
along
the
way,
so
that's
poor
requests,
156,
Volker
and
I
having
conversation
in
there.
B
B
It
lists
like
every
feature
that
we've
talked
about
free
mixes,
v2
and
all
the
links
that
I
could
find
to
prior
discussions
and
stuff
like
that,
and
then
we've
separated
that
into
a
couple
buckets
of
work
items.
One
is
an
update
to
UNIX
51,
so
I'm
an
issue
open
right
now
for
a
discussion
that
will
turn
into
a
PR
2.
B
So,
tucked
I
updated
sort
of
a
bunch
of
different
stakeholders
on
all
the
stuff,
definitely
working
on
on
the
current
status.
But
if
the
research
project
and
a
lot
of
the
projects
that
people
depend
on
got
a
lot
of
feedback,
that
will
be
really
helpful
for
future
meetings,
including
for
all
of
y'all.
B
When
you
have
sort
of
broad
questions
or
stuff
that
you
are
struggling
with,
if
you
can
service
those
to
me,
I
can
actually
work
them
into
questions
and
things
that
that
group
can
discuss,
and
then
we
can
also
get
feedback
from
them
and
as
that
grows
to
include
external
stakeholders.
That'll
be
I.
Think
more
interesting,
because
a
lot
of
what
we
work
on
doesn't
get
enough
input
from
a
different
stakeholders
with
different.
B
It's
more
like
what
are
we
struggling
with
right
now
and
then
they
may
have
input
or
advice
on
that
right.
So
some
of
the
stuff
that
I
surfaced
was
just
you
know.
We,
we
are
constantly
struggling
with
how
the
best
message
things
and
finding
the
right
language
to
describe
things
and
even
a
line
within
each
other.
B
I
talked
a
bit
about
some
of
the
stuff
that
rod
has
been
doing
to
sort
of
figure
out
like
what
are
the,
how
to
quantify
the
different
sort
of
performance
cases
in
these
multi
block
data
structures,
and
then
what
levers
we
can
pull
to
manipulate
them
and
because
I
know
that
some
of
the
people
in
that
call
have
thought
about
that
for
a
while
as
well.
So
those
are
the
things
that
I
said,
but.
E
B
A
B
Yeah
I've
been
thinking
about
the
fastest
way
to
do
this
and
I
think
the
fastest
way
is
that
if
one
of
us
all
do
it,
I
I
will
share
my
screen.
But
someone
else
should
take
notes
on
what
we
want
to
actually
do
to
each
issue
and
then
we'll
do
them
after
the
meeting,
so
that
we're
not
like
waiting
on
people
to
type
in
the
screencast.
So
if
somebody
else
can
take
those
detailed
notes,
then
I
can
share
my
screen
and
we
can.
A
B
Yeah
I
think
that
we
can
maybe
just
decide
to
close
all
of
those
like
I.
Don't
I,
don't
see
anything
in
the
backlog
that
we
shouldn't.
That
isn't
just
like
a
conversation
that
we
need
for
posterity.
That
isn't
gonna.
Have
anything
happen
to
it
until
we
create
a
new
issue
about
it.
Does
anybody
disagree
with
that.
A
B
Aversion
to
yeah
it's
quite
it's
quite
difficult
to
even
contextualize
a
lot
of
these
ones
that
are
pre
old,
I,
think
anything
that,
like
a
stale
bot,
would
have
already
closed.
We
should
just
go
through
and
close
so
I
think
all
of
the
stuff
that
was
tagged
as
backlog.
I
think
that
we
can
close
for
now
and
just
say,
like
I'll,
write
up
a
note
about
it,
so
basically
49
and
earlier
issues
we
are
closing.
Let's
just
say
that.
F
A
F
A
C
C
D
B
D
G
G
So
there
long
as
my
questions
around
like
seek
ability
and
search
ability
and
random
acts,
all
these
things,
cars
and
also
they
can
easy.
They
shimmer,
like
I,
think
that
version
is
well.
The
first
version
was
October.
Sorry
literally
leaves
to
tar
file.
If
the
next
version
hat
was
slightly
more
special
case
and
used,
protobufs
I
think
no
photo
Searcy
working,
River
yeah,
but
yeah
it's
good.
Second,
they
like
it's
complicated
and
not
that
high
priority.
B
A
C
Implementations
exist
and
they're
moderately
well
specified
for
what
they
are,
but
they
also
haven't
been
super
ratified
or
like
super
I.
Don't
think,
there's
any
reason
to
call
them
special
or
unique,
or
if
the
only
one
right.
So
it
seems
like
something
we
could
put
in
a
general
bucket
of
links
to
related
interesting
projects.
You
should
check
out.
Maybe
if
you
have
time
yeah.
G
Eventually,
we
wanted
a
speck
on
this
and
but
then
like
we
get,
we
handle
those
questions.
We
also
pressure
on
the
compression,
because
actually
you
want
to
compress
different
watts
but
different,
like
with
different
compression
functions,
and
then
you
want
it
to
be
able
to
like
get
rid
of
like
say
it's
like
that.
All
these
good
questions
use
rabbit
hole
of
insanity,
okay,
yeah.
A
B
We
can
close
and
I
I'm
going
to
assume
that
this
the
feedback
to
the
extent
that
it
was
turned
into
anything
actionable
made
it
into
one
of
the
other,
select
respects
that
we
have.
Oh,
yes,
yes,
there
were
a
lot
of
selector
specs
open
at
one
point
in
time,
so
I'm
not
surprised
that
one
was
hanging
so
close
104.
Basically,
I
should
do
basic
specs
for
hampt.
D
D
B
G
B
G
B
G
G
G
Saying
like
are
we
good
switch
not
going
to
switch?
That's
a
good
point.
We
should
use
one,
but
we
shouldn't,
because
this
is
a
discussion
point
really.
We
have
to
elicit
say:
hey
facwidein.
We
have
this
a
thing
over
here.
Here's
the
spec
also
maybe
converting
the
current
petition.
To
this.
You
think
I
mean.
B
Okay,
it's
just
sort
of
point
of
process,
so
they're
they're
possible
for
deciding
whether
or
not
the
switch
to
the
other
one
is
is
outside
of
like
what
we
necessarily
do
with
the
spec.
So
they
made
it
like
they're
already
so
they're
very
active
in
the
other
spec
right
now
they
are
talking
about
switching
to
it.
They
may
switch
to
it.
They
may
not
I,
think
they're
probably
actually
will,
but.
G
B
A
Want
to
keep
it
around,
what
we
could
do
is
like
what
we
saw.
I
did
with
the.
So
when
you
come
to
the
graph
sing,
a
PRS
I
did
the
ability
archive
them,
so
we
can
easily
talk
about
how
to
archive
it.
When
we
saw
the
graph
sync
PR
twist,
you
can
see
what
I
did
with
there
basically
decide.
I
want
to
do
the
same
thing:
okay,.
B
B
A
C
A
B
A
B
I
think
I.
Think
next
step
is
to
archive
it
into
the
design
history
somewhere
close
this
out
and
then
depending
like
sometime
in
the
future
when
they
decide
which
one
that
they're
gonna
be
on.
We
may
end
up
pulling
this
back
out
and
maybe
like
sending
it
to
their
repo
so
that
they
have
access
to
it
in
an
easier
format.
B
We
don't
have
to
ham
specs
open,
what's
great
grab,
sync
response
metadata.
Is
this
the
one
that
you
were
talking
about
poker
versus
another
one?
No.
B
E
C
C
G
G
B
Okay,
I
just.
G
G
B
A
B
A
To
my
plan,
most
basically
doing
well
like
going
over
these
and
see
what
would
we
do
with
it
like
I?
Just
do
it,
so
you
don't
have
a
clue
what
like
I
doing
Oh
what
they
about
so
I
will
just
like
yeah
go
over
them
in
what
we
do
with
it.
So
just
yeah.
My
ex
item
is
to
make
sure
that
something's
happening.
B
C
C
D
So
that
this
was
this
was
I
just
wanted
to
try
and
make
the
hierarchy
a
bit
more
obvious
here
and
and
then,
but
but
Eric
wants
to
pull
it
back
up
again.
I
just
I
just
would
like
these
things
to
be
located
in
a
logical
place
for
the
user
to
find
them
and
Eric
wants
to
put
them
in
a
concepts
directory.
I
want
there
to
not
be
a
concepts
directory
because
I'd
like
these
things
to
be
organized
nicely,
because
it's
gonna
just
explode,
but
it's
not
a
strong
strongly
felt
opinion.
D
H
Yeah
I.
C
B
B
C
C
Just
different
constraints
around
them
and
advanced
data
layout
seem
to
also
be
node
to
node,
just
with
more
stuff
in
the
middle
and
then
codecs
are
not.
That
codecs
are
something
the
heck
else
to
note
and
vice
versa.
So
this
might
provide
some
hints
about
the
order
in
which
we
introduce
some
things.
A
And
it
should
be
like
should
be
like.
Should
we
discuss
this
right
now
so
because,
like
I,
would
rather
think
that
if
we
finally
have
like
all
the
RPI,
Oscars
and
HSN
or
whatever
base,
we
know
what
will
be
really
in
the
repository.
And
then
we
can
decide
to
look
at
everything
and
decide
like
how,
where
to
put
it,
because
yeah.
A
B
That's
why
we're
cueing
them
all
up
and
right
now
right,
but
my
remember
I'm,
remembering
all
of
the
different
current
threads
and
issues
in
the
PRS
and
a
lot
of
them
are
naming
and
related.
I
know
that
we
talk,
so
the
layer
cake
is
confusing
in
terms
of
teaching
people
I
feel
deep,
but
it
is
still
useful
in
terms
of
organizing
a
lot
of
our
stuff.
One
thing
that
I'm
noticing
here,
though,
is
it
like
from
block
layer
and
data
model
layer.
B
It
helps
a
lot
with
the
organizing
to
have
those
in
a
directory
for
everything,
above
that
we
effectively
have
just
been
putting
into
the
top
level
so
like
schemas
and
selectors,
and
like
we
I
think.
What
we
should
do
here
is
just
take
everything:
that's
in
the
schema
layer
directory
and
move
it
up,
so
schemas
obviously
was
already
moved
up,
and
this
is
just
duplicate
and
confusing,
and
then
data
structures
can
just
go
to
the
top
level.
It
is
very
like
that
is
self-explanatory.
C
Mostly
agree
except
I'm,
betting
rods,
gonna
say
that's
too
many
things
up
to
top
levels.
It's
the
explosion
and,
but
so
I
agree
otherwise,
I
wonder
if
maybe
it
would
work
out
to
take
all
of
those
things
and
put
them
in
a
dry
trip
which
I
cannot
imagine
the
name,
but
just
everything
that
you
could
not
read
about
until
after
you
have
finished
reading
about
data
that
directory
right.
B
B
B
If
you
sum
up
everything
that
I
just
said
we're
still
down
into
record
from
where
we
are
now,
because
this
only
has
one
directory
in
it
that
will
go
out,
schemas
will
get
consolidated,
we're
getting,
we
would
get
rid
of
the
schema
layer
directory
and
concepts,
would
move
them
to
design
so
we're
still
down
the
directory
and
I.
Think
it's
clear,
I'm
gonna
go
with
that.
Put
an
action
and
I'm
done
for
me
to
do
that.
Okay,
I
think
we're
good
there
all
right.
Okay,
so.
D
B
Yeah,
we're
gonna
collapse,
schema
layer
directory
okay,
so
this
PR
was
open
just
to
talk
about
what
it
would
take
to
get
rid
of
slashes
and
reserved
key.
It
is
not
necessarily
something
that
we
should
do
so.
I
think
that
what
we
should
do
with
this
is
the
same
thing
that
we've
been
doing
with
focus
other
scripts,
which
is
to
create
an
archive
file
and
put
it
in
design.
History,
yeah.
E
B
G
B
D
Show
this
there's
just
there's
one
major
outstanding
item
that
I
just
haven't
got
to
encode,
which
is
removing
the
bit
with
property
in
inferring
it
from
the
size
of
the
map
by
an
array,
so
I'd
like
to
do
that
and
reflect
it
in
the
in
the
doc.
But
aside
from
that,
I
think
it's
it's
pretty
pretty
good!
You.
C
D
This
boss
array
case
I,
don't
particularly
like
it,
so
our
coin
has
a
use
for
this.
So
Falcone's
gonna
need
a
sparse
array,
and
this
will
serve
that
purpose.
That,
in
theory,
I
think
it's
gonna
get
unbalanced
to
quickly
and
easily,
but
it
deserves
to
be
specked
out
and
actually
experimented
on
its
own
okay.
B
Okay,
so
a
couple
things
that
need
to
happen,
one
of
the
bit
should
move
into
design
with
an
alternate
with
a
name
that
has
a
since
it's
really
early
and
there's
no
implementation
that
we
know
of
so
it
just
needs
to
like
get
pointed
into
the
directory.
And
then,
since
it's
experimental
and
there
isn't
imitation,
yet
we
can
just
Mergent.
B
D
B
H
D
B
B
E
C
C
B
C
B
A
E
A
A
B
B
H
B
A
D
B
Primitives
proposal
this
is
out
of
date-
I
mean
this
all
informed.
What
went
in,
but
this
is
like
pretty
old,
okay,
so
number
56.
We
should
close
and
then
so
for
the
next
ones
that
we've
been
taking
their
son
just
right
that
will
close
them
and
then
I'll
go
in
and
add
the
comments
later
on.
While
we're
closing
the
central
typing
coding
information.
A
B
A
B
B
Long
string,
keys,
Eric,
you
have
opinions
about
this
time.
String
key
is
I,
think
that
we've
resolved
non
string
keys
in
a
couple
places
right
so
I
mean.
C
B
B
B
B
C
C
With
the
whole
time
in
schema,
design
is
that,
if
that
you
can
actually
have
different
kinds
of
boy,
let
me
try
not
to
get
tongue-tied
here.
You
can
use
any
type
you
want
as
the
map
key
type,
and
it
can
actually
be
almost
any
kind.
You
want
at
the
type
level
as
long
as
the
representation
kind
is
straight.
A
C
H
B
B
C
C
A
C
D
He's
he's
a
concrete
example:
I
was
saying
in
that
the
in
the
amp'd
spec
discussion
that
I
think
that
a
better
way
to
handle
sparse
arrays
in
the
future
would
be
to
use,
ordered
maps
and
then
use
the
integer
keys
or
ordered
maps,
so
that
then,
when
we
have
a
dust
and
an
ordered
map
data
structure,
then
it
will
be
better
at
balancing
than
an
int
would
for
arbitrary
spaz
to
race.
So
you
know
in
there's:
AB
is
non
string
key
for
a
map.
D
A
A
E
A
C
So
so
rod
you'll,
probably
now
under
and
my
issues
around
that
this
topic.
So
if
I
try
to
figure
out
how
to
implement
non
string
keys
in
the
go
stuff,
none
of
the
existing
accessor
methods
that
I
have
around
maps
work
and
if
we
try
to
implement
sort
of
a
union
type
in
go
that
would
be
either
string
or
integer
and
use
it
for
these
accessor
methods
as
their
parameter
or
for
the
iterators
or
anywhere
else.
Where
this
touches,
we
don't
have
zero
cost
Union
abstractions
and
go
it's
not
rust,
go
actually
sucks.
C
A
So
should
we
prep
say
so:
we
define
that
map's
map
kinds
have
only
strings
and
we
specify
it
and
then
we
can
close
the
CPU
and
in
the
future
at
one
point,
if
we
need
it
for
whatever
reason,
then
we
will
see
what
like
how
it
fits
in
and
it's
like
how
long
non
string
keys
fit
in
and
if
we
really
need
them
or
yeah.
We.
C
B
So
it's
it's
just
really
hard
to
figure
out
how
how
you
would
go
about
doing
that
so
you're
off
in
like
advanced
layout,
composite
land.
The
moment
you
want
to
do
this,
so
it's
not
that
we
won't
ever
support
something
like
this
in
the
future.
It's
like
that's
the
layer
that
it's
gonna
have
to
live
that
and
we
aren't
currently
working
at
doing
that.
Yeah.
C
A
So
basically
you
can
delete.
Do
it
like
so
that
I
pretty
data
model
is
the
least
you
can
do
pretty
general
things
like
I,
don't
like
like
on
every
permutation.
But
if
you
go
into
non
string
keys
you
end
up
with
it's
so
specialized
that
yeah,
you
probably
don't
yeah
yeah
I
can
use
easily
other
limitations
because
it's
so
application
specific
yeah,
I,
really.
Okay,.
B
E
B
E
A
F
D
B
C
E
H
B
C
C
C
Since
then,
I've
tried
to
talk
about
this
problem
with
a
couple
of
different
people
like
yeah,
there's
something
and
someone
like
not
physically
body-slammed
me,
but
like
the
argumented
equivalent
of
it
and
said
why,
like
just
literally,
why
character
encoding?
Why
not
just
shut
up
and
treat
it
like
bites?
Because
you
cannot
win
character,
encoding
and
I
was
unable
to
answer
that
and
then.
H
B
C
B
C
B
Okay,
yeah,
so
all
right,
coming
back
to
this,
we'll
close
this
by
turning
it
into
a
design
history,
doc
I,
think
that,
like
on
the
to-do
list
somewhere
is,
is
a
path
spec
doc.
But
it
is
it's
more
perilous
than
I
think
anyone
wants
to
admit
that
it
is
it's
not
clear
who
the
audience
is
and
who
implements
the
path
back
like
that's.
That's
the
problem
that
I
have
every
time
that
I
sit
down
to
work
on
it.
B
That's
the
issue
because,
like
with,
if
you're
thinking
about
like
Earl
specs,
the
the
person
who
gives
you
the
Earl
is
like
a
user
who
hands
you
a
string
and
the
rules
are
about
encoding
that
into
things
that
don't
lose
a
lot
of
precision
this
like
when
we're
talking
about
it.
It's
very
unclear
like
who
would
be
responsible
for
encoding
these
and
at
what
time,
and
we
don't
have
like
we're
going
to
end
up
with
a
lot
of
double
encoding
if
we
don't
define
that
before
you're
in
Quebec,
so
so.
B
Like
yeah,
we've
been
doing
a
bunch
of
work
and
intuiting.
What
paths
should
do?
I
think
that
the
more
that
we
do,
that,
the
more
that
we
start
to
define
where
this
might
exist,
and
so
it's
not
as
bad
as
it
seems
to
not
have
a
path
that
yet
because
we
I
think
that
we
actually
are
learning
where
this
goes.
The
longer
that
we
live
with
what
people
do
intuitively
I.
C
D
This
issue
is
fascinating
because
it's
basically
the
conversation
we're
having
that
about
type
of
information
I
like
I
like
that
top
one
that
particularly
because
there's
this
argument
about
context,
saying
that
a
data
is
never
context-free,
but
no
actually
really
interesting
discussion.
Are
we
aiming
for
context-free
data
or
data
that
is
always
tied
to
con?
Some
context
like
that
seems
to
be
a
hinge
for
a
lot
of
our
disagreements
about,
and
this
type
stuff.
C
C
A
You
might
remember
from
the
difficult,
but
that
data
Terran,
who
does
em
like
factory
things
with
ipfs,
Anatoly
and
they're.
They
basically
have
small
events
and
sent
them
over
to
like
all
over
the
place,
and
they
would
really
benefit
from
and
special
compression.
So
they
basically
know
they,
for
example,
only
send
certain
values
all
the
time,
so
they
can
use
just
a
existing
dictionary
and
compress
it
very
well,
which
you
can't
do
on
the
transport
layer,
because
the
Olea
doesn't
have
the
knowledge,
the
application
hands.
A
B
This
is
where
our
layer
model
starts
to
break
down
a
little
bit,
though,
and
how
we
built
a
lot
of
these
extractions.
To
be
honest,
because
this
doesn't
work
all
that
well
without
burying
codecs
quite
a
bit,
and
not
just
you
know,
treating
things
if
somewhat
codec
agnostic
and
just
supporting
a
data
model,
because
the
blocks
that
you're
creating
are
probably
just
like
raw
blocks
in
the
linkage.
But
then
are
semantically
interpreted
some
other
way
by
the
by.
E
C
E
D
But
the
point
of
the
discussion,
though,
is
that
maybe
this
is
not
our
problem
right
now
like
this
is
an
interesting,
interesting
thing
like
it's
similar
way
to
encryption.
Is
we
don't
need
this
right
now?
But
if,
but
we
want
to
make
space
that,
if
somebody
wanted
to
do
it,
then
they
could
come
along
and
contribute
something
that
would
do
this.
B
A
A
H
C
B
Okay,
well,
we'll
just
need
this
one
open,
it's
fine!
We
can
have
some
open
issues,
slice
paths-
this
belongs
in
the
path
back
that
needs
to
get
written
so
I,
guess
that
also
stays
open
until
that
gets
written
me,
but
I
was
thinking.
This
can
definitely
get
closed
out.
This
is
an
action
item
issue
from
January.
B
B
A
B
D
D
B
This
is
a
different
one,
though
this
is
the
mime
type
yeah
I'm
gonna
leave
that
for
now
don't
want
to
find
this,
but
we
do
need
to
have
the
discussion,
but
I,
don't
I,
don't
feel
confident
having
yet
because
I.
Don't
think
that
the
IDI
Anna
is
gonna.
Let
us
just
say
application.
Slash,
I
feel
D
belongs
to
us.
B
A
C
B
A
H
C
B
B
A
D
A
Very
good,
like
whatever
like
yeah
so
basically
I,
was
also
busy.
I
was
thinking
about
if
we
should
perhaps
I
ride
like
at
least
the
top
like
a
summary
and
then
our
timing
protects,
but
still
I
came
in
the
comments
because,
like
sometimes
like
I
think
like
especially
like
the
the
the
PR
before
from
from
God,
had
a
huge
discussion
on
also
the
graphs
and
stuff
really
their
discussions.
Also
interesting.
It's
not
about
like
the
thinking
about
things
that
take
listing.
B
B
Yeah
I
think,
like
the
the
point
here
is
to
kind
of
clear
some
of
this
out
to
the
big
game.
Suzanne
PRS
are
more
accurate
reflection
of
what
we're
talking
about
now
and
I
mean
we've
had
that
discussion
sitting
there
forever
it
can
fit
in
a
markdown
file
instead,
and
we
don't
really
need
to
put
like
a
lot
of
extra
stuff
around
it.
I
love
design
rules
from
Eric.
What
do
you
think
that
are.
C
H
H
A
H
B
Requires
like
in
like
an
ever-expanding
set
to
be
helped
by
every
session,
but
yeah
I
mean
this
needs
to
go
into
design.
History,
yeah.
C
H
A
C
C
B
H
B
D
Here's
the
thing
with
this
archiving
is,
though,
is
that
this
this
is
an
outstanding
thing
that
we
are
currently
hashing
out
between
us,
but
for
others
coming
along
to
this
discussion.
If
we
archive
this,
then
it's
like
well,
it's
not
resolved
it's
over
there,
but
misdoing
still
active
it's
kind
of
nice
to
have
this
thing
as
flagged
as
an
active
thing
that
we're
working
on.
B
B
A
But
I
see
but
I
think
it
shouldn't
be
our
cup.
So
if
we
close
it,
it
should
me
archive
because,
like
it's
not
like,
so
for
me,
the
archives
for
things
that
basically
people
spend
a
lot
of
time
thinking
about
things
and
we
decided
not
to
pursue
two
different
now
and
then
we
might
be
recommend
in
in
the
past.
It's
one
time
I'm
having
discussion
and
it's
not
like
it's
a
like
it's
a
proposal
or
something
it's
just
like
agree.
A
B
H
D
D
B
One
of
the
problems
with
all
these
diss
open
documents,
though,
is
that,
like
the
context
from
one
just
flows
into
the
next
one,
naturally,
because
it's
all
the
same
people
commenting
in
it,
so
none
of
them
make
very
good
point
like
particulars
places
for
you
to
get
that
information,
either
right
and
and
and
to
some
extent,
like
I,
would
actually
appreciate
an
issue.
Just
saying
like
I,
don't
know
anything
about
this.
B
I
think
we're
time
to
two
different
kinds
of
documents,
so
InDesign
history
dates
are
fine
because
those
don't
actually
even
get
modified,
but
in
the
like
design,
/
experimental
feature
a
that
we're
doing
those
actually
do
get
updated
when
people
are
actively
working
on
them.
D
D
On
that,
just
showing
what
you're
showing
there
on
your
screen,
the
back
to
another
discussion,
we
were
having
about
Matt
key
kinds.
Well,
now
the
schemas
allows
for
alternative
key
types,
and
you
can
see
it
there
in
the
advanced
layout
thing.
We,
you
know
the
curly
braces
and
the
string
to
string
thing.
D
B
B
E
B
C
B
Yeah
I
mean
so
I,
don't
see
the
because,
since
you're
literally
saying
the
same
thing
twice,
I,
don't
see
why
and
and
you're
not
allowed
to
do
them
separately.
I,
don't
see
the
point.
Why
and
if
we
want
to
and
if
we
want
to
open
up
the
possibility
of
being
amusing
advanced
type
as
two
different
types,
then
that
this
would
be
the
easiest
way
to
do
it.
Okay,.
C
B
C
C
A
Yeah,
just
I
just
recreate
what
we
just
like
I'm
still
concerned
about
the
previous
easy,
because
they
were
just
closed
because,
like
like
the
whole,
like
naming
composites
for
the
error
discussion,
because
the
problem
is
I
know
that,
like
tomorrow,
Michael
will
talk
about
composites
again
and
everything
will
be.
Everyone
will
be
confused
so,
like
I,
think
if.
H
B
I'm
gonna
go
and
write
a
spec
for
University
to
and
I
feel
B
schema.
Then
I'm
gonna
have
to
write
some
tools
to
turn
that
I
feel
the
schema
into
an
API
and
then
I'll
also
probably
end
up.
Writing
some
API
for
defining
in
advanced
layout,
not
totally
schemas,
and
that
will
give
us
a
much
more
concrete
thing
to
look
at
and
say,
like.
Okay,
here
is
like
in
the
advanced
layout
implementation
in
JavaScript,
and
here
is
a
composite
in
description
of
JavaScript.
What
is
the
difference
between
these
two
things
and
it?
B
We
can
have
a
much
more
informed
discussion
from
that
point
on,
and
it's
not
important
for
us
to
resolve
this
thread.
That's
until
you
know
before
that,
work
is
done,
so
we
can
just
kind
of
defer
it
and
then
we'll
have
a
better
thing
to
talk
about
and
more
knowledge
in
general
and
I.
Think
I'll
even
have
much
better
language
to
describe
it.
Okay
and.
A
A
B
B
C
E
A
I
think
you
have
to
add
the
group
Danny
really
I,
guess.