►
Description
Identity, Capabalities, & Private Data - presented by @expede at þing 2022 - Building Apps on IPFS - https://2022.ipfs-thing.io
A
After
that
round
of
intros,
I
wish
that
I'd
made
this
like
more
philosophical,
but
this
slot,
or
at
least
the
description
in
the
schedule,
is
mainly
about
you
know.
Some
of
the
people
are
building
platforms
to
do
apps
on
ipfs
and
seeing
how
we
can
you
know,
do
cross-pollination
and
work
and
help
each
other.
So
this
is
essentially
a
mainly
a
technical
review
at
roughly
breakneck
pace
to
see
where
there
might
be
points
of
overlap.
A
But
again,
please
do
ask
questions
along
the
way
and
if
we
go
totally
off
from
these
slides,
it's
fine
by
me.
So
the
web
native
sdk,
which
is
the
name
for
or
the
umbrella
term,
for
a
bunch
of
stuff
that
we're
building
over
at
fission,
which
is
a
portable
edge,
stack
or
just
an
encrypted
at
rest
file,
system,
location,
independent
user,
controlled
data,
self
modifying
apps
and
services
off
protocol
in
a
trench
coat.
A
I'm
brooklyn
zelenka,
I'm
the
cto
at
vision
and
where
we
started
with
all
of
this
stuff
was
looking
at
a
lot
of
people
in
the
web
through
space
were
struggling
to
build
sort
of
classic
web
2
apps
and
we
were
looking
at.
You
know
a
lot
of
the
tech
and
said
well.
This
should
actually
make
things
easier
right
as
much
as
we
care
about
decentralization
and
security.
A
That's
a
little
bit
like
you
know,
eating
your
vegetables
right
like
it's
something
you
should
do
but,
like
you
know,
people
say
they
like
security,
but
they
don't.
They
don't
behave
like
they
do
right,
like
lots
of
people
use
facebook
literally
billions
of
people
use
facebook
on
a
daily
basis.
So
how
can
we
make
things
not
just
better
from
a
security
and
decentralization
point
of
view,
but
like
what's
the?
How
can
we
make
people's
lives
better
on,
like
literally
a
day-to-day
basis
right?
So
the
original
idea
was
this.
A
Is
you
know
sorry,
your
typical
web
2
stack
today
has
all
these
parts
in
the
middle
and
that's
a
lot
for
people
to
have
to
train
hire
for
maintain
all
the
stuff
in
the
stack
you
know
suddenly.
Now
you
have
to
do
all
this
devops
stuff
these
days,
in
addition
to
just
trying
to
get
an
app
to
your
users
right
and
by
using
some
of
these
newer
techniques
and
newer
technologies.
A
I
think
we
can
shrink
this
down
and
make
it
so
that
it's
building
an
app
on
the
web
or
on
a
desktop
is
essentially
the
same
right.
We
can
make
everything
feel
like
like
an
ios
or
android
app
everywhere
and
then
the
the
actual
benefit
this
would
then
bring
to
people
is
that
they
have
much
faster
iteration.
You
don't
have
to
train
them
in
all
of
these.
You
know
you
have
to
become
a
full
stack,
dev,
plus
devops,
plus
all
these
other
things
you
focus
on
the
users.
A
You
can
respond
to
their
feedback
much
faster
and
you
have
a
lower
barrier
to
entry
right.
So
if
we
think
software's
going
to
eat
the
world,
we
need
to
train
a
lot
more
people
a
lot
faster
right,
high
level
dependencies.
We
have
always
wanted
to
get
to
compute,
but
to
do
compute
you
need
to
do
data
and
to
do
data
in
production.
A
You
need
some
sort
of
auth
system
so
that
people
can't
look
at
all
of
your
all
of
your
files,
so
we
ended
up
building
it
in
roughly
this
order
off,
then
data
then
compute.
A
This
is
the
stack
that
ended
up,
resulting
from
that
we're
not
all
the
way
through
this.
Yet
we're
about
roughly
here
working
from
the
bottom
up
so
and
we'll
we'll
touch
on
a
bunch
of
these
throughout
this
presentation,
so
using
dids
for
identity
tree
modified
cryptotree,
you
can
networking
this
durable
file,
store,
which
I
talked
a
bunch
about
yesterday.
So
I'm
gonna
skip
like
mostly
over
that,
but
that's
the
web
data
file
system.
A
We
have
offline
and
async
sharing
and
we're
now,
starting
on
a
scalable
fully
distributed
database,
local
first
on
top
of
ipfs
as
well,
and
we
will
eventually
get
to
that
portable
compute
section
near
the
top
there
and
then
there's
this
nice
line
and
then
abstractions
to
get
that
into
developer's
hand,
so
that
they
don't
need
to
know
that.
A
There's
this
towering
stack
of
things
underneath
in
terms
of
actual
experience,
the
end
goal
right
is
to
make
it
so
that
people
don't
have
to
know
that
there's
something
special
happening.
So
sorry,
I
didn't
create
a
new
demo.
This
is
from
a
previous
presentation
where
it
just
looks
like
a
regular
app,
but
the
data
underneath
is
owned
by
the
user
and
portable
between
apps.
So
here's
that
file
from
the
previous
app
and
we
can
now
load
it
up
in
this
sort
of
file,
explorer
view
or
have
data.
A
You
know
the
user
gets
to
see
essentially
almost
like
an
oauth
login
right
and
loads
of
music
into
a
music
app
right.
So
this
this
kind
of
thing.
A
So
starting
with
that
bottom
of
that
that
three-layer
stack
authorization
and
authentication.
A
Because
we
decided
to
start
with
the
web,
that
meant
that
we're
working
in
browsers
and
browsers
are
extremely
hostile
environments
and
doing
key
management.
Here
is
hard
right
and
in
terms
of
threat
model.
The
biggest
problem
that
you
can
have
is
somebody
runs
off
with
your
keys
right,
so
it
doesn't
matter
how
secure
your
key
is.
If
somebody
has
it
they,
you
know:
they've
installed
a
malicious
extension
into
your
browser
or
their
app
is
going
to
go
around.
You
know
collecting
your
keys,
you're
essentially
hooked.
A
So
if
we
have
this
malicious
user
they're
trying
to
get
to
that
key,
but
with
the
web
crypto
api,
we
have
non-extractable
keys,
so
that
sits
behind
this
barrier,
and
you
can
then
pass
the
things
to
sign,
but
they
never
actually
get
direct
access
to
this
key.
So
we
put
a
line
in
the
sand
right
at
the
beginning
for
anything
that
needs
signatures.
It
has
to
not
have
exportable
keys
for
encrypted
data.
We
don't
really
have
a
choice
right.
A
You
need
to
hand
a
key
around
to
somebody
else
so
that
they
can
decrypt
it,
but
for
signatures.
Everything's
done
this
way.
Now,
when
you're
not
moving
keys
around,
but
you
still
need
identity,
there's
two
ways
of
doing
this:
one
is
with
dids
and
then
you're
going
to
register
all
of
these
keys
to
a
single
identity,
and
then
the
other
is
with
capabilities
so
dids,
broadly
it's
a
standard
from
the
w3c
and
actually
has
tons
of
adoption.
A
So
microsoft,
bunch
of
governments
are
using
it
and
it's
also
based
on
public
key
crypto,
and
you
end
up
with
the
document
that
essentially
says:
here's
the
identifier
and
all
of
the
keys
that
are
associated
with
it.
Currently
we
technically
use
these,
but
only
the
id
key
is
just
a
wrapper
around
just
a
single
key
and
using
ucan,
which
we'll
talk
about
in
a
second.
We
transfer,
not
the
identity
around.
In
fact,
we
don't
really
care
so
much
about
who
the
user
is.
We
transfer
the
authority
around
only
now.
A
The
other
advantage
of
that
is.
You
can
register
the
same
user
into
multiple
apps
and
you
know,
let's
say
boris
has
an
app
and
he
wants
to
share
some
capabilities
with
me.
We
don't
have
to
create
some
sort
of
shared
user.
A
To
do
that,
we
can
just
pass
around
the
little
bits
of
things
to
each
other,
so
it
ends
up
being
very,
very
flexible
and
you
can
do
things
like
progressive
accounts,
so
somebody
can
show
up
not
sign
up
at
all
start
using
the
app
immediately
and
if
they
later
want
to
register
a
username,
that's
the
thing
that
they
can
do,
but
they
don't
have
to
they
don't
have
to
register
anything
with
anybody
by
default.
There's
often
reasons
that
you
want
to
for
discovery,
but
you
don't
have
to
we're
also
increasingly
finding
that.
A
So
we
have
some
data
and
placing
some
of
this
information
about
who
the
original
creator
was
or
the
key
that
created
it
directly
in
that
data
structure
in
a
well-known
as
a
pattern
is
extremely
useful,
so
that
we
can
then
have
some
data
structure
that
is
owned
by,
or
at
least
has
some.
You
know
it's
like
signing
your
name
on
the
bottom
of
your
shoe
sort
of
thing
right.
It's
like
this
is
owned
by
so-and-so
right
by
this
key
at
the
at
the
root
so
ucam.
A
This
is
how
we
move
capabilities
around
and
we
like
to
say
that
if
dids
say
who
you
are,
who
you
know
fundamentally
is
about
asymmetric
crypto,
so
you
know
they
can
sign
with
this
thing.
Therefore
they're
and
nobody
else
has
that
key,
therefore
they're
who
they
they
claim
to
be,
but
you
can
show
what
you
can
do,
okay,
so
this
is
divided
really
neatly
into
authorization
and
authentication.
A
They
look
pretty
familiar.
In
fact,
we
designed
them
to
to
be
familiar
to
web
two
devs,
so
they're
jwts
with
some
special
fields
in
them,
and
they
have
these
two
with
which
is
a
resource.
It's
just
literally
a
uri,
any
uri
can
go
in
there
and
can
what
they
can
do
with
this
thing,
and
that's
some
some
action
and
then
potentially
some
extensible
fields
as
well.
So
if
you
want
to
put
say
a
regex
in
there,
you
can
do
that
and
then
it
works
on
this
chained
model.
A
So
we
have
these
different
users
or
they
don't
have
to
be
different
people.
These
could
just
be
different
devices
or
even
different
processes
on
the
same
machine.
It
doesn't
really
matter
so
you
have
the
original
creator.
In
this
case,
the
little
artist
in
the
the
cloud
has
some
ambient
authority,
because
they've
signed
their
name
into
the
data
structure,
right
they'll
delegate
by
saying:
well
only
these
things
only
these
capabilities.
Only
these
actions
I'm
going
to
delegate
to
the
astronaut
here
and
then
that
astronaut
can
go
further
and
delegates
more
and
more.
A
As
long
as
these
are
getting
narrower
as
we
go
along,
they
can
only
do
the
same
or
less
as
as
we
move
through.
A
And
so
it
forms
this
chain,
that's
cryptographically,
verifiable,
as
we
walk
back.
So
if
you
get
this
last
invoked
one
where
you
know
the
person
actually
goes
to
use
this,
then
we
just
check
all
of
the
proofs
walking
back
in
this
chain,
and
we
can
prove
that
yep,
the
the
owner,
the
person
who
signed
into
this
data
structure
was
the
original
creator
of
it.
A
Those
proofs
are
just
embedded
in
the
regular
jwt
like
this
they're
serialized
and
then
signed.
So
we
need
that
serialization
ahead
of
time,
so
that
the
signature
is
verifiable,
because
in
jwt
you
serialize
it
first
and
then
you
sign
it.
So
these
have
to
be
serialized
to
base64,
url
and
embedded
inside
and
in
the
latest
version
of
the
spec
that
we
are
hopefully
going
to
merge
this
week.
A
You
do
the
same
process
to
each
proof
which
may
recursively
have
more
proofs
inside
of
it.
The
upshot
of
this
is
we're
using
the
same,
essentially
the
same
tech
as
as
oauth,
underneath
where
this
is
the
oauth
sequence
or
fairly
typical
one.
It's
about.
I
haven't
counted
this
in
a
while,
but
you
know
12
or
13
steps
to
just
access
some
resources
on
a
resource
server
and
requires
you
know
four
actors
in
the
in
here
and
we
can
actually
so
this
is
actually
being
generous
to
oauth.
A
This
is
a
you
can
flow,
so
this
could
actually
just
be
a
single
line,
but
let's
say
that
we're
doing
it
in
like
a
classic
application
style.
It
would
look
more
like
this.
We
and
it
also
because
it's
uses
cryptographic
proofs
instead
of
looking
up
things
in
a
database
or
some
shared
secrets.
A
So
file
system,
if
you
were
around
yesterday,
you
saw
a
bit
more
of
this
user.
Controlled
data
means
that
the
data
is
controlled
by
the
user,
not
by
the
app,
and
so
you
know
we
have
alice
bob
and
carol.
Bob
has
a
photo
gallery,
but
we
can
also
share
data
across
multiple
users
that
are
using
the
same
app
so
or
or
potentially
different,
apps
right.
A
So
carol's
video
game
is
going
to
be
spread
across
bob
and
carol's
stuff
and
we
can
load
them
both
in
at
the
same
time
alice's
music
player.
Maybe
it
even
has
some
overlap
with
the
video
game
and
everybody's
stuff
in
this
in
this
picture,
so
it
makes
data
portability
really
easy,
there's
no
more
export
function
and
because
of
how
you
know,
as
I
was
saying
before,
we
don't
really
care
about
who
is
doing
the
action
like
literally
which
human
just
the
signing
keys.
A
These
could
also
be
the
same
person
just
different
devices,
and
so
we've
made
it
very
easy
for
these
things
to
then
also
merge
together
later.
So
if
you
create,
you
know
two
different
in
giant
scarecrow
users
on
two
different
apps
or
even
on
the
same
app.
You
can
later
come
back
and
merge
those
back
together.
A
We'll
talk
about
that
in
a
little
bit
by
default.
Everything
is
immutable,
so
we
never
delete
anything.
A
You
can
go
through
and
delete
stuff,
but
it's
more
manual
so
just
like
how,
if
anybody's
on
a
mac
or
or
it
has
been
on
mac
for
a
while,
rather
time,
machine
where
you
can.
If
you
delete
a
file,
you
can
always
get
back
to
it
or
see
a
previous
version
of
the
file
we've
implemented
almost
exactly
time
machine.
They
do
that
with
unix
hard
links.
A
We
do
this
with
cids,
essentially
hard
links
and
using
all
the
nice
structural
sharing
properties
that
we
get
from
from
ipld
to
do
that.
So
this
is
the
same
directory.
A
Adding
one
file
we
only
need
to
add
was
this
four
links,
three
files
and
we
get
full
versioning
underneath
and
then
we've
also
made
it
evented
so
that
from
the
root
you
can
see,
you
know
this
kind
of
event
happened
below
and
then
there's
this
insert
new
and
then
which
specific
file
was
inserted.
So
it's
actually
it's
more
than
a
graph.
It's
a
technically
a
hypergraph,
because
we
have
these
events
on
there
as
well,
because
we're
building
things
for
apps.
A
So
these
merkel
crdts
were
originally
developed
at
protocol
labs
and
has
been
extended
by
martin,
klepman
and
and
a
bunch
of
others,
and
essentially
we
can
take
a
file
system
over
time
and
use
a
reconciliation
mechanism
to
essentially
do
like
a
git
merge
automatically
without
having
to
ask
the
user
to
do
this,
for
you
by
picking
one
of
them
automatically
and
then,
if
we
picked
the
wrong
one
based
on
heuristic,
you
can
always
go
back
and
say
well
actually.
A
Other
one
and
bring
that
forward
big
advantage
of
this
is,
if
you
have
these
two
completely
separate
file
systems.
It's
the
same.
You
can
just
merge
any
two
arbitrary
data
structures
now.
A
So,
if
I
have
two
users,
I
can
switch
them
together
or
if
I
have
one
user
who's
diverged,
because
they
were,
you
know
offline
or
had
two
devices
that
were
doing
updates
at
the
same
time,
and
there
was
latency
or
any
of
these
cases
we
can
stitch
them
together,
it
doesn't
matter
the
system,
doesn't
care
which
scenario
scenario
you're
in
it
knows
how
to
do
this
reconciliation
and
because
it's
multi-user,
we
need
a
way
of
sharing
things
when
they're
not
online,
which
is
pretty
simple.
A
The
downside
of
this
today
is
you
have
to
know
that
there's
some
data
over
there
that
you
want
to
look
at
and
where
we're
going
and
I'm
going
to
touch
really
briefly
at
the
end
on
this
distributed
database
is
that
ends
up
as
a
behaving
as
a
message
queue,
and
so
you
can
gossip,
hey,
there's
going
to
be
a
message
over
there
for
you,
you
should
go
look
at
it,
but
that
doesn't
exist
today.
A
Today
you
have
to
actually
know
to
go
open
up
the
specific
app
and
then
it'll
do
the
automatic
check
for
you
talked
about
this
yesterday
as
well.
Obviously,
there's
a
hierarchical
encryption.
So
if
I
only
give
you
access
to
my
photos
directory,
you
only
get
access
to
that.
A
You
can't
see
my
documents,
you
can't
see
the
root
of
the
file
system,
and
this
is
all
done
just
with
symmetric
encryption,
each
of
those
keys,
whichever
one
I
give
to
you,
you
can
see
everything
below,
because
that
will
give
you
the
key
to
the
lower
directory,
which
has
the
keys
for
all
of
its
files.
A
So
if
I
give
you
only
one
file
at
a
single
version,
superversion
right
you'll
only
see
that
one
or
I
can
give
you
a
directory
at
a
certain
version.
You'll
only
see
that
one
or
we
can
say
this
directory
for
all
time
and
you
can
then
see
reading
forward
and
that's
the
the
time
one
there.
A
Actually
we
don't
really
talk
about
the
skip
ratchet
and
that's
it
rediscovering
that
structure.
We
are
rewriting
it
in
rust,
as
the
the
kids
say
for
portability
and
webassembly,
so
that
this
can
then
run
everywhere.
So
we,
the
last
couple
years,
have
focused
mainly
on
the
web,
but
we
want
this
to
run
on
desktops,
on
phones
on
everything,
and
we've
also
found
massive
speed.
A
Ups
for
a
lot
of
cryptography,
switching
from
javascript
to
rust
and
and
webassembly
like
100x
improvement
in
some
cases,
so
would
recommend,
and
then
I
said
I'll
just
really
briefly
touch
on.
We
have
this
distributed
database
coming.
A
It
is
essentially
based
on
property,
graphs,
plus
encryption,
and
we
take
the
same
basic
idea
as
the
file
system.
Where
we
blow
away
these
links,
put
it
in
a
flat
structure.
It's
actually
a
set
now,
instead
of
a
tree,
the
order
does
not
matter,
and
we
get
a
bunch
of
really
nice
properties
like
we
can
reorder
all
of
the
rows.
You
can
pull
only
certain
rows
if
you,
if
you
need
them,
we
have
explicit
dependencies
on
time
and
ordering
that
only
appear.
A
If
you
care
about
those
things,
you
can
write
a
query
that
isn't
against
time
and
different
devices
can
hold
on
to
different
literally
down
to
the
single
row
level.
You
can
just
grab
exactly
what
you
need.
So,
if
you're
in
a
low
power
device,
it'll
still
work,
and
then
this
is
going
to
get
us
all
of
that
nice
broadcast
and
soft
real-time
stuff
that
was
talking
about
before.
A
So
we've
had
people
experiment
with
a
bunch
of
stuff,
so
tiddlywiki
has
an
integration
which
is
nice.
We
can,
you
know,
essentially
bake
down
html
files
and
also
make
use
of
the
file
system
and
all
the
data
in
there,
which
is
nice,
so
it
can
hold
arbitrary
data,
including
websites
right.
So
all
of
that
stuff
we've
one
of
our
team
members,
so
a
lot
of
people
we've
hired,
started,
writing
demo
apps
and
we're,
like
you,
seem
awesome,
come
join
us.
A
I
built
a
dynamic
wasm
loader
as
well,
which
is
pretty
cool,
so
actually
really
excited
about
the
like
the
dynamic
programming
capabilities
and
so
well,
not
not
dp,
but
you
know
being
able
to
load
in
stuff
statefully
really
interesting.
The
main
thing
that's
held
us
back
right
on
the
flip
side.
Is
we
put
the
line
in
the
sound
early
on
saying
if
we're
uploading
over
http
and
we're
downloading
over
http
we've
just
created
a
web
server
with
extra
steps
right.
A
B
Think
that's
actually
a
really
good
point
and
maybe
something
for
everyone
who
talks
to
highlight.
So
we
run
js,
that's
in
the
browser
and
also
we
have
a
cli
where
we
can
add
everything
locally
and
then
use
that's
natively
to
actually
pull
from
the
developer,
desktop
as
an
example-
and
this
is
how
we've
ended
up.
Essentially
here
I
mean
literally
here
in
this
room
of
life.
Oh,
we
need
to
slightly
improve
parts
of
the
ips
protocol,
so
I
think.
A
C
A
Yeah
yeah
well,
and-
and
it's
both
like
browsers
themselves-
you
know
their
their
overall
security
model
and
you
know,
as
things
are
getting
more
secure
say
you
know,
firefox
is
adding
more
security
features.
Apple
just
announced
a
bunch
of
security
features
that
makes
it
more
difficult.
The
real
pain
is
that
they
all
have
slightly
different
apis,
supported
right,
so
like
web
workers,
just
like
they
work
one
week,
and
then
they
stop
working
in
one
browser
right
with,
like
20
market
share
like
well.
What
now
we.
B
Literally
yesterday,
with
the
team
but
kind
of
late
here,
I
think
we're
basically
gonna,
say
chrome
sparring
because
basically
firefox
has
made
it
so
that
just
various
things
don't
work
and
we're
like
brooks
of
firefox
primary
user
yeah.
We're,
like
I
don't
think,
we've
supported
plus
great,
but
rage
is
essentially
chrome.
A
But
one
asterisk
on
that,
so
I'm
giving
a
talk
tomorrow,
the
day
after
on
carpool,
so
we're
also
writing
protocols
and
implementations
into
kubo
and
other
places
so
that
it
can
be
like
we
can
use
other
transports
than
bit
swamp
right.
So
biswap
has
a
bunch
of
challenges,
especially
for
the
web,
not
just
the
fact
that
you
know
the
latency
of
all
those
round
trips
and
if
you
can
start
pushing
car
files
over
http
with
deduplication.
A
A
bit
of
both
so
there's
yeah
time
on
the
dht,
it
can
be
pretty
bad,
sometimes
sometimes
really
good.
A
The
some
browsers
will
just
suddenly
drop
support
for
some
features
right
so
not
having
web
worker
support
for
jsi
bfs
can
be
very
painful.
You
you
look
at
content
addressing
and
think.
Obviously
we
should
be
able
to
share
apps
on
the
same
system
and
not
go
out
to
the
internet
and
come
all
the
way
back
and
that's
in
a
lot
of
browsers,
not
possible.
A
Currently
right
so
or
you
can
push
around
small
chunks
of
data,
but
they're,
slowly,
locking
down
different
parts
right
or
at
least
firefox
and
safari
are
so
or
you
know,
apple
a
year
and
a
half
ago
announced
that
they'll
just
start
randomly
clearing
local
storage
and
indexeddb
right.
So
even
if
you're
loading
stuff-
and
it
could
happen
at
any
time
so
not
when
the
user
is
actively
using
it,
but
as
soon
as
they
navigate
away,
they
might
clear
that
cache
because
they
don't
want
you
to
get
tracked
right.
Specifically.
B
A
Yeah
we
need
a
tls
proxy
in
front
of
websockets
because
that's
not
baked
into
kubo
ulcer.js
ipfs
doesn't
use
the
main
dht
by
default.
So
you
have
to
talk
up
to
a
specific
instance.
A
You
can
network
gsi
pfs
instances
in
the
browser
against
each
other
over
webrtc,
but
now
you
need
to
run
a
webrtc
signaling
server,
which
should
just
get
baked
in,
I
think
into
all
of
these
nodes
so
that
you
could
then
just
point
out
any
of
them,
but
that
doesn't
exist
today
and
actually
matrix
has
some
apparently
solution
for
this.
Like
very
recently
in
the
past
couple
weeks,
they
just
started
on
it
that
we
could
maybe
bake
into
into
things.
Just
book
transfer
support.
Sorry
web
transport,
oh
great.
C
B
Amazing,
so
I'll
put
this
in
the
parking
lot,
but
as
an
example,
I
think
one
of
the
things
is
like
hey:
wouldn't
it
be
awesome
if
the
default
experience
is
developed,
it
just
works.
Okay,
hey,
who
wants
to
run
jointly
run
and
webrtc
servers
like
I'll
run,
one
like
ceramic
piano
right
like
exactly
like.
We
can
get
an
equal
five
people
running
a
webrtc
and
doing
their
community
bootstrap.
That
way.
A
C
C
C
C
B
Into
like,
oh
my
god,
I'm
running
I'd
get
that's
a
production
help
please.
If
I
don't
get
wrong,
I
don't
know
it's
just
yeah
right,
and
so
can
we
like
take
a
new
initiative
like
this
and
be
like
sweet?
You
should
do
things.
It
totally
includes
focus
yes
in
ux.
I
think
that
kind
of
came
up
as
well
again,
unlike
your
users,
awesome.
C
B
Has
to
make
it
all
the
way
into
our
all
of
our
default
app
code,
examples
that
are
like
fill
this
out,
and
this
is
a
default
thing
that
will
give
you
a
thing
that
will
just
work
or
in
your
docs
you
like
connect
ours
or
whatever.
In
this
case
it
shouldn't
so
like
the
idea
is
that
you
would
just
probably
get
to
a
set
of
bootstrap
works
and
the
good
job
is.
B
B
A
So
maybe
not
about
this
specific
transporter
or
signaling
system,
but
it
like
in
general,
like
kubo
takubo
works
like
a
bazillion
times
better
than
anything
involving
a
browser.
Today,.
C
A
Yeah,
this
is
a
probably
a
semi-controversial
statement,
but
I
would
love
to
see
high
quality,
wasmable
rust
libraries
so
that
people
could
construct
their
own
nodes
so
that
we're
not
spending
time
spreading
across
all
these
different
implementations
right
and
then
we
can
get
it
into
browsers
into
edge
services
into
all
of
these
places
right
and
that's
not
to
say
that
it
has
to
has
to
use
all
of
these
pieces,
but
at
least
it
gets
you
up
and
running
and
we
can
have
really
high
quality
libraries
for
this
stuff.
A
So
there
is
lib
live
ipfs.
Is
it
now
in
sego?
I
think
which
might
work
I
haven't
played
with
it.
Yet,
though,
there
wasn't
time
to.
C
Get
go
into
browser
with
assembly.
I
don't
know
how
at
that
point.
That
month,
I
know
someone
was
using
the
go
to
bp.
B
Developers
essentially,
this
has
been
extended.
Troll
applied
research
where
we
first
had
to
admit
protocol,
so
our
biggest
adoption
is
actually
did
by
peers,
so
you
can
and
their
method
has
been
adopted.
So
hugo
from
the
they've
gone
all
over
twitter,
blue
sky,
jack's
block
team
and
the
thing
named
red5.
B
It's
also
nothing
you
can't
because
everybody
needs
to
decentralize
off
layers
for
these
sorts
of
things
and
then
next
up
there's
a
number
of
people
who
are
very
interested
in
doing
private
encrypted
data
on
ipfs
and
platform.
So
I'm
looking
at
that
we're
happy
with
protocol
adoption,
that's
what
you're
doing
and
as
it
hardens
it
actually
becomes
usable
for
the
just
works
for
friday.