►
From YouTube: EIP Editing Office Hour #13
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/216
A
Welcome
to
EIP
editing
office
hour
meeting
13
I
have
shared
agenda
and
chat.
We
have
a
few
pull
requests
added
here
for
a
discussion.
We
are
joined
by
a
couple
of
authors
who
would
like
to
discuss
their
proposal.
Some
of
them
are
new
to
maybe
understand
the
process,
so
maybe
Sam.
If
you
can
pull
up
your
screen
and
we
can
start
looking
into
the
proposal.
We
can
start
with
the
first
PR
number
6506.
B
C
Yes,
so
I
am
here
mostly
to
kind
of
find
out
what
the
process
is
about.
Getting
this
included
in
to
see
what
the
next
steps
are.
I
have
made
all
of
the
recommended
changes
that
the
editors
requested:
formatting,
wise
and
structure
and
I
added
some
other
stuff,
as
well
in
the
comments
and
so
I'm
just
trying
to
figure
out
what
the
process
looks
like
yeah.
D
So
it's
just
waiting
for
somebody
to
look
at
it,
so
probably
be
yeah.
C
No
problem,
so
one
of
the
comments
that
I
got
when
I
submitted,
the
initial
pull
request
was
about
reference
implementation,
I,
built
a
proof
of
concept,
made
a
proof
of
concept
repo
that
implements
this
standard.
It's
not
included
in
this
markdown
file
because
they
said
it
shouldn't
be
so
it's
attached
in
the
comment,
history
of
the
pull
request
as
well.
D
Okay,
yeah,
if
it's
a
reasonably
sized,
you
can
put
it
in
the
assets
directory.
It.
C
Is
not
I
guess
so,
so
the
actual
the
actual
like
interface,
the
actual,
like
defined
interface,
is
included
in
this
style,
but
I
have
an
actual
like
solidity,
implementation
with
like
solidity
files
and
test
cases
and
scripts
and
stuff
that's
in
its
own
repo,
because
those
files
are
big.
D
Okay,
yeah
yeah
because,
like
we,
we
do
encourage
you
to
put
a
reference
implementation
in
The
Proposal
if
you
can,
but
if
it
like,
if
it's
huge,
then
yeah,
it's
best.
C
Yeah
elsewhere,
if
you,
if
you
scroll
down
later,
you'll,
see
the
defined
interface
with
the
functions
yeah,
absolutely
there
and
I
Define
all
that.
What
that
looks
like
in
terms
of
like
an
actual
solidity
implementation
that,
like
does
all
of
the
things
that
this
EIP
describes,
that's
in
its
own
repository,
okay,.
D
So
these
events
here
these
are
like
code
Snippets
right,
so
they
should
be
in
back
ticks
as
well.
Okay,
super
small
knit
so.
D
It's
just
it's
just
for
like
style
and
consistency,
it
won't
block
merging
it.
It's
just
the
next
time
you
make
a
commit.
Try
to
remember
to
to
do
that.
B
D
Yeah,
if
it's
code
like
a
snippet
of
code,
they
should
be
in
backticks,
even
if
they're
in
headers,
because
sometimes,
if
you
don't
do
that,
it
messes
up
the
spell
checker
and
then,
if
you
do
it
for
seven
of
them,
but
not
all
of
them,
then
it's
inconsistent.
So
it's
better
if
it's
code,
just
to
put
it
in
back,
ticks.
Okay,.
D
B
B
E
D
D
D
D
Yeah,
this
is
looking
really
good.
This
is
yaml
I,
assume
right.
C
I
copied
it
from
the
ERC
4626
version:
okay,.
D
C
D
Oh,
it's
the
the
like,
markup
or
not
markup,
the
language
that
this
is.
This
looks
like
yaml.
C
D
No
it's
just
if
you
put
the
indicator
of
what
language
it
is
along
with
the
backticks
here,
it'll
highlight
it
as
yaml.
Oh.
D
Even
worry
about
them
good,
good,
good,
great
and
then
this
is
also
the
animal.
D
D
Is
there
a
space
before
that
is
that
okay
I'm
not
sure
how
that'll
render
hopefully
it'll
render
correctly
okay
verify
that
looks
good.
B
D
Yeah
no
I
know
it's
Not,
Unusual,
okay,
modification.
D
Now
this
is,
this
is
looking
really
good.
This
is
written
the
way
a
standard
should
be
written,
so
excellent.
D
So
I
guess,
while
I'm
doing
this,
have
you
been
like?
Do
you
have
anybody
in
mind
for
who
you'd
like
to
talk
to
for
like
getting
a
review?
Who
do
you
think
your
like
users
are
going
to
be?
Who
you,
who
are
you
going
to
integrate
with
those
kind
of
questions.
C
Yeah
so
in
terms
of
like
actual
review,
I'm,
not
sure
the
target
audience
has
been
gals
I've
been
in
conversations
with
redacted
and
Hidden
Hand,
primarily
okay,
but
this
is
particularly
for
I,
guess,
generalized
for
any
doubt
implement
particularly
ones
that
have
on-chain
voting
is
well
I,
guess
ones
it
up
on
it's
a
applicable
to
ones
that
have
on
and
off
chain
voting.
C
So
right
now
my
focus
is
on
on-chain
voting,
so
but
it's
applicable
for
anyone.
Okay,.
B
D
Yeah
because
so
you
said,
you're
curious
about
the
process
so
after
this
has
merged
as
a
draft
it'll
be
this
is
this
is
going
to
get.
This
is
draft
right,
yeah,
okay,
it's
up
to
the
authors,
so
you
guys
to
figure
out
who
to
talk
to
in
the
community
to
get
reviews
from
outside
of
your
team
and
then
once
you're
satisfied
that
you've
had
enough
review.
You
can
move
what
was
once
you're
sat
once
it's
completed.
D
You
can
move
it
into
review
like
the
proposal
itself,
then
you
can
get
reviewers
and
once
you're
satisfied
that
it's
been
reviewed
by
anybody
who
might
have
an
interest
in
the
EIP,
then
you
can
move
it
into
the
last
call
status
and
that's
you
know
entirely
up
to
you
when
you
want
to
do
those
moves.
C
Okay
yeah,
so
luckily
it's
just
me:
okay,
yeah
and
I
have
or
been
the
stakeholders
and
people
I've
been
talking
to
have
been
in
I,
guess,
I'm
in
contact
with
them
for
several
months
as
I've
been
working
on
this,
so
I
guess
once
they
they've
already
signed
off
on
like
the
content,
so
I
guess
once
the
formatting
is
done,
it
should
be
good
to
move
it.
C
C
I'm
not
really
sure
how
I
would
go
without
getting
that
into
like
open
Zeppelin
I'm,
just
working
on
this
as
like
a
master's
thesis.
But
oh.
D
Yeah
yeah,
it's
I
think
we
have
some
contacts
there
that
we
could
talk
to
cool.
C
D
Okay,
yeah,
that's
that's
perfect.
I'll
just
add
these
changes
and
then
should
be
good
to
merge.
C
B
C
D
There
isn't
really
an
approved
right,
it's
it's
we're
just
a
bunch
of
documents.
We
don't
really
decide
who
uses
them
or,
if,
like
we
have
several
different
competing
standards
for
URLs,
for
example,
we
we
don't
make
really
any
judgment,
calls
on
them
other
than
like.
Do
we
think
they're
reasonable?
D
That's
kind
of
an
indication
of
how
complete
it
is
so
after
we
merge
this
in
draft,
that's
kind
of
a
signal
that
you're
starting
the
process
once
you
put
it
into
review,
that's
generally,
when
you're
signaling
to
everybody
that,
like
hey
the
standard,
is
ready
for
you
to
try
making
your
prototype
of
and
then
last
call
and
final
are
basically
like
we're
done
we're
not
making
any
more
changes.
This
is
the
absolute
last
chance
you
have
to
bring
up
any
concerns
before
it's
released
to
the
wild
okay,
I
gotcha.
D
Every
two
weeks,
but
feel
free
to
just
ping
me
or
whatever.
If
you
need
me
to
take
another
look
I'm
on
Discord
and
Twitter
and.
C
C
So
this
just
approves
it
I'll,
make
the
changes,
and
then
it
can
merge.
I.
D
A
All
right,
so
we
are
joined
by
next,
like
a
group
of
authors
for
the
proposal.
6672
I
just
have
shared
Link
in
the
chat.
D
A
That's
a
good
question:
we
have
a
lot
of
people
here
from
that
particular
group.
I,
don't
know
Archie
Randy
boy.
Anyone.
G
A
G
G
Okay
yeah,
so
we
are
from
retriever.
We
are
the
one
that
proposed
eip6672.
So
basically,
this
proposal
is
about
a
multi-red
team
of
nft,
so
we
already
in
the
in
the
retention
protocol
vertica
for
years,
and
we
also
see
that
there
is
there
was
a
protocol
called
EIP
called
five
five
six
zero,
but
that
EIP
is
only
works
in
a
specific
scenario.
G
So
what
we
are
proposing
here
is
like
to
improve
that
EIP
and
try
to
try
to
create
some
standard
that
can
be
used
in
multiple
scenarios.
D
So
my
first
question
is:
is
this
person
part
of
your
team.
B
D
B
D
E
B
B
D
D
So
because
these.
B
H
As
for
the
example,
do
we
like
just
like
put
the
descriptions
over
here
or
we
can
provide
any
like
because
we
have
done
like
several
projects
based
on
these
scenarios?
Do
we
also?
Is
it
okay?
We
include
the
links,
or
we
just
like
put
the
descriptions
over
here.
D
B
D
D
D
H
H
It's
the
duplication
is
mainly
duplicated
by
the
Redemption
ID.
So
if
they
want
to
like
block
certain
like
IDs
for
redemption
in
place,
they
can
put
the
same
IDs
there
so
that
they
it's
the
Redemption
ID
is
more
likely
an
order.
Id,
as
in
e-commerce,.
D
D
D
So
you
require
165
here,
but
you
don't
actually
say
at
least
you
didn't
see
anywhere
where
you
say
that
it
needs
to
implement.
B
D
D
D
D
D
H
Okay
yeah,
so
the
next
step
is
we
will
like
fix
according
to
these
like
comments
and
like
book,
another
time
or
or
we
just
like.
B
A
E
D
This
is
Spam
I
assume
this
Maza
for
zero.
One.
B
B
B
B
I
So
that's
that's
separately
defined
this
to
events,
because
the
the
create
rdf
will
be
triggered
when
the
token
was
first
mint
minted
at
the
first
time,
and
the
update
will
be
will
be
triggered
when
we
are
updating
the
rdf
statement.
So
I
missed
the
statement.
The
rdf
statement,
in
the
token
can
be
updated.
I
So
it's
it's
a
time
difference
and
the
the
two
events
is
makes
it
easier
for
the
listeners
to
to
capture
what
happens
and
have
the
corresponding
process
of
that
after
the
the
lesson.
The
event,
okay.
D
So
you're
still
leaving
rdf
data
as
like
up
to
the
implementer
right.
It's
not
defined
in
the
standard
itself.
I
Yes,
I
will
leave
it
as
to
the
implementer,
because
the
rdf
is
actually
something
that
already
already
been
standardized
and
it
has
own
own
standard
to
to
to
describe
the
integrated
scammer
and
the
yeah
yeah
I
missed
the
data
schema
we
we
did.
We
did
try
to
include
a
link
here
but
field
because
it
didn't
accept
external
links.
So
actually
we
we
intended
to
include
something
from
the
web
3C
website
page
for
a
reference,
so
that
the
implementer
can
actually
check
the
reference
on
how
they're
going
to
implement
that.
D
Right
I
mean
more
specifically
like
this
struct
here,
which
you
have
in
the
comment
like
I
rdf
is
fine
if
it's
left
outside
the
standard,
like
that's
out
of
scope
for
the
Erp
process,
but
the
struct
itself
for
encoding
rdf
data.
So
this
this
little
blob
here,
that's
not
part
of
the
stand
like
the
standard
or
or
is
this
something
that
should
be
left
up
to
implementers
as
well.
I
I
think
that's
not.
The
IDF
is
not
part
of
this
standard.
D
I
I'm
not
quite
sure
that
I
got
the
question,
but
I
I
think
here
is
because
the
rdf
there's
actually
different
synaptics,
like
somebody
used
to
Ado
and
something
is
other
the
all.
So
we
have
a
multiple
products
here
can
be
included
to
describe
something.
So
we
sometimes
we
use
a
with
the
array
type
here.
D
Okay,
I'm
not
super
familiar
with
solidity,
but
can
you
compile
an
interface
without
this
struct
being
defined?
That's
like
is
that
allowed.
D
D
Yeah,
that's
that's
what
I
was
thinking
yeah.
So
that's
probably
my
my
biggest
concern
is
that
there's
there's
if
somebody
is
like
using
the
standard
and
they
want
to
write,
say
a
like
I,
don't
know
just
a
website
that
displays
this
rdf
information
for
any
generic
token.
They
won't
know
what
the
structure
of
the
rdf
data
struct
is
without
like
manually
inspecting
each
contract.
D
It's
more
it's
not
about
there
being
an
example,
it's
about
like
if
I
were
to
write
a
like
a
dab
that
displays
rdf
data
for
an
arbitrary
token.
How
do
I
know
what
the
what
rdf
data
here
means
like
if
I
want
to
display
these
updates
or
changes
over
time
and
I
want
to
decode
it?
How
do
I
know
how
to
decode
this
form?
The
destruct.
I
I
see,
then
we
could
add
something
to
for
those
explains
about
the
rdf
data.
B
D
I
I
Can
be
actually
be
pointed
to
through
the
URI,
so
I
think
it's
better
to
for
for
the
for
the
decoder
to
find
those
information
there.
So.
I
F
Can
I
can
I
jump
in
here,
just
just
a
quick
suggestion?
Yeah,
so
can
you
scroll
back
up
to
the
last
yeah
to
this
one?
So
if
you
have
the
rdf
data
this,
this
needs
to
be
defined
when
you're
compiling
the
smart
contract.
Otherwise
you
cannot
call
it
and
if
you're
calling
it
from
another
smart
contract,
you
don't
have
access
to
the
internet
for
the
smart
contract
to
check
right.
F
If
so,
you
can't
really
use
Oracle
to
get
the
structure
in
itself,
so
my
suggestion
is
to
go
with
a
defined
RFD
data
struct
that
covers
all
of
the
use
cases
and
if
there
are
some
Fields
like,
for
example,
if
you
compare
the
last
one,
so
the
one
that
uses
arrays
of
predicate
an
object
and
the
the
previous
one
just
has
one
predicate
and
one
object.
You
can
just
use
the
one
with
arrays.
For
that,
and
you
know
your
arrays
for
predicate
an
object
can
be
of
size
one.
F
If,
if
that's
the
case
this
way,
any
smart
contract
can
use
this
interface
without
worrying
how
it
will
work,
and
the
issue
here
is:
if
you
support
multiple
RFD
data
structs
when
compiled
you,
you
might
get
different
interface
identifier.
So
if
you
rely
on
programmatically
checking
whether
or
not
the
smart
contract
is
has
support
for
eip6239,
then
you
wouldn't
be
able
to
do
that
because
he
wouldn't
have
to
you
wouldn't
be
able
to
deterministically,
say
this
hash
matches
this
one,
because
you
would
have
to
or
possibly
three
different
identifiers
there.
I
I
see
for
the
should
actually
implementation,
because
we
already
did
some
implementation
of
the
smart
contract.
So
What,
where
you
said
just
have
the
re-type.
There
is
a
squad
for
the
standard,
something
we
we
separate
because
for
the
action
implementation,
it
is
it's
a
best
practice
to
just
include
one
one
statement:
I
mean.
D
Yeah,
unless
there's
a
a
reason
to
go
with
one
of
the
other
two
options
here,
I
would
suggest
just
only
defining
this
one
and
then
making
a
note.
That
says,
like
it's
best
practice,
to
use
array
of
length,
one
for
predicate
an
object
and
I
think
that
would
probably
handle
all
three
use
cases
I'm,
not
too
sure
about
this.
One
like
this
one
seems
very,
very
generic,
but
these
other
ones
seem
a
little
bit
more
specific.
B
D
So
we
are
planning
on
allowing
links
to
w3c
we're
just
figuring
out
the
specifics,
so
once
we
get
that
sorted
out,
you'll
be
able
to
link
to
it
eventually.
D
Okay,
it
rdf
so
for
the
update
stuff.
Is
it
going
to
be
common
like
who
is
going
to
be
doing
the
updates?
Is
it
the
person
who
deployed
the
token
contract
or
is
it
anybody.
I
It
definitely
cannot
be
anybody,
but
actually,
when
the
incrementers
was
firstly
deploying
the
smart
contract,
they
can
Define
who
is
going
to
be
update?
Who
is
going
to
update
rdf?
It
can
be
someone
like
the
implementer
and
somewhere
in
the
white
list,
or
get
this
just.
They
Define
it
for
us.
Okay,.
D
So
for
contracts
like
erc20
and
ERC
721,
we
generally
don't
include
interfaces
for
minting
or
updating
the
metadata,
because
it's
usually
very
unique
to
the
implementation.
How
to
do
that
so
I'll
make
the
same
recommendation
here,
that
you
don't
specify
how
to
make
changes
to
the
rdf
and
leave
it
up
to
the
implementers
unless
you
think
it's
going
to
be
common
for
multiple
daps
like
like,
let's
say,
I'm
making.
You
know
a
token
that
has
rdf
information
in
it
and
I,
deploy
it
How
likely.
D
Is
it
that
another
dap
is
going
to
be
changing
the
rdf
of
the
token
that
I
deployed?
Because
if
that's
going
to
be
very
uncommon,
then
I
don't
think
you
need
to
standardize
it.
But
if
it's
going
to
be
very
common,
you
probably
should
standardize
it
and
that's
up
to
you
and
just
just
a
recommendation.
I
I
see
it's
not
common
for
the
others
to
update
ads,
but
for
the
for
the
this
owned
app
right,
the
users
or
the.
I
D
Yeah
yeah,
so
the
best
place
for
a
standard
is
when
you
have
multiple
different
implementations,
trying
to
talk
to
each
other.
So
if
it's
only
ever
going
to
be
the
deployer,
that's
making
the
rdf
updates,
then
you
probably
don't
need
to
make
a
standard
for
it,
but
every
like
reading
the
rdf
stuff
that
that
absolutely
needs
a
standard
and
I.
Think
that's
great!
D
D
D
D
B
D
B
All
right,
so
that's
looking
really
good.
Just
a
few
comments
on
there.
Yeah
thanks
for
coming
out
and
I
appreciate
it.
B
D
D
D
D
All
right
so
I
know
this
is
really
really
late
in
the
game,
but
having
a
Boolean,
that's
negated
is
always
incredibly
annoying
from
a
developer
standpoint
and
I
would
very
strongly
recommend
is
transferable
instead
of
is
non-transferable,
but
that's
that's
entirely
up
to
you
guys.
D
D
Foreign,
you
have
a
comment
in
here
addressing
my
yeah
yeah:
okay,
yeah.
F
One
of
the
issues
when
you're,
defining
booleans
and
integers
and
solidity
is
the
no
default
value
which
means
that
it's
always
false.
So
if
it's
non-transferable,
you
have
to
set
it
to
true.
D
A
F
D
B
B
D
D
D
D
E
E
E
B
A
All
right,
thank
you
so
much
yes,
I'm
just
to
let
you
know,
there
are
three:
oh
I
guess
four
proposal
in
last
call
and
one
more
in
finally
call
waiting
for
review.
So
if
you
get
a
chance
to
maybe
take
a
look
Offline,
that
would
be
awesome,
yeah,
of
course,
yeah.
Thank
you.
Everyone
for
joining
us
today
and
hope
to
see
you
in
two
weeks
have
a
good
one.
Everyone.