►
From YouTube: URL/URI standard working group meeting 1
Description
Working document - https://hackmd.io/@poojaranjan/URLWorkingGroup
A
All
right,
thank
you.
Everyone
for
joining,
we
may
be
expecting
a
couple
of
more
people
to
join
in.
I'm
just
gonna
share
the
hackmd
file
that
I
have.
I
probably
have
shared
earlier
with
some
of
you,
and
this
is
just
a
list
of
proposals
which
are
available
on
eap
repositories
for
uri
or
url
standard.
I
know
this
is
the
idea
of
magnet
to
have
all
these
people
in
a
room,
and
we
can
probably
talk
about
standardization
process
or
how
we
can
have
one
good
standard
available
for
uri
and
url
so
matt.
B
B
It
feels
like
there's
a
lot
of
different
standards
that
are
started
starting
to
bubble
up
now,
related
to
urls
uris,
referring
to
information
on
the
ethereum
blockchain,
and
it's
not
clear
to
me
how
much
overlap
we
have
on
these
types
of
things,
and
maybe
the
outcome
of
this
call
is
that
there's
really
not
a
lot
of
overlap
and
people
will
just
keep
doing
their
own
types
of
things,
but
because
they're
so
closely
related.
B
So
I
feel
like
if
the
outcome
of
this
call
is
that
we
can
at
least
just
figure
out
like
what
exactly
are
people
doing,
what
what
do
they
want
to
accomplish
with
these
standards.
And
how
can
we
group
these
in
a
way
that
makes
sense
and
then
figure
out
what
applications
and
what?
What
libraries
are
going
to
need
to
support
these
things?
B
That
way,
we
can
work
on
making
sure
that
those
things
are
upstreamed
into
those,
because
it's
you
know
it's
something
that
we've
seen
before,
where
people
come
up
with
good
standard
ideas,
but
they
don't
ever
make
it
into
like
canonical
upstream
sources
and
so
like
a
good
example
is
like,
if
you
make
it
change
the
rpc,
but
it
never
is
upstream
to
web3.js
or
ethers.
Then
you
know
more
or
less.
You
didn't
make
a
change
to
the
rpc,
because
that's
the
interface
most
people
access.
B
B
C
Sweet,
I
think,
from
my
understanding
right
now.
There's
a
couple
schemes
out
there,
there's
the
ethereum
scheme,
the
dap
wc
and
ethpm
or
ethempm
right
so
under
dapp
bruno
renault
bard
79
has
made
a
url
for
dapps
in
general
to
basically
have
deep
linking
into
mobile
wallets.
So
you
can
that
way.
Open
up
your
mobile
wallet
wc
is
for
wallet
connect.
They
have
their
own
uri
scheme
that
they
use
for
all
their
fun
stuff,
and
that
is
like
wallet,
connect,
specific
actions.
C
B
C
It's
the
first
time,
I'm
seeing
it
and
then
there's
the
ethereum
scheme
which,
as
of
right
now,
if
you
do
not
put
anything
behind
it,
so
there's
831,
which
defines
that
there's
just
ethereum
colon,
some
prefix
dash
and
then
the
payload.
C
The
current
prefixes
that
are
in
use
are
the
pay
prefix.
If
you
put
nothing
or
you
put
the
pay
prefix,
it's
a
681.
So
it's
for
transaction
requests,
so
you
can
request
a
payment
or
a
specific
transaction
to
or
interacting
with
a
smart
contract.
C
Let's
see,
2400
or
24
yeah
2400
describes
ethereum
colon
and
then,
as
prefix
tx,
to
be
able
to
link
to
a
transaction.
So
say
you
had
a
vending
machine
or
some
appliance
that
interfaced
with
ethereum.
C
They
can
give
you
a
link
back
to
the
actual
transaction
that
you
just
submitted
or
to
a
past
transaction
etc,
or
we
can,
in
our
browser
link
to
transactions
without
having
to
specifically
link
to
ether,
scan
or
polygon
scan
or
whatever,
so
it's
ethereum,
colon,
tx
dash
transaction
id
and
then
at
and
then
the
chain
id
and
then
some
extra
information
and
then
the
one
that
I've
now
proposed
together
with
a
few
of
the
co-authors,
is
1594
still
an
open
pull
request
and
that
is
for
actually
switching
to
networks,
because
what
I
realized
is
I'm
working
on
a
little
project
in
ethereum
vending
machine
right.
C
It's
an
appliance.
It
needs
to
interface
with
your
mobile
phone,
somehow
so
we're
using
qr
codes
for
it
and
what
the
situation
is.
Is
that,
like
the
ethereal
parser
npm
package
made
by
bruno,
which
is
funnily
enough,
the
guy
behind
the
dap
scheme?
He
was
both
at
metamask
and
he's
now
at
rainbow.
He
wrote
each
url
parser
and
it
only
kind
of
supports
part
of
681
like
it
doesn't
support
any
of
the
like
calling
functions
on
a
smart
contract
except
for
transfer.
C
C
and
it
supports
all
of
them
and
it's
migrated
to
typescript
and
it's
lovely
and
it
works,
and
I've
been
back
and
forth
with
bruno
on
on.
You
know
changes
that
he
wants
to
see
and
then
you
know
making
sure
that
all
happens.
However,
the
issue
that
I
noticed
with
the
mobile
wallet
is
that
I'm
deploying
my
stuff
right
now
on
polygon
to
test
everything
out,
which
obviously
is
not
eve,
mainnet
and
scanning
a
url
or
uri.
If
you
will
using
metamask
or
rainbow,
which
parses
it
through
ethereal
parser
appears
to
fail.
C
C
So
the
idea
of
5094
is
to
kind
of
mirror
the
rpc
variant,
because
you
know
we
needed
a
url
standard
as
well
to
be
able
to
use
it
in
qr
codes
where
I
can
just
put
a
sticker
on
the
vending
machine.
That
says,
add
the
polygon
network
same
way.
C
We
have
the
button
at
the
bottom
of
a
polygon,
poly
scan
to
add
it
to
metamask,
for
example,
right
and
instead
of
running
an
rpc
call
in
this
case,
there's
a
url
ethereum
colon
network,
add
and
then
all
of
the
information
for
the
network
itself,
so
the
network
name,
the
currency,
name,
decimals,
etc.
C
D
Okay,
so
maybe
the
the
first
thing
we
should
do
like
after
the
summary
of
of
everything,
that's
out,
there
is
go
through
and
actually
list
all
the
use
cases
people
have
as
opposed
to
the
actual
standards.
So
right
now
we
have
like
network
switching.
What
other
use
cases
do
people
have
that
they
want
to
talk
about.
E
Yeah,
actually,
I'm
thinking
the
question
because,
like
I
saw
like
there's
a
seminar
comments
regarding
the
different
type
distinguished
use,
cases
like
network
switch,
switching
and
also
fixed
amount
of
transaction
receives,
and
also
the
apps.
So
I
feel
like
probably
we
can
put
two
categories
kind
of
like
a
core
eips
versus
erc,
which
is
one
one
type
of
uil
is
help
help
the
basically
the
users
to
locate
fixed
one,
read
and
write
the
basically
resources
on
top
of
ethereum,
for
example,
it
can
be
a
request,
a
transaction.
E
It
can
read
a
state
or
read
a
maybe
block
or
read,
for
example,
any
result
that
is
returned
from
smart
contracts
and
that's
something
I
feel
like
it's
highly
correlated
and
probably
we
can
put
it
in
one
vip
and
probably
there
are
also
a
couple
of
sub
other
types
of
come
like
erc.
That
request
come
like,
for
example,
the
new
network
or,
for
example,
add
on
a
d-app
link
so
that
it
can
designate
what
kind
of
network
id
is.
This
is
kind
of
initial
thought.
F
I
mean
I'm
not
a
fan
of
network
searching,
obviously,
but
isn't
it
better
that
we
just
have
optional
parameters
to
an
actual
action.
You
know
because
it
would
take
one
qr
code
scan.
I
know
it
would
become
like
a
quite
a
significant
qr
code.
You
want
to
resist
the
data
in
a
qr
code,
so
it's
readable,
but
for
example,
you
have
chain
name,
rpc,
url
rpc
url
seems
relevant,
but
then
should
wallets.
Just
do
most
of
this
work.
F
C
C
Becomes
the
deciding
factor
on
what
rpc
endpoints
get
used
with
5094
right
now,
you
can
even
give
a
list
of
rpc
endpoints,
but
the
I
mean,
like
you,
suggested
we
could,
hypothetically
speaking,
amend
681
right,
the
ethereum,
actual
payment
standard
and
that's
already
final
and
add
query
parameters
for
rpc,
url,
etc,
etc,
etc.
C
D
C
I
mean,
then,
you
still
have
to
add
an
rpc
url
to
your
thing.
So
it's
going
to
add
more
complexity
to
the
url
in
overall
right,
because
it's
going
to
be
ethereum
pay
dash,
whatever
contract
you're,
interacting
with
slash
whatever
function,
you're
interacting
with
then
gas
price,
gas
limits
and
a
gas
estimate
as
well
as
value,
and
then
every
argument
you're
giving
to
the
function,
which
probably
also
if
it's
like
an
erc20
transfer,
contains
another
address
right.
C
So
you
already
have
a
very
long
url,
that's
already
very
detailed
and
requires
in
my
specific
case,
but
I
can
see
this
in
a
lot
of
other
cases
as
well
requires
more
details.
So,
if
you're
going
to
print
stickers
to
do
this,
they're
going
to
have
to
be
very
detailed
if
you're
going
to
use
a
low-res
display
you
just
you
can't
right.
C
B
C
C
B
What
flow
are
you
imagining
with
this,
because
the
way
that
I
interpret
these
flows
is
that
the
wallet
should
really
be
the
one
who
decides
what
network
it
supports,
because
right
now,
there's
pretty
good
overlap
with
eth
and
polygon
and
optimism,
but
that
doesn't
necessarily
have
to
be
true,
and
so
just
adding
a
network
and
assuming
it
has
that
same
interface
as
another
network
could
be
a.
Could
it
cause
problems?
B
Just
these
networks
assume
that
there's
a
specific
interface
for
interacting
with
the
network
and
that
there's
certain
assumptions
that
are
being
made.
I
mean
you
can
imagine
that
a
network
performs
completely
differently.
I
mean
there's
already
these
differences
with
l2s
right
now,
right
like
if
I
submit
a
transaction
to
an
l2,
then
that
transaction
actually
isn't
posted
to
the
mainnet,
and
so
there
isn't
very
good
guarantees
that
it's
actually
going
to
go
on
chain
for
several
minutes
and
there's
lots
of
just
small
things
like
this.
B
B
B
It
feels
like
a
the
wallet
should
dictate
what
network
it
supports
and
if
you
try
to
use
a
qr
code
that
doesn't
support
that
it
doesn't
support,
then
that
should
be
handled.
You
know
in
a
better
way
like
crashing,
is
obviously
not
an
acceptable
way
to
handle
it.
That's
what's
happening
currently
right.
Well,.
F
This
proposal
kind
of
fits
your
requirement
right
because
you,
as
a
user,
would
scan
the
qr
code
for
network
ad
before
doing
the
pay
correct.
So
I
end
up
being
the
same.
At
least
you
fail
for
a
different
reason.
You
know
why
you're
failing,
while
the
other.
C
The
ideal
flow
that
I'm
imagining
here
and
obviously
it's
not
the
most
ideal,
but
it
is
the
best
we
can
do
with
the
current
situation
of
681
is
that
a
user
would
walk
up
to
the
machine
they'd
like
to
interact
with
or
the
site
that
they'd
interact
like
to
interact
with
assuming
they
don't
use
wallet,
connect
and
try
and
scan
the
payment
request,
url
or
qr
code,
and
then
their
wallet
should
give
an
error
saying
unknown
network
or
please
add
the
network
with
this
id
first
right
and
then
the
user
will
probably
look
down
realize
that
there
is
a
little
pop-up
at
the
bottom
of
the
screen.
C
G
So
I
think
I
think
it
does
make
sense,
but
I'm
concerned,
like
I'm
already
concerned
with
the
rbc
endpoint
friday
network
and
the
reason
is
in
that
situation
you
described.
I
really
don't
feel
like
that
user
should
be
adding
a
network
from
a
vending
machine
like
either.
You
are
familiar
with
the
network
you're
interacting
on
or
you're.
Not.
You
should
go
research
it
and
like
fair
normalizing.
G
This
behavior
of
getting
users
to
just
like
scan
qr
codes
in
a
subway
and
add
them
to
metamask
feels
very
dangerous
and
ripe
for
abuse,
and
so
I'm
very
hesitant
to
to
normalize
that
and
make
that
like
an
acceptable
thing,
I
feel
like
you
should
tell
the
user
hey,
you
know
we're
on
polygon.
You
need
to
go,
get
some
polygon
eth.
You
need
to
go
research.
What
polygon
is
then
you
can
come
back
and
use
this
vending
machine
not
like
hey.
This
is
a
vending
machine
sign
up
here
to
get
your
free,
candy
bar.
C
But
most
most
wallets
get
mad
at
you.
If
you
try
and
add
a
network-
and
you
use
the
incorrect
information
right
and
worst
case
scenario,
somebody
adds
a
third
party
endpoint,
I
mean
you,
you
have
a
chain
id
and
you
have
an
rpc
url.
I
don't
see
how
this
could
go
wrong.
The
worst
case
scenario,
somebody
you
know
who
makes
this
malicious
qr
code
adds
an
emoji
next
to
polygon,
mainnet
right,
matic,
mainnet.
G
So
I
think
the
the
worst
case
scenario
is
I've
never
used
like
hypothetically
I've
never
used
polygon
before
so
I
go
up
to
vending
machine,
it
says,
add
a
polygon,
I
scan
a
qr
code
to
add
polygon
and
I
buy
my
candy
bar
or
whatever
I
now
have
polygon
like.
Oh
polygon
is
nice,
I'm
using
it,
and
then
I
go
do
some
other
stuff,
I'm
polygon,
but
lo
and
behold
this
whole
time
not
actually
talking
to
a
real
polygon,
rpc
endpoint,
I'm
talking
to
some
malicious
endpoint.
G
That
is
then
forwarding
some
of
my
requests
to
polygon
and
then
capturing
some
of
them
and
doing
bad
things.
Letting
me
back
data
back
making
me
think
that
I'm
going
to
do
something
that
I
don't
intend
to
do
stuff
like
that,
like
I've,
basically
just
added
some
something
I
got
from
a
qr
code
as
an
authoritative
source
of
information
about
the
polygon
network,
but
I
have
no
reason
to
believe
that
is
actually
the
polygon
network.
I'm
talking
to
it's
just
you
know
some
do
it
on
the
internet
or
in
this
case.
C
At
that
point,
you'd,
hopefully
have
your
wallet:
either
interfere.
Your
wallet
have
a
pop-up
when
you
scan
the
qr
code
actually
showing
what
you're
about
to
add
as
a
network-
and
I
mean
it's
the
same
situation
when
you
go
to
any
website
that
says,
add
the
polygon
network
and
you
just
press
the
button
there
right,
yeah.
G
And
I
think
that's
terrible
as
well
like
to
be
clear.
I'm
not
saying
just
your
what
you're
proposing
is
bad.
I'm
saying
like
this
normalization
of
people
adding
networks
without
knowing
anything
about
them,
I
think,
is
bad
for
the
security
of
end
users
like
right
now,
the
users
that
are
doing
this
are,
you
know,
apes
and
dgens
and
whatnot,
and
they
know
the
risks
that
they're
getting
into
I'm
much
more
worried
when
you
get
the
mom
and
pop
that
is
normalized
into
oh.
G
G
I
think
what
matt
was
getting,
that
is
the
the
best
from
a
security
standpoint
solution,
which
is
the
individual
wallets,
add
support
for
networks
natively,
and
you
trust
your
wallet,
presumably
because
you're,
giving
it
your
private
keys,
and
so
they
are
delegating
authority
to
you
know:
okay,
we
we
met
a
mask,
assert
that
this
is
how
you
access
polygon.
You
access
it
through
this
inferior
link
that
we
have
baked
in,
or
you
can
add
your
own
manually,
but
that's
a
an
advanced
use
case
and
then
in
theory.
You
know
the
wallets.
G
Add
a
bunch
this
I
recognize
this
does
make
it
hard
to
get
new
l2
adoption,
because
you
need
to
sell
the
wallet
first
or
you
can
only
sell
it
to
advanced
users,
but
the
trade-off
we
have
to
make
here
that
I
don't
see
a
solution
to
is
end
user
security
versus
ease
of
adoption,
and
I
tend
to
fall
on
security.
Just
because
I
I
worry
not
about
the
current
generation
of
users.
I
worried
about
the
next
generation
of
users
who
are
just
going
to
get
just
destroyed.
F
H
G
Yeah,
when
you
still
met
a
better
mask,
you
know
they
give
you
the
inferior
one
and
you're
implicitly
entrusting
in
fear
by
delegating
your
trust
through
metamask.
If
you
ask
the
hardcore
security
people,
they'll
say
no,
you
should
run
your
own
node.
I
guess
the
only
way
you
can
actually
trust
this.
There,
of
course,
is
a
spectrum
between
you
know
just
subway
rpc
endpoint
and
run
your
own
node
and
inferior
somewhere
in
the
middle.
G
But
you
are
correct:
there's
there's
no
way
to
authority
to
gain
that
trust
other
than
through
an
existing
trust
network,
which
may
mean
you're
running
your
own
code.
It
may
mean
talking
to
a
friend
who
you
do
trust
about
all
these
things.
Who
tells
you,
oh
and
fear,
is
trustworthy
or
here's,
my
node,
you
can
borrow
it,
etc.
G
H
One
one
thing
worth
noting
too
here
is,
like,
I
think,
we're
complicated.
This
is
like
two
separate
issues
right.
It's
like
one
is
the
standardization
of
just
like
some
url
format.
The
other
is
what
like,
what
does
a
wallet
developer
need
to
make
their
experience
better?
I
think
mika
kind
of
hit
good,
where
it's
like
this
makes
wallet,
developers
lives
easier,
but
realistically,
hey
how
many
evm
chains
are
people
actually
adding
all
the
time
and
b
like
if
that's
the
pro?
H
If
the
problem
is
the
lack
of
evm
change,
the
wallet
developers
should
either
enable
advanced
functions
like
in
metamask,
where
you
can
just
create
an
rpc,
or
they
should
just
be
updating
their
app
more
frequently
like
I
just
don't
see
a
reason
for
exporting
that
process,
because,
like
yeah,
like
mika,
said,
if
you're
at
a
vending
machine,
it's
like
oh
add
this
random
network
and
you
need
to
procure
tokens
and
stuff
to
begin
with
or
bridge
them
over.
It's
already
like
super
risky.
C
I
mean
you
might
have
just
not
added
your
mobile
wallet,
the
new
networks.
Yet
in
my
case
I.
H
B
Yeah,
it
feels
like
there's
like
a
spectrum
where
we
can
push
more
of
this
work
towards
developers
like
on
the
application
side
and
then
the
spectrum,
where
we
push
more
of
these
things
to
the
wallet
developers
and
it
feels
like
we
are
not
pushing
things
hard
enough
onto
wall
developers.
We're
accepting
that
they
give
us
like
basically,
the
bare
minimum
to
interact
with
these
chains.
And
then
we
do
everything
else
and
it
kind
of
feels
like
that's,
not
the
best
approach.
B
I
want
to
take
a
step
back
quickly,
we're
kind
of
running
up
on
time,
and
I
don't
want
to
keep
people
too
much
over,
so
the
people
on
this
call
probably
have
a
pretty
good
perspective
on
what
types
of
things
are
lacking
in
this
you
know
sort
of
domain
of
urls
uris.
B
B
You
know
the
situation
that
users
are
interacting
with
and
like
in
this
example,
where
we
have
this
in
the
cip
to
add.
Actually
new
networks
to
wallets
like
this
is
obviously
important,
given
the
situation
where
and
where
wallets
are
not
probably
doing
what
they
need
to
do
like.
How
can
we
then,
like
transition
to
making
walls?
Do
the
right
thing.
C
So
you
want
to
instead
of
talking
okay,
so
we've
we've
agreed
that
this
is
just
a
uri
format
right
and
that's
that
and
the
greater
problem
at
scale
is
we
need
to
like
tighten
down
on
wallets
and
go
hey.
You
should
take
some
responsibility
for
your
users
and,
like
make
sure
they're
safe.
How
do
we
resolve
that?
C
B
So
we're
looking
for
improvement
on
that
you
you're
giving
full
trust
to
your
wallet,
and
so
I
think
that
you
know
the
things
that
you've
already
decided
is
okay,
like
them
deciding
what
rpcs
you
interact
with.
Is
you
know
not
as
bad
as
what
other
things
they
could
do?
It's
not
the
biggest
concern,
yeah,
fair.
D
I
think
it's
just
important
to
include
them
in
the
discussion
of
what's
possible
and
what
they'd
like
to
see
like
I,
I
definitely
think
having
a
registry
of
of
endpoints
that
wallets
maintain
might
be
a
good
idea,
but
that's
about.
As
far
as
I
thought
about
it,.
G
So
I
liked
I
have
a
fan
of
the
way
uniform
handled
this
with
token
lists,
where
it's
a
decentralized
system.
You
can
pick
your
list
and
the
app
can
support
the
list,
but
you
don't
need
to
couple
the
two,
and
so
I
might
use
metamask,
but
I
might
use
you
know
the
sam
wilson
list
of
rpc
endpoints
instead
of
metamasks.
D
Yeah,
that's
that's
a
great
idea,
not
not
giving
me
a
list,
but
using
the
uniswap
like
tokenlist
model.
I
mean
isn't
that.
G
G
You
can
add
a
list
of
tokens
from
somebody,
you
trust
and
that
doesn't
have
to
be
the
person
whose
app
you're
using
it
can
be
someone
different,
and
so
your
you
know,
your
wallet
is
one
entity
and
they
give
you
a
default
list.
Maybe,
like
minimas
gives
you
inferior,
because
it's
consensus
and
they
own
both.
G
But
you
can
say
you
know
what
I
want
to
use
all
the
tok,
all
the
rpc
endpoints,
as
provided
by
you,
know,
rainbow
wallet
or
whatever
or
sam
wilson
or
wherever
you're
getting
your
list
from,
and
now
you
have
fully
populated
lists
that
it's
not
just
in
fura.
You
know
it's
also
a
bunch
of
other
places.
D
Well,
this
sounds
like
something
we
could
bring
up
with
the
all
wallet
devs
and
get
a
an
eep
together
for
creating
that.
C
G
G
Yes,
and
I
I
do
not
want
to
go
towards
more
or
towards
less
secure,
while
we
are
working
on
going,
because
these
are
opposite
directions
right
either
we
go
towards
make
it
harder
to
add
rpc
endpoints
from
random
places
on
the
internet
and
random
places
in
the
world,
or
make
it
easier
to
do
those
things.
What
59
informants
describe
describing,
if
I
understand
correctly,
is
let's
make
those
things
easier
and
I'm
saying
no:
no,
we
should
be
making
them
harder
like
these
are
in
tension
with
each
other.
C
Okay,
all
right,
do
you
think
they're
there
do
you
see
how
there
could
be
issues
if
we
had
a
qr
version
or
like
link
version,
if
you
will
uri
for
adding
one
of
those
trusted
lists,
because
then
you're
still
in
a
similar
situation,
where
a
user
gets
told,
hey.
G
Right
yeah
same
thing,
so
the
way
unit
handles
this.
Is
they
don't
give
you
a
list?
They
give
you
a
place
to
put
a
list
and
then
you
it's
up
to
you
to
go,
find
your
list
and
then
they
give
you
a
link
to
a
place.
That's
got
like
100
lists
lists
listed
and
you
can
pick
from
them
like
they.
They
give
you
a
breadcrumb,
basically
on
hey,
here's
how
you
can
get
started,
but.
G
Exactly
that's,
that's
the
key
they.
It
is
up
to
the
user
to
go,
find
the
list
and
we
don't
want,
and
specifically
we
don't
want
giving
people
a
list,
because
that's
delegating
trust
to
the
person
who
gave
you
a
list
which
is
probably
not
someone.
You
should
trust
like
anyone.
Anyone
who
tries
to
give
gives
you
a
list
is
probably
not
the
person
you
want
to
get
a
list
from.
B
B
Okay,
we're
a
couple
minutes
over.
I've
got
two
main
action
items
that
I
wrote
down.
One
is
talk
to
wall,
it's
about
just
properly
supporting
rpcs
and
considering
supporting
some
type
of
rpc
lists.
That
way,
we're
not
coupling
those
two
as
tightly
together
and
let's
do
some
work
on
trying
to
remove
this
rpc
endpoint
that
lets
users.
Add
new
rpcs
to
wallets.
Is
that
roughly
what
we've
come
to.
D
Oh
and
schedule
the
next
one
of
these
working
group
meetings,
so
we
have
a
deadline.
G
C
G
That
is
that
rpc
endpoint
was
one
such
thing
where
it
was
like
hey.
We
want
to
get
lara
2's
working
before
they're
decentralized,
while
they're
still
sensorable,
while
they're
still
centralized
well,
people
can
still
steal
all
the
money
before
they're
audited.
We
want
to
get
them
into
user
hands
right
now,
with
a
single
click
and
their
pc
was
added.
C
Okay,
I'm
bitter,
so
I
I
presume
that
this
is
going
to
take
a
fair
bit
of
time
like
this
is
not
something
we'll
have
done
in
the
next
like
week
or
two
right,
and
then
we
need
wallet.
Adoption.
B
C
D
C
C
G
The
way
the
way
unisop
handled
this,
which
was
good,
I
think,
is
their
built-in
list
was
incredibly
limited.
It's
like
die
usdc,
usdt
and
east
and
west.
I
think,
or
something
like
that,
and
then
it's
up
to
you.
If
you
want
more
and
so
in
a
perfect
world,
the
there's,
no
there's
no
perfect
world.
G
In
one
hypothetical
world,
the
wallet
comes
with
a
default
list
that
is
fairly
constraining
and
then
any
user
who
wants
to
do
anything
more
would
go,
find
a
list
and
add
it
like
chainlist.org
they'd
use
theirs
or
something
there's
another
alternative
world
where
metamask
includes
chainlist.org
or
includes
their
own,
but
it
is
very
thorough
and
complete
and
you're
totally
right.
Most
users
will
not
change
it,
which
is
unfortunate
because
it
just
means
we're
delegating
more
and
more
trust
to
the
wallet.
That
being
said,
the
wallet
is
at
least
someone.
G
C
So
here's
what
I'd
like
to
propose
and
give
me
a
moment
to
like
properly
put
this
out
there.
I
really
want
something
like
this,
and
I
understand
that
if
we
currently
put
it
on
the
track
of
making
the
better
version
of
this
right,
it's
going
to
take
a
fair
bit
of
time.
C
I
think
what
what
is
very
possible
is
that
we
actually
don't
get
scared,
merge,
1594,
but
we
add
some
kind
of
clause
at
the
bottom
that
says
that
it
has
an
expiration
date
and
that
it
is
awaiting
for
override
from
a
future
eip
that
we
will
be
working
on
and
getting
implemented
into
wallets.
So
for
the
meanwhile.
That
is
a
feature
because
again
it's
just
a
mirror
from
the
rpc
feature
that
already
exists,
and
then,
as
soon
as
we
are
ready
to
replace
the
rpc
feature,
we
can
also
immediately
throw
out
5094
right.
C
D
E
D
Agree
with
it,
but
I
think
it's
one
of
those
things
where,
if
you
want
to
build
it
for
your
dap
and
convince
wallet
developers
to
do
it,
you
you
certainly
can.
But
I
don't
think
it's
something
that
we
should
like
actively
try
to
encourage,
because
if
applications
build
on
top.
B
D
Then
you
get
a
bunch
of
momentum
to
to
keep
it
and
then,
as
that
momentum
builds
up,
it
becomes
harder
and
harder
to
remove
it.
So
right
now,
there's
like
let's
say
you
know:
10
apps
that
use
the
rpc
endpoint
and
10
apps.
That
would
use
the
url.
Well,
if
we
add
the
url
now
you
have
20
daps
that
are
pushing
back
against
removing
the
endpoint.
So
that's
my
concern.
D
C
Yeah
we
can,
we
can,
we
can
add
a
section
to
it
that
says,
discourages
use
of
this
endpoint
only
for
temporary
purposes
or
something
along
those
lines.
The
use
of
this
eip
until
the
new
standard
comes
out.
So
essentially
it's
like
a
a
deprecation
warning
ahead
of
time.
If
that
makes
sense
right
and
then
we
can
immediately
in
there
also
formulate
deprecation
of
the
actual
rpc
version
right.
I
don't
can't
remember
exactly
what
eip
that
is.
C
G
A
And
if
I
may
add
here
that
this
proposal
is
present
at
present,
is
in
the
you
know
pr
status
right,
even
if
it
is
merged,
it
will
be
in
draft
and
then
it
will
be
in
review
last
call.
It
is
not
something
that
we
are
going
to
see
in
less
than
two
months
time
period.
So
my
question
will
be
like
one
thing:
the
the
present
proposed
proposals
that
we
have
in
eip
repository.
A
And
I
know
this
is
like
way
over
the
time
that
we
have
decided
for
it.
So
if
people
want
to
discuss
this
further
in
in
next
meeting,
we
can
probably
come
up
with
a
date
and
time
that
works
for
everyone,
and
one
important
question
that
we
wanted
to
get
solved
by
this
meeting
was
to
have
if
someone
is
willing
to
take
kind
of.
You
know
a
lead
in
that,
and
maybe
working
with
the
authors
of
these
proposals
to
come
up
with
like
consensus
or
which
all
proposal
we
can
move
towards.
A
C
Just
so
I
get
to
interject
here
real
quick,
I'm
not
here
for
a
one
time
adding
my
eip,
I'm
in
it
for
the
long
game,
and
I
am
totally
down
to
help
out
with
coming
up
with
that
chain
list
or
token
list
or
whatever
we
end
up
our
pc
list
standard
and
making
it
happen
and
actually
getting
it
implemented
in
wallets.
G
So
I
think
who
decided
to
schedule
this
for
half
an
hour?
What
kind
of
crazy
person
schedules
half
hour
meetings.
G
Coming
take
it
okay,
so
just
to
throw
a
wrench
in
in
this
conversation.
G
I
do
actually
agree
with
what
matt
was
saying
earlier
that
right
now
we
have
all
these
you
should
know
by
now,
matt
I
I
know
when
meetings
happen,
and
I
just
can
intuit
this
and
show
up
so
there's
this
issue
that
right
now
we
have
these
these
l2s
and
and
l1s
that
all
try
to
look
exactly
like
ethereum.
So
that
way
they
can
work
with
ethereum's
wallets,
and
the
reason
for
this
is
because
it's
much
easier
to
use
ethereum
wallets
than
it
is
to
build
your
own
wallet
for
your
own
ecosystem.
G
Right,
like
no
one
wants,
wants
to
build
their
own
metamask
and
their
own
coinbase
wallet
et
cetera,
et
cetera,
and
so
they
try
to
make
themselves
look
like
ethereum
this.
I
suspect
this
will
work
up
until
layer,
twos
start
to
get
actually
interesting,
and
I
think
they
are
going
to
start
to
get
interesting
sooner.
Rather
than
later
later,
when
I
say
interesting,
I
mean
on
these
layered
twos
you're
going
to
want
to
be
able
to
do
more
different
things.
G
You
cannot
do
in
layer,
one,
and
particularly
you
can't
do
an
on
ethereum
and
when
that
happens
like
this
all
breaks,
and
so
I
am
with
matt
that
I'm
a
little
hesitant
to
kind
of
go
down
this
path
of
standardizing,
this
behavior
of
like
setting
an
expectation
that
you
can
just
plug
an
rpc
into
a
wallet
and
it
will
just
work.
I
think
that
short
term.
That
is
true,
and
it
does.
G
I
think
that
in
the
next
five
years
that
will
no
longer
be
true,
and
we
will
have
standardized
the
thing
that
no
one
uses,
because
it
doesn't
make
sense
anymore,
because
layer,
one
long
term,
is
meant
to
be
the
settlement
layer.
It's
not
meant
to
be
adapt
player
like
it's
not
the
hope
is,
is
that
people
will
be
doing
all
their
dap
stuff
elsewhere,
which
means
the
set
of
things
you
might
want
to
do
when
interacting
with
your
chain
is
going
to
be
vastly
different
on
the
sediment
layer
versus
the
top
layer.
G
I
don't
think
we
solve
this
with
this
game.
I
think
this
is
a
fundamental
problem
with
like
long
term,
I
don't
think
you'll
be
able
to
have
one
wallet
that
was
designed
for
ethereum
and
use
it
for
solana
or
arbitram
or
optimism
or
stark
stark
net
or
whatever.
I
think
you'll
have
to
get
a
wallet
that
was
specifically
designed
to
work
with
dark
net
and
that
might
be
metamask.
G
Maybe
metamask
will
support,
you
know
stark
net
and
ethereum
and
arbitrom,
but
I
think
they
will
have
to
develop
for
each
of
them
individually,
and
so
I
do.
I
just
want
to
be
careful
that
you
know
we're
thinking
about
the
long
term
here
and
I
think
in
the
long
term,
this
whole
strategy
might
not
make
sense.
A
All
right,
so
I
know
we
are
not
going
to
get
a
solution
right
now,
but
at
least
we
get
some
points
to
maybe
proceed
further
yeah.
You
definitely
gave
us
food
for
that,
so
yeah.
What
do
people
think
about
having
a
call
in
next
two
weeks?
Is
that
something
reasonable?
I
know
you
requested
for
some
time.
Look
that
you
may
want
to
may
be
able
to
connect
with
other
wallets.
C
I
am
currently
in
talks
with
both
metamask
and
rainbow
to
get
the
appropriate
changes
made
and
to
get
the
ethiorl
parser
updated
everywhere,
to
be
able
to
support
not
only
actually
running,
custom
functions
of
smart
contracts
because
currently
take
metamask
for
an
example.
Only
transfer
and
approve
our
allowed
function
names,
and
you
know
that
needs
to
change.
C
We
need
to
be
able
to
run
any
function,
name
and
any
amount
of
arguments
and
any
duplicate
arguments,
so
I
am
definitely
involved
with
the
the
wallet
development
and
I
have
been
talking
with
people
at
both
rainbow
and
metamask
to
get
these
changes
into
the.
C
Those
changes
are
upgrading
to
typescript,
adding
a
bunch
of
extra
like
tests,
and
I
mean
shrinking
down
bundle,
size,
etc,
etc,
etc.
I
will
drop
a
pr
link
in
the
chat.
If
you
want
to
see
it.
A
A
All
right,
okay,
then
I
will
I'll
try
to
schedule
another
one.
We
will
definitely
share
the
information
in
the
way
we
have
shared
this
time
on
different
channels
and
invite
as
well.
So
if
anyone
wants
an
invite,
please
drop
email
address
to
me
on
discord
or
anywhere,
and
maybe
we
will
also
get
back
on
yeah
he's
not.
C
A
A
E
E
Yeah,
so
this
is
the
another
ui
standard
I
recently
proposed
and
also
covers
with
sandwiches,
and
the
basic
idea
is
try
to
basically
call
in
the
contract
and
is
able
to
translate
the
url
and
put
it
on
contract
and
then
pass
the
corresponding
data
return
to
the
user
and
one
application
I'm
thinking
about
is
because
we
are
developing
l2
with
a
large
storage.
On
top
of
that.
So
we
can
use
this
standard
to,
for
example,
so
we
already
built
a
gateway.
So
it's
not
working.
E
So
it's
able
to
basically
upload
a
whole
website
or
big
example.
The
example
to
query
account
wsdt
on
rigby
and
basically
call
in
the
balance
of
function
and
then
translate
the
corresponding
ns
address
to
the
corresponding
address
of
ether
and
return
corresponding
value
to
the
2566.
And
this
is
the
result.
E
E
So
basically,
we
created
this
kind
of
like
a
url,
so
that
when
users
want
to,
for
example,
locate
the
resources
on
the
easier
kind
of
like,
basically
you
can't,
but
in
web
2
we
have
dns,
we
have
iphs.
Now
we
have
contract,
we
have
enos,
so
we
are
able
to
translate
them
and
then
to
be
able
to
locate
any
resources
on
top
blockchain
and
then
display
it.
I
think
I
think
this
might
should
work
on
c
dns
domains.
E
So
this
is
example
that
we
upload
all
the
ems
website
on
top
of
encrypt
rinkeby,
and
so
we
user
can
just
type
it
using
kind
of
like
a
standard
browser
right
now,
it's
using
a
gateway
method,
and
this
will
basically
load
all
the
contract
from
the
from
the
ring
b
and
then
display
using
the
web
content.
E
G
E
Yeah,
that's
a
great
question,
so
first
like
ipfs.
That
means,
for
example,
it
requires,
for
example,
to
clean
the
data.
So
that
means
that
maybe
lost
and
further,
if
you,
if
I
use
a
want
to
upload,
for
example,
content,
it
has
switched
to
another
platform
while
in
this
way,
so
other
things
is
using.
The
basically
ethereum
stack
is
stored
on
the
ethereum,
and
so
we
use
it
doesn't
need
to
worry
about
whether
the
website
would
be
shut
down,
but
definitely
they
can
also
remove
the
website
by
distract
destroying
the
contract.
E
So
from
user
perspective,
it
doesn't
need
to
understand
other
techniques
that,
like
ipfs
filecoin
ar
it
just
stick
to
one
platform
and
do
whatever
they
want,
and
second
is
that
ffs
is
more
like
a
static
content,
so
people
post
the
content,
return
the
hash
aware
link.
But
in
this
scenario,
basically
user
can
interact
with
basic
dynamically,
create
all
the
content
return
to
the
user.
E
It's
kind
of
like
we
are
running
a
web
server
backed
by
evm
and
also
the
server
is
by
the
serum
all
the
nodes
in
the
network
rather
than,
for
example,
we
have
example
reference
pointer
and
point
to
the
ipfs
static
content,
but
we
are
not
able
to
modify
all
this
content
or
dynamic
generators
content,
but
fix
them
or
we.
If
we
want
to
compose
nft
based
on
different
state
and
yeah,
we
can
program
what
kind
of
a
return
data
svg.
E
Yeah
yeah,
that's
that's
the
basically
the
purpose
of
our
sidechain.
That's
doing
basically,
because,
like
my
understanding
that
l2
is
trying
to
scale
provide
scalability,
what's
good
is
in
terms
of
like
a
transaction
or
computation,
like
average
optimism,
another
way
is
feel
like
about
using
the
ethereum
technology.
E
G
Okay,
I
mean
the
certainly
more
power
to
you.
I
I
think
the
reason
no
one
has
worked
on
it
so
far
is
because
ipfs
does
a
great
job,
especially
with
the
introduction
of
filecoin
allowing
for
permanent
storage
at
paid
permanent
storage,
and
so
my
general
recommendation
is
to
figure
out
how
to
improve
the
ipfs
integration,
which
is
getting
better
all
the
time
like
you
know,
I
browse
all
the
apps
I
use
I
use
through
ipfs
already
and
it
works.
G
I
would
be
hesitant
to
go
down
a
path
of
trying
to
replace
that
without,
like
I
understand
the
desire
of
having
everything
on
ethereum,
but
I
don't
think
you're
going
to
gain
enough
to
be
worth
the
effort
like
building
a
storage,
decentralized
storage
system
is
a
huge
and
hard
project
and
ipvs
solved
it
well,
and
so
I'd
be
hesitant
to
try
to
replace
that.
I
think
there
are
other
things
you
could
replace.
That
would
be
much
more
valuable.
G
E
Yeah,
I
think
another
is
ar,
but
yeah
ipfs.
I
think
probably
that
that
I
really
like
that
they
work
in
some
direction,
but
but
like
let's
imagine,
let's,
for
example,
we
create
kind
of
like
dynamic,
blog
website,
that
is
on
top
of
the
like
this
technologies
or
versus
on
ipfs.
What
was
the
difference
there
because,
like
I
feel
like
if
the
user,
for
example,
when
I
create
a
blog,
I
need
to
go
to
ipfs.
E
I
need
to
click
someone
maybe
pin
this
or
maybe,
for
example,
to
pay
a
file
coin
to
ping
all
those
storage
rather
than
fixing
my
or
I
can
be
able
to
fix
my
post
like
or
retreat
just
following
the
smart
country,
logic
that
are
built
in
into
the
build
on
top
of
evm.
This
is
something
that
I
can
think
about
something
probably
from
maybe
different
in
terms
of
application
perspective,
yeah.
E
A
4804,
okay,
I
mean
I
may
have
missed
it.
I
will
like
to
add
it
here
in
the
list,
so
we
have
all
the
proposals
in
one
place:
okay,
cool!
Thank
you
for
sharing
this.
We
could
not
reach
to
the
conclusion
yet
like
which
direction
we
would
like
to
move,
but
it's
a
very
good
session
in
which
we
learned
about
some
new
proposals
solving
different
problems.
A
I
guess
we
can
have
another
meeting
schedule
two
weeks
from
now
in
which
we
can
probably
discuss
on
which
all
proposals
we
would
like
to
move
forward
with
and
if
there
are
authors
who
are
around
to
may
be
able
to
push
these
proposals
would
be
good.
If
not,
then
someone
from
whoever
joins
the
call
is
willing
to
be
a
champion
for
that
proposal.
A
That
would
be
helpful
because,
as
we
get
into
layer,
2
solutions
more
and
more,
it
will
be
useful
to
have
some
certain
standards
and
people
be
following
them,
although
I'm
not
sure
if
they,
if
one
proposal
will
be
able
to
solve
all
the
use
cases,
but
definitely
will
try
to
get
standard
depending
upon
use
cases
yeah,
I
know
our
light.
Client
has
dropped
off,
he
had
to
go
and
the
meeting
was
getting
for
30
minutes
only.