►
From YouTube: URL/URI standard working group meeting # 4
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/149
Working document - https://hackmd.io/@poojaranjan/URLWorkingGroup
A
All
right,
thank
you
all
for
joining.
This
is
the
fourth
meeting
in
the
direction
of
getting
uri
url
standards.
Moving
towards
final,
a
quick
recap
from
the
last
meeting
in
the
last
meeting
key
explained
eip
4804,
with
a
slides
presentation
greg
who
is
unfortunately
not
able
to
join
this
meeting
today.
He
had
some
question
in
the
last
meeting
about
this
proposal
like
what
would
be
the
biggest
benefit,
what's
the
main
problem,
that
dot
is
trying
to
solve,
etc.
A
So
he
recommended
to
reach
out
to
decentralized
projects
for
support
and
vital
adoption,
and
in
response
we
see
a
comment
added
to
agenda.
We
hope
to
hear
about
it.
The
progress
on
proposal
4804
in
a
bit
in
the
last
meeting.
We
did
not
get
any
update
on
eip
2400,
but
luckily
we
have
the
author
here
in
this
call.
A
So
hopefully
we
will
have
some
update
from
the
team
on
that
part
and
also,
a
few
weeks
ago,
a
discord
user
trezanya
shared
thoughts
on
this
url
uri
meeting
format
that
was
added
in
the
last
meeting
agenda,
but
we
could
not
get
to
that.
We
ran
out
of
time.
So
maybe
we
can
start
from
that.
I'm
hoping
that
it
will
be
a
quick
item
to
cover.
B
A
C
So
I'm
sort
of
coming
at
this
from
a
perspective
of
like
a
just
an
observer,
but
after
reading
some
of
the
url
uri
specification
proposals,
some
of
them
like
definitely
are
needed
and
that
they're
very
general
and
like
you
should
need
to
have
some
kind
of
common
denominator
there.
But
I'm
worried
about
presenting
like
a
useful
specification
for
wallet
developers
to
be
able
to
present
to
users
like
enough
information.
C
This
amount
here
is
much
easier
for
a
wallet
to
understand
what
it's
supposed
to
do
than
saying
call
this
function
on
this
contract
whatever.
So,
if
you
have
a
higher
level
concept
like
that,
it
makes
it
easier.
So,
like
the
example
I
gave
in
in
the
dock
that
I
wrote
up
is
say
you
have
funds
on
polygon,
but
someone
wants
to
receive
them
on
arrange
from.
If
you
just
say,
call
this
function
on
this
contract
in
arbitrary,
a
wallet
could
go
and
figure
out.
C
C
C
So
what
the
lightning
invoice
format
did
is
it's
all
just
binary.
The
entire
thing
is
just
a
binary
representation
and
it's
pretty
compact
and
then
you
encode
it
in
a
opaque
format,
called
dec32,
and
so
that
can
be
turned
into
a
url
just
by
prefixing,
lightning
on
it
and
it's
fine
and
it
works
like
that.
But
a
lot,
I
I
don't
think
tying
ourselves
to
encoding
the
directly.
C
The
data
directly
in
the
url
format
is
like
really
worth
the
cost
of
the
added
complexity
and
clunkiness
and
thinking
about
like
oh,
maybe
we
should
just
be
communicating
this
data
in
a
more
opaque
way.
That's
harder
to
misuse
and
just
saying
everyone
just
rely
on
the
library
to
decode.
Instead
of
you
know,
trying
to
do
it
themselves.
C
D
Interesting,
okay,
I
I
feel
like
I
can
agree
with
you
on
the
encoding
data
as
a
more
of
an
opaque
chunk
right,
because
I
feel
like
with
the
current
url
specs
having
written
one
of
them.
It
is
kind
of
frustrating
to
have
to
somehow
try
and
make
it
fit
into
the
whole
http
like
url
version
right
where
the
original
eip.
D
I
don't
have
the
number
in
my
head,
real,
quick,
but
there's
an
eip
that
essentially
describes
ethereum,
colon
whatever
and
then
we've
kind
of
just
started,
attaching
prefixes
and
adding
payloads
and
then
defining
that
whole
payload
section,
but
making
it
look
similar
every
time
and
there's
a
bunch
of
discrepancies
there.
So
I
feel
like
I
can
understand
with
that.
I
do
not
think
I
can
fully
agree
or
get
behind
the
idea
of
the
the
the
vagueness
there
like.
D
Right
is
usually
trying
to
tell
the
wallet
to
do
action
x
and
to
do
it
this
exact
way
right
and
if
you
give
the
wallet
more
freedom
of
interpretation.
So
an
example
of
that
would
be
metamask.
Current
implementation
of
the
681
spec
right,
where
they're
only
taking
parts
like
certain
parameters,
they
accept
certain
parameters,
they
just
don't
filter
for
and
they
kind
of
just
ignore,
which
means
we
have
different
results
on
each
wallet.
I
feel
like
if
we
clearly
just
said
this
is
the
payload.
This
is
the
address.
This
is
the
function.
D
C
So
if
you
have
a
high
level
presentation
of
what
it's
doing
saying
like?
Oh,
do
you
want
to
transfer
funds
here
to
here
to
here
it's
easier
for
the
walt
to
figure
out
what
to
do
than
if
it
has
this
blob
of
data
and
needs
to
somehow
like
communicate
back
to
the
host
and
then
that
communicates
to
the
chain
to
try
to
figure
out
what
it's
actually
doing,
so
it
makes
it
harder
for
it
to
present
a
richer
interface
to
the
user.
D
Because
you
were
you're
the
author
of
2400,
correct
yeah
for
transaction
receipts
right
so
trey.
I
don't
know
how
much
you've
you've
read
up
on
the
the
url
standards
that
there
are
right
now,
because
there
are
quite
a
few
and
they're
quite
some
places
overlap.
Some
places
are
there's
discrepancies,
but
an
example
would
be
like
2400,
which
ricardo
correct
me
if
I
say
anything
wrong,
but
is
for
receipts.
D
So
if
somebody
were
to
click
that
url
or
open
the
url
in
an
app
or
scan
the
qr
code
or
whatever
they
are
taken,
at
least
the
idea
is
that
they
would
be
taken
to
a
screen.
That
shows
you
the
overview
of
that
specific
transaction
and
what
happened
there,
whether
that
be
cached
on
the
device
or
fetch
from
unchained,
so
that
is
kind
of
like
one
of
the
higher
level
actions.
We
have
an
ad
ad
chain
url.
D
We
have
a
initiate
transaction
url,
which
is
pretty
arbitrary
already,
but
it
does
fit
in
a
certain
like
pattern
right.
The
http
pattern
I
mentioned
before
so
it
would
be
nicer
if
we
could
take
all
of
these
actions,
which
are
kind
of
like
a
mix
between
high
level
and
low
level,
because,
like
a
high-level
interaction,
is
the
view
of
the
transactions,
for
example,
where
like
it
is
fully
up
to
the
wallet
to
say:
oh
hey,
this
function,
name
was
transfer,
so
it
was
probably
a
transfer
and
this
contract
is
erc20.
D
C
To
occur
on
chain
so
like
I've,
I
haven't
read
all
of
the
oral
specs,
but
like
high
level
actions
like
2400
like
yeah.
That's
that's,
definitely
good
and
it's
like
much
more
unambiguous
about
what
is
actually
presenting
so
yeah.
I
just
want
to
like
ensure
that
people
like
extend
that
thought
process
to
like
comment
like
payment
requests.
I
think,
are
like
the
current
like.
E
I
think
that
a
good
analogy
to
what
we
have
now
in
web
2
is:
we
have
post
requests,
so
these
this
transactions
request
should
be
something
like
a
transaction
request,
but
of
course
we
are
not
sending
it
to
the
server.
We
are
sending
it
to
the
the
client
to
authenticate
it.
So
it's
the
totally
different
ui
ux,
but
the
the
tools
that
we,
these
urls
and
url
eyes,
are
tools
that
the
developers
of
the
apps
and
wallets
would
use
to
coordinate
what
they
want.
E
The
user
knows
that
that
that
a
system
is
outdated
and
yeah
that
that
I
think
that
that
urls
and
your
uris
are
are
very
important
and
they
they
can
be
useful
tools.
I
agree
with
you
that
there
are.
There
are
other
ways
we
can
do
with
that,
but
the
the
proposal
here
is
actually
to
instantiarize
the
everything,
so
the
wallets
can
be
consistent
across
each
other,
at
least
in
the
important
things.
D
D
We
got
through
reviewing
them,
but
then,
if
I
recall
correctly,
bruno
went
on
vacation
or
something
so
they
haven't
been
merged,
so
they've
been
open
for
a
month,
but
those
editions
would
add,
support
for
2400
for
5094
and
better
support
for
681
and
currently
metamask
and
rainbow.
As
of
my
knowledge,
both
use
this
library
and
I'm
sure
that
there's
probably
a
few
other
wallets
out
there.
D
Bits
define
the
action.
The
second
couple
bits
whatever
right
like
that
sense
and
be
able
to
do
a
lot
more
compact,
we'll
be
able
to
add
that
into
the
library
here
and
then
get
every
wallet
to
upgrade
their
packages
and
build
their
own
uis
accordingly.
But
at
least
they'll
have
one
standard
way
to
do
it
right
and
we
won't
have
to
rebuild
support
across
20
different
platforms.
C
Package
for
it,
I
I'm
not
saying
like
oh
you're,
not
trying
to
do
any
of
these
things
right
now.
I
just
want
to
make
sure
that
people
understand,
like
my
perspective,
on
it
as
someone
that
might
be
building
a
wall
in
the
future
that
wants
to
do
like
aggressive
cross
chain.
I
I
have
another
document
that
I
was
working
on,
describing
like
my.
I
have
some
comments
about
the
current
state
of
wallet
so
but
that's
not
ready
for
to
be
shared
yet
so
I
might
have
more
right
discussion.
D
So
now
that
you've
you've
sparked
the
thought
of
like
the
way
that
lightning
does
it
right,
because
you
mentioned
something
about
that,
I
thought
back
to
reading
the
spec
for
how
the
lightning
qrs
work
and
like
what
is
it
bip.
I
don't
know
something
like
that.
Some
one
of
the
bips
about
the
the
actual
like
how
bitcoin
and
lightning
do
their
qr
code
urls,
and
I
honestly
would
have
to
agree
that
you
know
if
we
can
make
it
smaller.
D
E
So
I
noticed
that
that
might
might
have
a
use
case
where
the
wallet
it's
the
receiver
of
the
transaction
is
offline
or
doesn't
want
the
transaction
to
be
automatically
submitted
for
some
reason.
So
perhaps
perhaps
I
don't
know
if
it
should
be
included,
or
maybe
it's
another
url
standard
of
the
raw
transaction.
So
instead
of
publishing
the
the
transaction
and
delivering
the
hash,
the
the
app
could
deliver
the
designed
transaction
back
instead
of
automatically
submitting
it.
I
don't
know
if
this
is
should
be
considered,
but
yeah.
E
D
I
think
if
we
want
it
to
go
such
a
way
if
we
make
some
kind
of
rewritten
like
pure
compact
data,
right,
opaque
data,
url
format
where
we
are
like
making
a
transaction
request,
we
could
probably
literally
take
all
that
data
change
one
bit
around
to
now
signify
that
it
is
a
receipt
and
then
the
wallet
should
just
be
able
to
read
it
with
the
exact
same
code
and
instead
of
showing
it
as
a
hey.
Please
make
this
transaction
they'll
show
it
as
a
hey.
This
user
made
a
transaction.
D
E
Or
not,
it
would
be
valid
and
it
actually
went
through.
No.
The
dependent
the
sender
address
is
the
you
can
retrieve
through
the
signature,
because
the
raw
transaction
contains
the
all
the
data
the
in
the
signature
to
that
transaction.
So
you
you
only
need
yeah,
you
would
be
just
replacing.
Instead
of
putting
a
hash
of
the
transaction
would
be
to
put
the
right
transaction
there,
but
yeah
it's
there.
There
is
a
lot
of
concerns
on
that,
so
I'm.
I
feel
that
I
should
not
add
this
use
case
here,
so
just
to
keep
it
simple
right.
D
Right,
but
if
we're,
if
we're
going
to
do
something
like
rewrite
the
entire
idea
of
of
urls
right
and
try
and
make
these,
I
mean
my
brain
really
here
is
thinking
about
qr
codes,
because
we
want
to
keep
them
as
small
and
readable
as
low
detail
as
possible
right
because
that
improves
camera
usability,
etc
and
a
lot
of
things
for
users.
How
would
we
go
about
that?
D
Do
we
I
mean,
I'm
sure
we
probably
don't
want
to
write
an
entire
eip
during
this
call,
but
I'm
sure
we
could
come
up
with
some
ideas
right.
Let's
say
we
started
writing
such
an
eip.
What
would
be
what
would
be
key
things?
Do
we
designate
a
certain
amount
of
bits?
Do
we
do
we
take
any
inspiration
from
the
way
lightning?
Does
it?
What
do
you
guys
think.
E
So
I
I
think
that
there
is
a
simple
way
would
be
to
have
a
standard
that
would
specify
a
compact
version
of
all
the
other
urls.
So
in
the
same
file
format
that
you
have
json
versus
bson,
that
is
binary
standard
object.
You
have
the
javascript
notation
object
so
on
it's,
it's
just
a
compressed
version
and
then-
and
maybe
you
can
even
use
another
compression
algorithms
like
for
example,
instance
7-zip.
I
don't
know
anything
right
that
that
we
wanted
and
then
yeah.
We
can
do
that.
C
So
a
few
of
the
types
are
obviously
like
destination
pub
key
there's
a
couple
different
like
route
hints,
which
is
a
lighting
specific
thing.
There's
a
purpose
field
that
you
can
have
in
this
case.
We
probably
don't
need
that,
but
and
then
obviously
quantity,
so
for
what
I
think
you
would
want
for
like
a
payment
request
in
this
case
are
the
same
basic
ones,
about
destination,
address
and
quantity
and
asset
type.
C
C
You
can
send
it
to
me
on
and
I'd
like
decide
that
that's
like
a
valid
place
to
send
the
funds
so
that
sort
of
expands
the
possibility,
like
I
don't
know
how
you
would
represent
that
in
the
url
in
an
elegant
way,
and
since
it's
already
like
in
the
byte
format,
it's
all
binary.
You
don't
need
to
worry
about
extra
compression,
since
it's
all
probably
just
hashes
or
pokeys
anyways,
those
don't
compress,
and
so
you
don't
really
get
any
inefficiencies
there.
When
you
try
to
encode
into
the
32.
C
D
Okay,
let's
chat
about
if
we
want
to
make
it
more
compact
right
and
you
think
besan
is
not
going
to
cut
it.
I
have
the
the
both
11.
I
sent
the
link
in
the
chat
there.
We
go
difference
between
jason
and
bson
as
well:
four
different
providers
right
for
different
layer,
twos
and
roll-ups,
etc.
Would
we
store
that
as
chain
id?
Do
we
need
more
data
than
just
the
specific
roll-up
like?
E
D
D
E
Yeah,
I
I
agree,
but
I
I
kind
of
like
that
is
kind
of
user
readable.
But
that
is
correct.
I
I
mean
like
and
when
I
say
see
some
urls
I
can
read,
and
then
I
like
user,
readable
urls
and
that's
that's
a
technique
on
web
development,
but
I
don't
like
when
I
have
a
url.
That
is
a
lot
of
clunky
data
that
I
don't
understand.
F
D
No,
no,
I
mean
yeah
that
could
save
some
characters.
I
think
the
the
way
that
bolt
11
is
doing
it.
If
I'm
not
mistaken,
is
there
they're
going
like
the
ultimate
minimum
character
route
where
they're
putting
like
lnbc
as
a
prefix?
So
it's
lnbc,
then
it's
one
as
a
32
separator.
So
lnbc1
is
the
beginning
of
all
of
their
things
and
then
there's
a
time
stamp.
E
D
Fair
but
like
for
the
current
example,
which
really
frustrates
me
about
681
in
the
http
spec
when
query
parameters
have
the
same
key.
So
if
I
have
like
some
url
question,
mark
hello
equals
foo
and
by
equals
bar,
then
that
would
work
and
it
would
convert
that
to
an
object
where
hello
equals
foo
and
by
equals
bar.
But
if
I
make
hello
happen
twice,
it
will
only
take
whatever
the
library
decides.
First
one
our
last
one
right
and
the
problem
with
that
is
that
in
681.
D
D
D
D
E
So
I
can
just
I
just
have
to
make
the
commit
to
lascaux
right
that
that
that's
you
said,
okay,
I
want
to
move
forward
on
it,
but
I
I
I
I
don't
know
if
it
should
go
to
lascaux,
because
I
see
that
there
are.
There
is
a
lot
of
discussions,
but
if,
if
we
plan
to
like
make
make
a
compact
version
of
the
urls,
then
I
think
that
we
can
stick
how
it
is
now
and
maybe
later
we
figured
out
this
this
problem
off.
A
So,
just
a
correction
here
to
make
sure
that
this
proposal
I
mean,
like
you
and
your
co-author-
are
interested
in
moving
ahead.
This
proposal,
you
do
not
have
to
move
it
to
last
call,
because
last
call
is
a
stage
where,
when
proposal
is
all
ready-
and
we
are
only
waiting
for
14
days
to
get
it
merged
towards
final,
so
the
best
thing
for
you
to
do
right
now
would
be
to
move
it
to
the
review
status.
That
will
help
all
eip
editors.
A
E
A
And
yeah
look
as
we
are
discussing
that
there
there
could
be
some
improvement
that
we
can
probably
use
in
the
direction
of
creating
a
better
proposal.
In
my
personal
opinion,
please
correct
me:
someone.
It
should
not
stop
any
other
proposal
moving
towards
final,
which
are
already
existing
and
has
certain
use
cases.
So
we
can
both
work
in
parallel.
D
However,
we
are,
as
discussed
a
second
ago
looking
into
potentially
making
a
new
eip.
That
would
be
some
composite
of
the
ones
we
have
right
now,
but
rewrite
them
in
a
more
compact
binary,
like
format
or
or
opaque
format.
To
an
extent
the
specifics
of
what
this
format
would
look
like
is,
I
don't
think,
we've
fully
thought
about
or
decided
on
yet.
F
C
A
Awesome
so
eap,
2400
is
already
getting
support
and
you
already
have
written
library.
So,
let's,
let's
keep
that
proposal
moving
ahead
and
about
the
proposals
that
we
are
discussing
now.
I
think
it
would
be
a
good
idea
to
maybe
start
a
thread
on
fellowship
of
a
theory
musician
to
create
a
new
proposal.
We
can
probably
collect
some
feedback
and
thoughts
over
there
and
once
that
is
firm
enough
to
be
converted
into
a
draft
form.
Maybe
you
can
create
the
pull
request.
A
A
A
Yeah,
thank
you
one
other
thing.
We
have
another
proposal
for
eight
zero
four.
Is
it
yeah
four
eight
zero?
Four.
I
think
he
is
on
the
call
and
he
has
a
presentation,
slides,
google
slides
that
he
had
added
to
the
agenda.
I'm
not
sure
he
would
you
like
to
maybe
talk
about
the
development
or
the
progress
since
the
last
meeting.
F
F
I
basically
summarize
some
motivations
and
applications,
and
also,
I
also
summarize
some
upgrade
updates
that
I
basically
since
last
meeting
roughly
three
weeks
ago,
and
so
so
let
me
move
on
so
one
thing
that
we
feel
that
is
missing
in
the
current
experience,
like
a
lack
of
decentralized
presentation.
What
it
does
is,
basically,
it
can
directly
locate
and
render
a
web
content
generated
on
chain.
One
example
that
we
are
seeing
more
application
is
going
on
is
the
nft
svg
files.
F
F
Oh,
this
is
something
interesting
application
that
they
are
creating
ft,
but
they
basically
upload
all
the
media
data,
the
savg
layers
on
top
of
the
ethereum,
and
then
the
narrative
is
that,
because
we
have
all
the
data
put
on
chain,
so
newton
you'll
never
be
worried
about
losing
your
media
files.
When
you
buy
ft
the
mt,
including
encounter
esc
7
2021,
together
with
your
media
day,
files
is
on
chain.
F
So
when
we
read
this
news,
oh
this
is
really
interesting
application,
and
so
we
take
a
look
at
their
contract
and
see
how
it
works,
especially
how
they're
able
to
display
the
this
on
chain
basically
generated
nft
media
files.
So,
let's
just
take
a
random
token
id.
Then
we
take
a
look.
The
there's,
I
think,
there's
a
mid
image
fill
here
and
we're
surprised,
they're
actually
still
using
ffs
to
tell
the
openc
to
say
hey.
F
F
So
basically
there's
a
position
pointer
that
tells
what's
the
range
of
this
ft
so
just
repeatedly
calling
this
index
pointer
and
then
it
will
basically
render
these
files
one
by
all
the
files
like
just
like
binary
and
sequentially,
and
then
once
it's
done,
then
we
have
all
the
ft
that
is
svg
generated
change.
But
unfortunately,
since
we
don't
have
a
way
to
directly
display
this
content
on
top
of
ethereum.
F
So
so
I
guess
so
they
have
to
still
rely
on
rtfs
and
said
that
once
ipfs
fix
some
data
is
may
lose
may
disappear.
Then
the
user
has
to
re-upload
this
content,
that
store
on
exterior
and
and
to
do
so.
So
this
is
one
thing
that
I
feel
like.
We
should
have
something
that
can
directly
point
to
the
basically
the
the
web
content
that
generated
on
ethereum
and
without
using
external
external
example,
services
like
ipfs
or
centralized
servers.
So
this
is
one
thing
that
we
feel
we
can
do
better.
F
One
part
is
using
the
blockchain
store
as
a
block
store
and
so
that,
if
he
has
silver
comments,
saying
that
he's
maintaining
a
copy
of
his
blog
on
ipfs,
but
it's
very
slow
and
then
sometimes
you
might
the
files,
maybe
jump
off,
and
if
that
is
flexible,
able
to
jump
the
entire
block
about
blockchain.
And
that
means
you
can
say
the
whole
problem.
F
So
one
crazy
idea
is
that
suppose
we
could.
We
are
able
to
dump
all
the
blocks
or
fix
some
websites
like
ens
unit
swap
on
blockchain,
but
how
we
are
able
to
locate
them
and
be
able
to
render
them
in
a
completely
centralized
way.
I'm
definitely
using
example,
json
us
json
rpc,
with
curl
core
or
is
a
scan.
It's
now
an
app
option
for
users.
We
need
kind
of
like
a
way
that
allows
end
users
to
directly
access
the
blocks
access
the
generated
svgs
directly
on
chain.
F
F
F
F
F
So
for
the
cyberbrokers
we
take
a
look
at
their
contract
and
then
so
we
write
write
a
simple
contract
which
basically
has
one
method
called
random
broker.
We've
taken
a
token
id
which
will
recursively
call
their
method,
which
is
the
regular
method
and
then
be
able
to
concatenate
all
the
basically
binary
data
they
return
and
put
return
with
a
single
svg
binary
data,
and
then
we
register
this
exclusive
cyber
brokers,
the
bns
name
and
points
to
this
random
contract
that
we
deployed.
F
So
now.
With
this
this
thing
now
we
are
able
to
using
the
erc4042
directory,
for
example,
random
this
this
svg
directory,
so
that
it
translates
to
a
gateway.
So
I
just
replace
the
gateway
with
f3
and
tells
taiwan
to
call
this
counter
its
method
and
the
trip
id
without
by
specifying
the
return
types,
then
we
will
treat
it
as
a
web
content
and
the
browser
will
automatically
detect
this
and
then
display
in
svg
image
format.
And
so
all
these
things
are
generated
using
the
smart
contract
and
display
directly
on
the
browser.
F
So
so
this
is
one
example.
So
we
hope
that,
with
this
standard
for
the
project,
they
are
using
the
composable
svg
onto
blockchain.
Now
they
are
fully
be
able
to
replace
the
ipfs
or
any
centralized
address
to
the
proposed
elc4804
addresses
with
the
corresponding
message
to
how
to
call
the
contract
and
render
it
in
a
decentralized
way.
So
this
is
one
application.
F
Another
application
is
a
personal
blog
study
website,
just
like
the
test
blog.
So
we
make
an
experiment.
We
download
all
the
vitalx
blocks
by
including
500
files
with
36
megabytes
data.
Then
we
upload
all
the
files
to
a
special
contract
that
we
create,
that
is
able
to
host
these
files,
and
they
are
the
path
in
all
information
and
on
wrinkly
testnet,
and
then
we
are
able
to
redispel
by
a
form
for
that
matter.
That's
quite
different,
because
we
want
to
support
directory
structure
and
absolute
relative
parting.
F
So,
for
example,
here
is
the
erc404
link
which
points
to
the
basic
special
contract
that
we
created
and
which
will
basically
goes
to
the
retarding
homepage
that
host
it
on
the
winky
beam,
and
I
can
go
to
the
example,
the
article
that
I
just
browse
and
that
is
also
basically
store
on
top
of
blockchain.
But
here
we
see
that
here
it
goes
to
the
basically
additional
basic
paths
that
will
be
passed
to
the
contract,
including
the
core
data,
and
the
good
thing
of
this
is
that
it
can
support
relative
particle.
F
The
image
in
the
basically
in
the
original
vitalix
file
is
a
relative
parting,
which
contains
the
parents,
parents,
parents,
directory
and
images
and
some
files
and
in
browser
it
will
automatically
basically
given
this,
it
will
automatically
translate.
According
to
the
url
uii
specification,
translate
to
the
corresponding
caller
pro
protocol.
Specific
relative
passing
to
this
link,
and
this
link
will
also.
F
F
Using
the
contract,
and
instead
of
using
the
storage,
local
storage,
then,
and
then
it
it
will
roughly
save
roughly
one
third
of
the
gas
cost
in
just
native
ethereum
storage
case.
But
definitely
we
are
thinking
about
in
the
future.
Yes
in
the
future
of
issue,
and
then
we
are
able
to
use
in
the
shoddy
day
blocks
all
even
with
the
serum.
For
example,
some
l2
scaling
solutions
that
we
are
able
to
write
which
is
friendly
for
decentralized
storage.
F
Yeah,
and
so
this
is
something
like
crazy
ideas,
say
hey,
if
suppose,
now
we
have
a
blockchain
that
is
able
to
have
this
capacity
now
they
are
acceptable
to
a
lot
of
interesting
applications.
So
here
I
will
give
a
interesting
application
is
that
we
are
able
to
create
some
implication.
That
is
more
user-friendly.
F
Yeah,
but
that
that
means
that
they
either
will
rely
on
customers.
If
we
really
want
to
save
in
icfs.
That
means
we
either
rely
on
centralized
server
like
some
universe,
xyz
or
we
need
some
cri
like
some
of
what
we
talking
is
doing
so,
and
so
here.
I
give
example
that
we
are
able
to
create
some
decentralized
applications
that,
without.
B
F
Yeah
so
now
I
am
able
to
have
to
create
this
block
without
just
using
wallet
without
any
other
example,
ci
other
options,
and
then
I
can
browse
it.
I
actually
have
browsing
this.
This
block
doesn't
need
any
wallet
because
it
can
just
using
the
web3
url
to
directly
access
all
the
content
without
any
wallet.
But
if
I
want
to
modify
this
car
this
this
block,
then
definitely
I
need
to
have
a
wallet
that
helps
me
to
submit
a
transaction.
F
F
F
F
F
To
start
a
service
to
support
it,
and
they
also
a
casa
saying
that
how
we
are
able
to
generalize
this
particle
to
multiple
chains
like
including
solana,
including
phantom
others,
and
then
also
regarding
the
com,
some
link
space
reserve
assignment
for
this
url
and
then
also
asking
questions.
How
you're
able
to
ensure
fully
trusted
access
in
in
case
giveaway,
is
lying
and
also
how
how
to
have
some
question
regarding
what
the
input
argument
should
be
and
then
how
we
are
able
to
support
additional
features.
A
Thank
you.
Thank
you
for
sharing
all
these
information
and
I
have
a
question
for
you.
Maybe
I
was
looking
into
the
discussion
to
link
that
is
provided
here,
as
you
mentioned,
that
there
are
quite
a
lot
of
interest
and
comments.
This
proposal
has
received
there,
but
this
proposal
is
also
in
the
draft
status.
Yeah
yeah.
I
wonder
if
you
think
that
it
is
ready
enough
to
be
like
getting
more
comments,
feedback
on
it.
Maybe
you
would
want
to
move
it
to
the
review
status.
F
A
A
I
know
okay,
fine,
no,
the
question
was
for
eap
editor,
but
I
just
remember
that
this
is
an
erc,
so
maybe
micah
may
not
have
looked
into
detail
of
the
proposal.
However,
I
will
if
you
would
create
a
pull
request.
We
can
probably
bring
this
to
the
next
tuesdays
meeting
discussion,
which
is
a
eip
editor's
apprenticeship
program,
but
we
generally
try
to
look
into
the
full
request
of
all
erc
category
of
proposals
and
if
there
are
any
further
feedback,
we
can
share
it
with
you,
but
it's
totally
up
to
author.
B
B
A
C
A
All
right
well,
thank
you
so
much
it
looks
like
people
are
divided
here.
Some
some
may
think
that
there
are
certain
proposal
in
which
getting
into
details
and
lower
level
may
be
useful.
However,
there
could
be
certain
proposals
which
may
use
on
the
higher
level
instructions
not
getting
into
the
details,
so
we'll
see
how
proposals
are
being
drafted
and
proposed,
and
definitely
up
to
eip
editors
to
make
the
decision
well.
Thank
you
all
for
joining
us
today
and
we
hope
to
have
next
meeting
two
weeks
from
today.
That
is
july.