►
From YouTube: Peer-To-Peer Networks Meetup x EthCC
Description
Building on the Web3 or peer-to-peer tech stack? Interested in ideating on how to solve the tech challenges for moving from Web2 to Web3?
Let's gather to get an in-depth look into the latest research & tech insights from the decentralized and open source projects. You'll learn about the developments in web3 computing and storage, collaborative peer-to-peer stack, data composability, decentralized infrastructure, and much more.
This evening is for developers and thought leaders interested in the Web3 tech stack and the challenges it faces today.
What tech stack do developers need to build awesome Web3 applications?
What does the tech stack look like today?
What's missing for Web2 to migrate over?
Bring your questions. Join the conversation. Listen to thought leaders.
Talks from the founders and core dev teams of Fluence, Radicle, Ceramic, and more, Q&A, networking, drinks & tasty local snacks.
A
A
Okay,
we're
live,
yeah,
hello,
everyone
from
the
youtube
and
hello
everyone
at
the
audience,
really
happy
to
see
you
here.
It's
been
quite
an
intensive
week.
Have
you
been
at
the
conference
or
at
the
meetups?
Yet
yeah
yeah?
I
see
people
are
a
bit
exhausted,
but
let's
get
some.
You
know
some
energy
kick
for
today
for
today's
meetup
we
are
discussing
peer-to-peer
networks
today
and
we
have
three
amazing
projects
and
three
amazing
speakers
co-founders
all
of
all
three
of
them.
A
So
first
will
be
tom
from
fluencelabs
and
then
followed
by
joel
from
ceramic
and
then
alexis
from
radical,
and
then
we
will
have
networking
and
drinks.
We
have
more
food,
we
have
desserts,
so
yeah
be
active.
We
will
have
q
a
after
each
talk
and
if
you
have
any
questions
there
is
no
stupid
question
remember
so
any
questions
are
welcome.
A
C
Great,
thank
you.
Anna
anna
is
a
core
member
of
the
team.
I
also
think
we
should
introduce
the
other
members
of
the
team
that
are
here.
We
have
evgeny,
we
have
dimitri
and
bernard,
is
back
there
and
then
there's
a
core
dev
folix
somewhere
hiding
somewhere
there
we
go.
So
with
that.
That's
you
got
a
lot
of
the
core
fluence
team
here,
which
is
great,
so
I
want
to
talk
about
peer-to-peer
and
compute
and
talk
about
the
need
for
it
and
why
peer-to-peer
matters
and
why
it
matters
particularly
now.
C
I
was
going
to
ask
the
question,
but
I'm
guessing
most
people
would
say
bitcoin
and
bitcoin
being
one
of
the
first
peer-to-peer
kind
of
applications
that
we
know,
but
the
real
application
to
popularize
peer-to-peer
and
to
make
it
mainstream
to
some
extent,
was
napster
back
in
1999,
and
so
I
just
think
it's
worth
pushing
this
timeline
of
peer-to-peer
and
actually
even
goes
back
to
the
late
70s
early
80s,
where
this
architecture
was
discussed.
But
it
goes
back
to
kind
of
usage
in
99.
C
C
You
would
first
time
send
value
to
somebody
without
an
intermediary,
and
that
was
important
from
value
perspective,
but
peer-to-peer
can
solve
far
greater
problems
and
there's
far
greater
risks
in
the
world
than
just
value
transfer,
and
so
big
tech
is
right
now
at
a
the
highest
point
of
its
kind
of
centralization
and
power
we've
seen,
and
so
these
are
examples
of
several.
You
know
censorship
that
I
think
people
have
seen
in
particularly
in
russia
and
also
happens
in
venezuela.
C
Obviously,
in
china,
where
big
tech
has
to
basically
adhere
to
the
directives
of
the
totalitarian
governments
who
want
the
narrative
shaped
a
particular
way
and
that's
something
that
you
know
we
can
see.
You
can
see
political
opponents
being
censored.
You
can
see
stories
being
taken
off
youtube,
videos
removed
and
that's
easy
to
do.
When
you
have
a
couple
specific
platforms
that
you
can
target
that
are
the
dominant
platforms,
people
use,
but
what's
interesting,
it's
not
only
by
totalitarian
governments,
we've
seen
it
happen
in
the
u.s.
C
Some
of
it
is
explicit
censorship,
and
some
of
it
is
sort
of
shadow
censorship.
But
this
is
you
know
the
most.
I
guess
extreme
example
of
this
is
in
india,
very
large
democratic
society
that
has
censored
and
taken
off
protests
or
chat
groups
about
protests
and
even
taken
off
opposing
politicians
and
directed
the
management
of
applications.
To
do
so,
and
in
a
very
kind
of
you
know,
meta
discussion
they
ban,
they
tried
to
have
twitter,
remove
an
article
to
censor
an
article
about
censorship.
C
So
that's
actually
the
level
that
some
governments
are
going
to
and
democratic
governments
to
be
clear.
This
is
not
just
a
a
you
know.
A
russia,
a
china
issue
and
now
twitter
to
its
credit,
is
suing
the
indian
government
to
prevent
this
type
of
censorship
from
from
standing,
and
so
that
is,
I
think,
a
very
you
know,
but
that's
just
worth
keeping
in
mind.
We
may
not
see
it
every
day.
C
So
why
is
this
happening?
It's
you
know.
Big
tech
has
also
a
stranglehold
on
the
web
in
terms
of
infrastructure,
and
so
we've
talked
about
the
sort
of
applications
that
people
use,
but
when
you
get
into
the
infrastructure
on
which
things
are
built,
you
also
have
an
oligopolistic
setup,
and
so
you
have
the
three
dominant
cloud
providers
that
have
at
least
60
percent
of
the
overall
market
and
they're
growing
revenue
dramatically,
and
why
are
they
doing
that?
Because
you're
effectively
locked
in
to
those
networks
and
when
you
join
it's
super
easy.
C
They
have
a
lot
of
services
you
can
use.
It
allows
you
to
get
your
applications
and
your
product
off
the
ground
faster,
but
the
bigger
you
get
the
harder
it
is
to
leave
and
there's
a
couple
of
examples
of
groups.
I
think
with
samsung,
among
others,
who
have
left
but
been
incredibly
expensive
and
hard
to
do.
You
know,
years
ago,
lyft
was
reportedly
paying
14
cents
a
ride
to
aws.
C
That's
probably
a
higher
number
now,
and
I
mentioned
the
power
they
have.
You
know
there
is
a
social
network
with
a
couple
million
users
that
was
knocked
off
with
a
couple
days
notice
for
a
terms
of
service
violation,
and
this
group
is
parlor
and
I'm
not
sure
parlor
is
something
that
we
would.
You
know
die
on
a
hill
for
necessarily,
but
it
just
shows
the
power.
C
The
term
of
service
can
be
an
arbitrary
on
off
switch
for
any
application
and
as
soon
as
they
do
that
to
parlor
all
the
other
applications
know
that
that
is
possible
to
happen
to
them
as
well,
so
that
influences
behavior
additionally
so
and
if
they
were
really,
you
know
incredibly
resilient
and
v
and
never
went
down.
Some
of
these
trade-offs
might
make
sense,
but
frankly
the
larger
they
get
the
more
complex
those
systems
are
and
the
more
prone
to
outages
they
are
and
the
bigger
consequences.
C
Those
outages
then
have,
and
so
those
technology
gets
more
and
more
complex
as
it
scales
it's
harder
and
harder
to
manage
centrally
and
more
and
more
people
use
it,
which
means
when
something
goes
down.
The
impact
is
that
much
greater,
so
we've
seen
you
know,
what's
happened,
facebook
and
others
go
down.
C
So
you
naturally
end
up
with
monopolistic
or
oligopolistic
setups.
You
have
it
in
search,
you
have
it
in
social
media,
you
have
it
in
hosting
that
continues
in,
and
the
internet
won't
probably
change
with
unless
we
are
successful
in
building
a
peer-to-peer
alternative,
and
so
you
know
how
did
we
get
here?
We
started
off
with
mainframes
and
desktops,
and
that
was
companies
by
and
large
doing,
compute
and
doing
kind
of
all
the
all
the
hosting
themselves
in
the
kind
of
late
90s.
C
The
cloud
started
and
people
were
started
to
be
dragged,
kicking
and
screaming
to
the
cloud
everybody
said.
Oh,
I
want
to
host
it
internally
because
it's
cheaper,
it's
more
resilient,
etc.
I
want
to
control
my
data
fast
forward
and
now
the
cloud
is
cheaper.
The
cloud
is
more
resilient
than
people
building
and
having
their
own
I.t
staff
and
infrastructure
in-house,
and
so
the
cloud
has
pulled
away.
C
The
mainframe
and
desktop
world,
but
peer-to-peer
platforms
really
are
the
next
generation
of
this
and
peer-to-peer
is
that
next
generation
for
three
reasons:
it's
next
generation,
because
it
can
scale
better.
It
has
higher
security
and
it's
more
resilient,
and
so
those
three
attributes
will
drive
peer-to-peer
to
be
the
future.
C
It
may
not
have
it's
not
going
to
happen
tomorrow,
but
it's
that
is
the
way
we
are
headed
and,
frankly,
we
need
to
get
in
that
direction.
But
let
me
talk
about
each
of
those
scalability
security
and
resilience,
one
at
a
time,
and
so
scalability
open
peer-to-peer
can
scale
faster.
When
you
have
a
global
network
of
hardware
you
it
can
respond
and
the
software
they
can
respond
to
demand
and
price
far
faster
than
any
centralized
company.
C
You
don't
have
management
to
threaten
to
jail.
Like
you
do
in
india,
you
don't
have
shareholders
who
are
going
to
be
upset.
If
xyz
doesn't
happen,
you
don't
have
boards
who
have
reputations
that
are
at
risk,
and
so
you
have
a
no
legal
entity
to
compel,
and
so,
when
you
have
peer-to-peer
applications
running
on
peer-to-peer
networks,
you
have
a
far
more
censorship
resistant
and
a
far
more
secure
method
of
application,
design
and
of
and
of
content
delivery,
which
gets
into
resilience
peer-to-peer,
doesn't
have
single
points
of
failure.
You
have
open
source
code,
highly
reviewable.
C
C
You
don't
have
centralized
points
of
failure
and
you,
and
that
leads
to
far
more
and
you
have
duplicated
duplicative
setups,
both
in
terms
of
hardware
and
in
terms
of
hosting,
and
so
you
end
up
with
a
far
better.
You
know
solution
from
a
secure
perspective
from
a
security
and
resilience
perspective,
and
where
are
we
right
now
we
have
payments,
and
so
we
were
familiar
with
all
of
the
payment
systems
out
there
that
work
from
you
know
bitcoin
to
ethereum
et
cetera.
C
I
put
hedera
on
there
and
also
storage
storage
is
also
working
very
well
right
now,
but
what
we
don't
have
yet
is
decentralized
compute
and
when
you
put
those
three
things
together,
you
end
up
with
a
you
end
up
with
a
decentralized
cloud
which
is
what
we
need,
and
so
just
a
quick
discussion
on
on
the
traction
payments
very
well
right.
Obviously
the
that
number
was
2
trillion
not
long
ago,
but
it's
still
significant
and
you
know,
storage
filecoin
are
weave,
you
know,
storage.
C
All
of
these
systems
are
functioning
they're,
headed
in
one
direction
in
terms
of
growth
and
that
technology
has
largely
solved
peer-to-peer
storage,
but
the
compute
is
what
we're
all
still
working
on
and
the
compute
is
we
when
we
think
of
compute
in
peer-to-peer
world,
we
often
think
of
smart
contracts
and
smart
contracts
work,
and
that
is
peer-to-peer
compute.
The
problem
is,
it
is
slow
and
expensive.
C
That's
what
you
should
want
in
a
peer-to-peer
compute
protocol,
and
you
know
that's
what
fluence
has
and
others
are
doing
it
as
well,
where
you
can
have
any
computation
and
it's
a
function
addressable
and
it's
permissionless,
so
think
of
it
as
like
a
decentralized.
You
know,
lambda
function,
you
know,
and
why
do
you
want
that?
Well,
one
of
those
other
reasons
we
talk
about
here
is
the
deep
platforming
risk
from
web
2,
and
you
know
this
is
just
one
example
of
twitter.
C
You
can
think
of
others,
as
you
know,
back
to
farmville,
et
cetera,
where,
if
you
really
want
to
innovate,
you
should
be
able
to
take
a
d5
example
and
build
on
top
of
existing
applications
and
existing
protocols,
but
in
the
web
2
world.
You
can't
do
that
because
the
applications
on
which
you
build
can
always
have
the
ability
to
turn
you
off
and
shut
you
down
and
that
limits
the
ability,
the
innovation
that
can
happen
on
top
of
any
one
protocol,
so
people
have
to
or
any
one
company
or
any
one
application.
C
C
The
problem
also,
though,
is
that
web3
projects
often
have
centralized
back
ends
right
now
as
well,
and
that
is
kind
of
a
little
secret
of
the
industry,
and
it's
nobody's
fault.
It's
just
that
there
hasn't
been
computer.
That's
peer-to-peer
that
is
usable
and
deployable
yet
for
web
3..
So
for
all
the
talk
of
web
3
and
being
decentralized,
there
are
centralized,
backends
and
centralized
apis
behind
some
core
infrastructure
of
web
3..
C
C
And
you
know
importantly,
it
doesn't
all
have
to
be
on
chain
the
way
smart
contracts
are
the
way
we
think
of
you
know,
and
especially
in
this
kind
of
conference,
you
would
think
of
it
as
being
on
chain.
Remember
that
both
are
weave-
and
you
know,
ipfs
some
of
the
most
successful
projects
in
the
peer-to-peer
world.
C
You
can
plug
consensus
if
you
want
and
it's
cheap
and
fast,
and
so
it
actually
provides
really
the
perfect
trade-off.
We
think
between
centralized
and
and
on
chain,
and
so
what
makes
up
the
computing
it's
the
network,
it's
the
language
and
those
allow
a
code,
creator
economy,
and
so
you
know
discussing
you
know.
The
key
piece
of
this
here
is
the
language
aqua,
and
so
I
talked
about
fluence
as
being
a
peer-to-peer
compute
protocol.
C
It
also
has
attached
to
it
and
a
core
piece
of
it
is
a
language
which
allows
the
easy
composition
of
native
peer-to-peer
applications.
It's
the
only
language
which
does
this
that
abstracts
out
a
lot
of
very
complex
peer-to-peer
code
and
peer-to-peer
architecture
so
that
you
don't
have
to
write
the
pure
discovery.
For
example,
this
aqua
takes
care
of
all
of
that,
and
so
we
think
that
when
you
add,
when
you
have,
you
can't
have
a
true
peer-to-peer
platform
without
having
very
simple
peer-to-peer
application.
C
Construction
and
importantly,
this
is
live
today.
I'm
not
talking
about
a
vision
of
something
we
have
in
mind
for
five
years
from
now,
but
right
now,
there's
pure
discovery
is
written
and
there's
you
know
there's
you
know,
you
know
we
use
data
streams
on
ceramic
there's
file
management
using
ipfs,
so
this
is
actually
live
and
usable.
C
This
is
the
software
author
comes
up
with
the
next
version,
and
the
previous
versions
are
out
and
you're
in
a
forced
upgrade
cycle
when
you're
in
a
peer-to-peer
world,
when
your
code
is
actually
released,
it's
out
there
and
you
as
the
author,
no
longer
own
it
and
you
as
a
user
and
as
a
host,
can
use
it
as
long
as
there's
demand
for
it
and
hosts
can
host
it
forever.
So
you
actually
end
up
divorcing
authorship
from
ownership
now
using
fluence
there.
C
You
can
share
monetary
rewards
from
that
in
perpetuity,
but
this
ends
up
with
a
world
like
this,
where
you
can
still
have
old
versions
that
run
as
long
as
there
are
hosts
available
and
interested
and
compensated
for
running
those
versions.
So
you're
not
forced
into
upgrade
cycles,
you're,
not
forced
into
you,
know,
breaking
code
that
you've
already
written
or
having
it
broken
because
dependencies
break
in
new
versions.
C
You
can
continue
to
run
this,
and
so
what
that
means,
though,
is
you,
then
have
no
d
platforming,
and
so
now,
because
this
code
is
out,
there
applications
out
there
no
longer
owned
by
the
author.
You
can
then
build
on
top
of
any
of
those,
because
the
author
can't
shut
you
off
anymore
and
anyone
can
host
those
and
anyone
can
use
them.
C
So
you
start
a
world
of
composition
where
anyone
can
build
on
existing
applications
without
fear
of
being
cut
off
and
in
the
worst
case,
you're
worried,
you're
gonna
get
cut
off,
you
could
host
it
yourself,
and
so
that
leads
to
a
potential
explosion
in
creativity,
as
you
no
longer
have
to
innovate
from
the
ground
up,
but
you
can
innovate
on
top
of
existing
infrastructure
and
existing
code
and
existing
applications.
Even,
and
so
we
think
this
allows
the
code
creator
economy
to
really
function,
because
that
then
allows
monetization.
C
It
allows
tokenization
and
a
huge
number
of
uses
kind
of
explode
from
there.
So
where
are
we
right?
Now
we
have
aqua
and
the
peer-to-peer
network
is
live
and
functioning
this
year.
We
are
getting
ready
to
launch
a
dow,
and
that
will
be
the
governance
of
our
network
and
then
the
compute
economy,
which
I
touched
on,
is
going
to
be
finished
next
year.
So
you
can
find
us
at
a
variety
of
these
areas.
Obviously,
but
definitely
find
us
at
dash.luas.dev.
C
Fluence.Network
is,
is
our
website
and
I'm
going
to
close
with
two
thoughts
here,
which
is
you
know
what
kind
of
world
do
we
want
to
live
in
and
do
we
want
three
companies
controlling
the
internet?
That's
then,
with
content,
monitored
and
sang
and
censored
by
nation
states
with
huge
barriers
to
building
independently.
C
You
know
this,
I
don't
think
is
what
tim
berners-lee
signed
up
for.
I
don't
think
his
internet,
any
of
us
want
and
so
peer-to-peer
an
incentivized
open
source
is
the
only
way
only
shot.
We
have
to
not
live
in
a
world
controlled
by
three
or
four
companies
and
effectively
by
governments
like
this
is
our
only
chance,
so
support
peer-to-peer
host
contribute,
follow
and
you
know,
empower
the
next
wave
of
internet
innovation.
C
D
Thank
you
for
this
nice
presentation.
I'm
I'm
hoping
it's
not
a
stupid
question.
Can
you
elaborate
a
bit
more
about
what
it
means
computing?
What
would
you
intend
by
this
and
how
would
it
work
for
me
as
a
developer?
What
what
should
I
push
to
your
system
and
what
what
would
I
give
you?
What
would
I
get
back.
C
I
mean,
I
guess:
well,
if
again
you
can
come
up
and
address
some
of
that,
but
I
guess
the
main
thing
I
would
say
is
that
it's
any
type
of
of
I
mean
of
computation.
So
it's
counting
it's
any
type,
anything
that
involves
think
about
the
other
way,
what
storage
and
what
is
payments
and
anything?
That's
not
that
is
effectively
computation.
C
D
C
Correct
correct
and
importantly,
you
would
write
it
and
it
might
go
to
look
up
one
host
that
it
could
perform
an
ad
and
then
perform
one
function.
There
find
another
host
for
the
next
function
and
travel
until
it
was
complete
and
then
come
back
to
you.
So
instead
of
you
writing
a
function
that
goes
to
one
place
that
you
know
like
aws
and
back.
It
actually
can
look
up,
peers
or
hosts
and
find
it
and
then
travel
back
in
multiple
places
and.
E
G
H
C
E
So
the
way
we
address
like
there
are
several
layers
of
the
verifiability,
if
you
think
of
verifiability
as
a
you
know,
in
terms
of
blockchain,
like
trustless
computation
right
when
you
want,
when
you
run
some
piece
of
computation
and
you
want
to
make
sure
that
was
executed
correctly,
there
are
several
ways
to
achieve
that.
First,
you
just
trust.
Whoever
did
the
competition.
E
E
Out
when
you
can
see
that
the
node
executed
the
function
you
want
it
to
execute,
but
maybe
you
cannot
check
that
this
function
was
executed
correctly,
but
you
cannot
be,
but
you
can
be
sure
that
there
was
the
right
function.
So
there
are
like
several
layers
and
the
solutions
to
them
are
like.
There
is
a
kind
of
the
family
of
solutions
and
that's
not
like.
We
don't
have
like
a
full
end-to-end
decisions
for
this.
Yet,
but
it's
kind
of
the
exploration
space.
I
B
H
C
That's
used
the
most
and
provides
the
most
use
and
value
to
people
overall
and
for
us,
the
coin
is
a
piece
of
that,
but
it's
not
the
driving
function
of
it,
but
we
also
think
that
there
probably
be
a
mechanism
of
staking
so
that
people
providing
computation
will
and
are
hosting
will
have
to
actually
own
a
certain
value
that
helps
provide
trust
in
them
as
well
somewhat
similar
to
you
know:
ipfs,
I'm
sorry
to
file
coin.
So
it's
a
combination
of
those
two
elements
that
we
haven't
finalized,
but
we
want.
A
J
J
J
J
Those
contributions
matter
together
and
from
this
we
can
actually
get
to
some
place
where
we
have
an
emergent
web
of
trust.
Where
not
only
like.
Can
you
see
like?
Oh
someone
did
something,
but
actually
look
at
the
graph
of
interactions
to
get
them
from
useful
information
out
of
this
graph.
So
one
interesting
use
case
for
that
is
git
coin
and
and
not
conviction,
but
quadratic
voting
where
you
actually
want
to
weigh
the
relations
in
the
quadratic
voting
based
on
like
something
called
social
proximity,
and
the
only
way
you
can
kind
of
get.
J
This
is
to
have
some
idea
of
like
what
the
different
groups
that
are
contributing
look
like,
and
the
web
of
trust
has
been
tried
before
in
kind
of
the
pgp
old
school
crypto
world,
but
that
never
really
took
off
because
they
were
kind
of
trying
to
introduce
new
social
ways
of
interacting
by,
like
oh,
let's
have
a
crypto
party
and
go
and
sign
each
other's
keys
like
who?
Who
really
wants
to
do
that?
But
if
you
actually
all
of
your
interactions
online
are
and
and
verifiable.
J
So
we
need
different
apps
and
different
organizations
to
be
able
to
collaborate
on
the
same
data,
and
this
is
so
like
you
know,
you
don't
get
data
silos
and
kind
of
what
was
talked
about
by
tom
right
before,
like
this
kind
of
thing
where
web
2
applications
can
shut
down
access,
that's
really
bad
and
we
need
the
data
to
be
open
and
shared,
and
we
can
actually
share
network
effects.
So
your
users
are
actually
also
my
users
and
we
don't
want
to
lock
developers
into
like
one
specific
workflow.
J
We
want
them
to
actually
plug
into
this
open
data
ecosystem
and
maybe
build
their
own
custom
database
or
something
like
that.
But
we
still
want
the
data
to
be
composable.
We
want
you
to
be
able
to
plug
in
use
existing
data
and
not
start
to
build
new
silos
based
on
like
different
formats.
We
want
to
like
be
able
to
share
formats
and
things
like
that,
and
with
this
we
can
again
like
increase
the
rate
of
innovation.
J
Another
really
important
aspect
here
is
that
we
can
prove
authenticity
of
the
data
and
all
the
interactions
in
the
network.
So
we
want
this
system
to
be
censorship.
Persistent
of
course
we
want
every
action
that
happens
in
the
system
to
be
authenticated,
and
that
essentially
means
that
every
action
is
signed
by
whoever
the
author
is.
J
All
of
the
authors
in
this
network
can
actually
start
to
build
reputation
because
we
can
see
like
their
interactions
over
time
and,
of
course
like
this
should
be
completely
surprised.
So
I
don't
need
to
like
time
myself
and
my
life
to
like
one
identifier
to
be
able
to
like
change.
You
know
identify
use
over
time
potentially,
so
this
is
a
great
can
we
just
do
it
on
a
blockchain
kind
of
blockchain
kind
of
provides
all
these
properties,
so,
let's
just
like
put
it
on
the
blockchain.
J
Well,
there
are
some
kind
of
problems
with
this,
as
you
might
know,
like.
Blockchains
are
really
good
for
like
financial
use
cases,
but
they
don't
really
scale.
You
know
to
the
web
scale
and
probably
like
will
be
really
hard
because
blockchain
scalers
favors
something
called
strong
consistency,
and
what
this
means
is
that
at
every
kind
of
update
to
the
blockchain,
all
nodes
have
to
kind
of
agree
on
what
has
gone
on,
and
so
this
is
great.
J
It
allows
us
to
prevent
double
spends,
which
is
what
we
need
for,
like
all
fun
financial
use
cases
and
semi-financial
use
cases
that
we
have
so
great
for,
like
managing
funds,
dows
invest
in
things
fund,
public
goods.
Like
really
nice
stuff,
we
can
have
non-fungible
tokens
and
all
that
fun,
but
we're
always
going
to
be
like
kind
of
minute
like
limited
by
the
block
producer.
J
So
the
block
producer
is
basically
the
node
in
the
network
that
produces
the
new
block
and
the
throughput
of
the
network
is
essentially
limited
by
the
size
of
this
block.
So
but
there
are
different
blockchains
trying
to
get
around
this
problem,
and
these
like
build
scalable,
blockchains
and
essentially,
two
two
approaches
to
this.
One
is
yeah,
let's
use
bigger
blocks,
so
we
have
like
blockchains,
like
solana
like
are
weave
like
celestia.
J
They
have
different
ways
of
providing
like
crypto
economic
incentives
and
new
structures
for
how
we
can
kind
of
convince
ourselves
that,
like
yeah,
this
big
block
producer
is
actually
fine
and
we
just
like
produce
really
big
blocks
and
kind
of
are
fine
with
it
and
still
like.
We
have
a
big
block.
You
know
we
don't
run
facebook
or
twitter
on
like
one
single
machine.
We
actually
have
to
short
those
type
of
like
web
scale
systems.
We
can't
run
those
on
a
strong
consistency
model.
J
So,
like
one
machine
running
a
big
block,
it's
not
gonna
cut
it.
Then
we
have
proof
of
storage
systems
and
these
provide
kind
of
like
a
nicer
property,
because
I
can
make
a
transaction
in
something
like
file
coin
or
cer
storej
and
tell
maybe
like
another
node
in
the
network.
Like
hey,
I
have
this
big
file.
I
want
to
store,
and
if
I
make
this
payment
to
you
conditionally
on
you
storing
that
file,
can
you
please
store
it?
So
you
make
this
agreement
with
one
or
multiple
nodes
in
the
network.
J
J
At
the
same
time,
in
the
system
you
have
like
10
000
or
like
millions
of
small
updates
that
happen
at
the
same
time
and
for
every
new
piece
of
data
that
you
put
into
a
proof
of
storage
system,
you
actually
need
a
transaction
into
the
block,
so
you're
actually
limited
by
the
size
of
the
block
producer.
Anyway,
you
just
made
it
limited
by
the
size
of
the
block.
J
So,
even
though
we
have
this
like
big
throughput,
we
still
can't
have
like
massive
parallel
data
production
happening.
So
the
question
we
should
ask
ourselves
is:
can
we
build
a
decentralized
peer-to-peer
network
that
is
eventually
consistent?
So
we
can
have
this
kind
of
massive
parallel
data
production
and
yeah?
I
think
we
can
do
that
if
we
have
all
the
event
logs,
be
verifiable,
have
verifiable
audit
trails
and
essentially
be
completely
independent,
and
can
we
do
this
while
actually
maintaining
the
composability?
J
So
what's
really
nice
about
blockchains
is
that
I
can
have
a
smart
contract.
You
can
build
another
smart
contract
that
kind
of
works
together
with
the
first
smart
contract,
which
is
really
nice,
but
can
I
have
a
system
like
that
where
you
build
an
application
and
you
have
some
sort
of
data
model?
I
want
to
actually
build
an
application
that
uses
your
data
model,
but
I
want
to
use
some
other
kind
of
structure
for
my
data
as
well.
So
I
can
kind
of
read
your
data
and
also
use
my
data
as
well
in
the
system.
J
So
can
we
have
that
sort
of
like
composability,
but
for
data
in
this
kind
of
non
completely
blockchain
system?
And
finally,
we
want
the
data
to
be
non-financial
or
like
this.
This
system
should
at
least
deal
with
non-financial
data,
because
for
the
financial
use
case,
we
actually
need
blockchains
so
that
this
data
kind
of
essentially
becomes
soul
bound
because
it's
tied
to
like
one
particular
identifier
in
the
system
there's
no
way
to
like
trade
purely
data.
J
J
And
this
is
actually
something
that
we
will
be
releasing
a
developer
preview
soon.
So,
but
let's
dive
in
and
dissect
this.
So
at
the
base
layer
we
have
event
streams
and
these
event
streams
are
kind
of
pure
event,
streams
that
just
like
allows
users
to
individually
post
events
to
kind
of
use,
their
own
event
streams
at
the
layer.
J
Above
we
have
an
indexing
layer
that
creates
databases
and
in
this
system
you
kind
of
observe,
what's
going
on
in
the
event
streams
and
produce
a
database,
and
on
top
of
this,
we
just
like
provide
a
nice
to
use
graphql
api
and
this
whole
system.
We're
actually
calling
compose
to
be
so
composed
to
be
is
basically
a
database
built
on
top
of
the
ceramic
event
streaming
layer.
J
So,
let's
start
with
the
event
streaming
layer
kind
of
the
base
layer
of
ceramic
so
event,
streams
are
independently.
Verifiable
they're
made
up
of
signed
events
and
of
events
that
kind
of
prove
that
a
certain
event
was
included
into
the
blockchain.
At
a
certain
point
in
time,
we
have
authentication
using
the
did
standard,
which
actually
got
accepted
like
an
official
w3c
standard
like
yesterday,
which
is
kind
of
nice,
and
the
system
we've
been
working
on
actually
allows
you
to
authenticate
to
ceramic
using
like
any
blockchain
wallet.
So
you
can
use
like
metamask.
J
You
can
use
blockchains
from
like
the
salon
ecosystem
from
polkadot,
like
whatever
like
you,
can
actually
extend
this
authentication
system
to
work
for,
like
any
blockchain
system
and
the
event
streams
themselves
are
synchronized
using
a
peer-to-peer
network.
So
there's
no
like
centralized
point
of
failure.
If
there's
like
multiple
people
actually
running
nodes
that
backs
up
these
event
streams
and
by
the
nature
of
like
the
data
being
signed
by
your
key
or
key
assession
key
permission
by
your
your
main
kind
of
maybe
like
ethereum
account.
The
data
is
all
tied
to
your
address.
J
Then
they
can
create
signed
events
that
just
like,
include
some
data
and
contains
a
pointer
back
to
the
previous
event,
and
so
you
can
just
like
keep
appending
the
event
log
with
these
signature
signed
events,
and
so
you
can
imagine
like
this
event.
Log
could
represent
really
anything,
but
you
could
have
like
it
represent,
just
like
creating
updating
and
deleting
documents,
for
example,
or
in
theory,
you
could
use
it
for
like.
I
took
this
input
and
ransom
computation
took,
and
this
is
the
output
ceramic.
J
J
We
have
a
ethereum
here,
for
example,
and
there's
an
anchor
event.
So
here
basically
what's
happening,
is
the
hash
of
the
previous
event
is
included
into
a
transaction
that
goes
on
ethereum?
This
essentially
provides
a
way
of
doing
timestamps
and,
of
course
like,
if
you
needed
to
do
this
for
all
events
for
all
streams,
it
would
be
very
expensive
to
make
a
lot
of
a
lot
of
transactions.
J
So
what
we
can
actually
do
is
just
take
up
a
bunch
of
events
from
a
bunch
of
different
streams,
build
a
merkle
tree
and
put
the
root
of
that
merkle
tree
or
really
like
any
sort
of
vector
commitment
put
that
on
chain.
So
now
you
can
have
a
proof
for
any
individual
stream
that
you're
synchronizing
that
this
particular
event
was
included
at
this
point
in
time,
and
you
can
just
like
store
the
data
of
the
merkle.
J
Witness
to
not
have
to
care
about
all
of
the
other
streams
in
the
in
the
network,
so
I
can
like
independently
verify
any
singular
stream
in
ceramic
without
having
to
care
about
any
of
the
other
streams
in
the
network
and
so
going
one
layer
up.
We
have
the
database
layer
so
really,
on
top
of
these
event
streams,
you
could
build
any
sort
of
indexes
from
these
events
and
you
can
really
like
specialize
for
particular
use
cases.
J
So,
for
example,
a
database
could
be
like
completely
global
and
index
like
all
of
the
users
or
data
or
like
all
of
kind
of
the
different
sorts
of
data
in
the
network,
or
you
can
make
them
index
like
subsets
of
data,
maybe
like
particular
models
or
like
schemas
in
the
network,
or
maybe,
like
particular
subset
of
users.
Maybe
you
have
like
a
very
local
peer-to-peer
app
that
only
wants
to
like
index
three
users
or
something
like
that.
J
And
so
finally,
this
kind
of
can
give
you
a
flexible
consistency
model.
So
you
can,
what
we're
doing
with
compose
db
is
actually
allowing
anyone
to
spin
up
a
node
and
just
like
index
whatever
they
want
and
actually
store
that
index
locally
in
their
node.
But
you
can
imagine
a
system
that
kind
of
has
some
consensus
mechanism
that
chooses
to
like
hey.
We
want
to
build
an
index
and
have
consensus
over
that
index,
so
we
can
like
know
and
that
we're
in
the
same
page.
J
So
in
compose
db,
as
I
mentioned,
it's
a
local
index
or
node
centric
index
and
in
in
this
compose
db
system.
There
is
a
model
for
data,
so
this
is
essentially
a
semantic
data
model.
It
has
a
json
schema
that
defines
kind
of
the
structure
of
documents
that
are
written
to
to
the
database
and
a
new
node
operator
can
essentially
choose
like
hey.
J
I
want
to
index
model
a
model
b,
but
not
model
c,
and
then,
essentially
you
can
think
of
it
like
when
you
start
this
node
you
can
synchronize
synchronize
the
the
history
and
instead
of
like
in
bitcoin
or
ethereum,
you
synchronize
all
of
the
history.
Through
time,
you
essentially
only
synchronize
the
pieces
of
the
data
that
you
care
about,
and
so
finally,
eventually
you'll
be
able
to
query
data
across
linked
models.
So
you
can
actually
link
models
together,
see
like
hey.
This
is
my
proposals,
and
this
is
comments
for
proposals
for
the
this
proposal.
J
So
I'll
talk
a
little
bit
more
about
the
data
models.
That's
used
inside
of
composedb,
so
the
data
model
is
essentially
adjacent,
schema,
plus
some
metadata
information
and
that's
it
and
then
any
user
can
write
to
this
model,
but
any
user
actually
writes
to
their
own
event
stream.
So
there's
no
need
to
kind
of
have
some
access
control
or
anything
like
that
of
like
which
users
are
allowed
to
write,
but
instead
your
node
can
choose
to
index
like
a
subset
of
users.
J
So
you
can
have
this
kind
of
open
right
access
to
that
data
model
and
potentially
like
restrict
who
you're
indexing
in
the
future.
If
you
want
these
data
models
can
be
easily
created
using
the
graphql
schema
definition,
language,
which
kind
of
like
a
very
easy
way
of
like
defining
it's
like
a
schema
for
some
reason.
J
Emojis
doesn't
work
on
this
computer,
so
I'm
sad
but
yeah.
Of
course,
then
you
can
make
like
graphql
queries
over
the
data
and
the
nice
thing
about
these
data
models
is
that
they're
discoverable
and
they're
reusable
and
they're
composable.
So
if
there's
like
five
people
here,
building
different
apps,
I
could
pull
in
all
of
those
five
different
models
into
my
application
and
just
use
them
and
already
have
access
to
like
all
of
the
data
of
your
users.
J
If
my
of
course,
the
user
can
send
to
use
my
application,
so
what
this
would
look
like
to
actually
defining
this
model?
It
would
look
something
like
this.
I
don't
know
how
viewable
is
hopefully
somewhat
doable.
Let
me
know
if
I
don't
know
if
you
can
zoom
in
here
essentially
here
we
have
a
proposal
so
think
of
this
as
like
a
proposal
to
a
tao.
J
Proposal
or
comment,
then,
in
the
comment
we
have
a
proposal
id
and
there
we
basically
is
referenced
id
of
a
particular
proposal,
and
so
this
is
essentially
what
not
yet
but
will
enable
us
to
in
ceramic,
just
make
a
query
for
a
proposal
and
giving
all
the
comments
in
the
same
query,
as
you
can
see
like
this,
is
fairly
easy
to
use
like
write
one
of
these
and
what
you
will
be
able
to
do
like
once.
There
is
like
a
set
of
models
available
in
the
network
is
kind
of
just
like
hey.
J
I
want
this
proposal
and
comments
already
exist,
and
I
want
to
use
that
in
my
dial
as
well,
but
now
I
also
want
to
have
like
likes
or
upvotes
and
downloads
for
for
comments
or
proposals,
or
something
like
that.
So
it's
easy
to
like
extend
models
with
like
new
properties
and
or
new
things
in
this
way.
J
So
I
think
I've
went
through
like
mostly
like
what
compost
db
is
and
and
what
we're
about
to
release
a
developer
preview
of
soon.
So
what
are
some
of
the
use
cases?
Well,
any
sort
of
things
about
like
online
communities
is
interesting
and
fun
like
I
don't
think
we
should
try
to
some
people
are
like
copying
twitter
copying
like
different
social
networks
from
web
2
into
web3.
I
don't
think
that's
the
right
approach.
J
J
Dial
tooling,
I
think
there's
a
lot
of
like
open
opportunity
around
out
tooling
and
some
of
the
kind
of
dow
tooling
systems
I
see
right
now.
They
build
just
like
systems
that
just
store
data
on
a
centralized
server
that
used
to
enable
dao
collaborators
to
do
stuff.
But
then
the
data
is
locked
into
that
particular
platform.
It's
not
really
composable.
J
B
J
Example,
put
like
what's
a
research
question,
what's
a
claim?
What's
some
evidence,
how
do
they
relate
to
each
other
and
then
use
that
as
a
basis
for
our
scientific
and
other
sort
of
like
discussions,
maybe
like
even
base
policy
based
on
like
actual
scientific
proven
or
like
proven,
but
like
based
on
real,
like
scientific
discourse
and
and
how,
like
you,
can
kind
of
model
propositions
inside
of
this?
J
So,
like
there's
a
lot
of
like
potential
in
that,
and
and
finally
like
really
exciting
to
think
about
once
you
have
these
knowledge
graph,
these
dial
collaboration
online
communities,
since
all
the
data
is
verifiable
in
ceramic,
you
can
see
which
accounts
did
what
and
how
they
interacted.
You
can
actually
just
look
at
these
event
logs
and
compute
some
kind
of
okay.
This
is
weighted
map
of
like
how
people
contributed
and
then
do
like
a
communal
kind
of
retroactive
funding
to
people
based
on
how
they
interacted.
J
So
I
think,
like
that
sort
of
thing,
it's
really
interesting
to
explore
for
new
projects
like
thinking
about
like
reputation
and
things
like
that,
all
right.
So,
if
you're
interested
in
all
of
this
we're
going
to
have
an
updated
documentation,
soonish
on
our
developer
website,
and
if
you
want
to
shout
to
us
about
this,
you
can
join
our
discord.
Thank
you
very
much.
K
J
J
Storing
your
data
and
that's
gonna,
find
for
technical
users
to
like
run
their
own
pods
for
most
users,
probably
not
gonna,
want
to
run
their
pod,
so
they
will
rely
on
some
service
provider
and
then
they're
kind
of
at
the
whim
of
that
service
provider.
I
think
it
can
work,
but
I'm
kind
of
worried
for
that
sort
of
solutions.
J
There's
similar
solutions
as
well
like
a
few
different
ones,
that
I'm
worried
that,
like
you'll
end
up
with
network
effects
with
like
one
big
company
like
google
or
microsoft
or
whatever,
that
list
runs
a
lot
of
those
nodes
and
a
lot
of
users
just
get
locked
into
that
system.
And
there's
like
capture
of
that.
Whereas
in
ceramic
we
focus
on
like
building
this
open
network
where
and
it
will
eventually
have
incentives
to
just
like
keep
the
data
available
in
in
a
decentralized
way.
J
L
J
Yeah,
so
I
mean
this
is
something
that
we're
still
kind
of
working
on
and
doing
research
on.
I
think
the
main
difference
is
that
we
want
to
have
an
incentive
that
make
sure
that
there
are
notes
in
the
network
that
continually
keeps
data
available,
but
not
necessarily
like.
Oh
at
this
point
in
time.
All
of
this
data
in
a
particular
block
is
available.
J
So
it's
probably
going
to
look
like
some
sort
of
like
sampling
mechanism
that
just
like
across
the
set
of
streams
in
the
network
that
have
kind
of
paid
for
to
be
sampled,
there
will
be
nodes
that
actually
be
incentivized
to
sample,
make
sure
that
data
is
available
and
that
the
kind
of
progression
of
the
event
streams
is
not
halted.
So,
like
you,
actually
have
an
incentive
to
store
new
events,
rather
than
just
like
only
store
like
a
certain
subset
of
events
in
a
stream.
J
B
A
B
M
M
No,
I
can't
on
this
computer,
but
okay,
maybe
I'll,
show
the
website
anyway
yeah.
So
radical
is
essentially
a
peer-to-peer
code
collaboration
network,
but
today
I'm
going
to
talk
a
little
bit
more
about
the
the
foundations
on
which
it's
built
and
on
which
any
kind
of
collaborative
network
can
be
built.
M
So
so
there's
there's
kind
of
three
problems
that
we're
tackling
with
radical
and
and
which
I
think
a
lot
of
peer-to-peer
networks
need
to
tackle
in
some
way.
The
first
one
is
how
to
reconcile
divergent
histories.
So
if,
if
users
are
are
working
on
a
document
from
their
laptop
and
eventually
you
know
they
they
go
online
or
they
go
offline.
There
may
be
conflicts.
M
M
Essentially,
this
is
something
that
git
doesn't
solve.
So
you
take
two
git
repositories.
You
can
look
at
the
source
code,
you
can
say:
oh
the
hashes
match,
but
this
isn't
an
identity,
a
solution
to
identity.
It
could
be
two
repos
that
happen
to
be
at
the
same
change
from
different
users
and
they
intend
them
to
diverge.
They
could
be
forks
of
each
other,
etc.
So
git
really
solves
the
replication
problem.
M
It
solves
some
of
the
the
the
merging
or
the
conflict
problem
and
it
doesn't
solve
the
identity
problem,
and
so
we
had
to
to
build
radical.
We
had
to
find
solutions
to
these,
so
I'm
going
to
go
through
them
through
the
the
three
and
explain
kind
of
what
we're
doing
so
for
for
merging
divergent
history,
so
we're
using
crdts,
which
is
a
pretty
common
technology-
that's
been
around
for
a
while
we're
we're
calling
them
collaborative
objects.
M
M
Then
there's
replication
so
with
replication,
as
I
said,
we're
using
git's
basic
replication
protocol,
which
is
super
nice
and
efficient
for
for
text.
It's
also
pretty
good
for
binary,
but
essentially
it's
it's
very
efficient
because
it's
interactive
so
as
opposed
to
something
like
ipfs,
which
is
great
for
like
static
files
with
with
a
git
replication.
You
have
a
little
interactive
step
before
the
replication
happens,
where
the
two
nodes
or
the
two
peers
sort
of
say,
hey.
M
I
have
this,
but
I
don't
have
that,
and
so
the
the
peer
that
has
the
data
will
generate
pac
files,
which
is
essentially
compressed
archives
with
all
of
the
data
that
the
other
peer
doesn't
have
nothing
more
and
send
that
over,
and
so
we
we
take
advantage
of
that
for
for
replication,
which
for
us
is
not
just
source
code.
It's
also
things
like
issues
prs
social
artifacts.
M
Whatever
you
want
in
terms
of
the
the
network
architecture,
this
is
kind
of
something
we're
still
working
on,
but
it's
a
little
bit
more
like
something
like
bitcoin
and
ethereum,
rather
than
something
like
scuttlebutt
or
dat.
If,
if
you
know
about
those-
and
by
that
I
mean
that
users
don't
usually
run
bitcoin
and
ethereum
nodes
on
their
laptops,
right,
they'll
have
some
kind
of
server
somewhere,
if
they're,
if
they're
running
them
and
the
servers
are
going
to
talk
to
each
other.
M
But
your
your
laptop
is
effectively
going
to
work
as
a
client
to
those
servers.
It's
not
going
to
act
as
a
pure,
exactly
and
so
we're
we're.
Taking
that
same
approach,
which
means
that
the
the
the
seed
nodes,
which
is
what
we
call
them,
interact
with
each
other
on
a
pure
basis,
pretty
pure
basis,
but
client
machines
interact
on
a
client-server
basis
with
appears
with
with
the
seed
nodes
in
terms
of
storage.
As
I
said,
we're
using
git
and
I'm
really
using
git
as
a
database.
M
We're
using
some
of
git's
features
to
essentially
name
space,
different
code
repositories
inside
the
same
physical
location.
On
your
hard
drive,
the
both
the
clients
and
the
servers
or
both
the
la
you
know.
Your
laptop
and
a
seed
node
have
the
same
structure
in
the
same
database
so
that
that's
that
allows
us
to
use
git
replication
and
we
call
this
the
monorepo
colloquially,
because
it's
kind
of
like
a
huge
repo
with
lots
of
other
repos
inside,
and
this
is
of
course
hidden
from
the
user.
M
The
user
works
as
usual,
with
with
a
working
copy
and
and
they
push
and
pull,
and
this
is
just
kind
of
the
the
implementation,
the
way
we're
storing
things
and
yeah
and
in
terms
of
the
the
kind
of
transport
we're
using
quick.
So
the
kind
of
was
going
to
be
http
3
at
some
point,
but
it's
a
udp
based
protocol
that
is
pretty
efficient.
You
can
kind
of
multiplex
it
with
streams
and
stuff
like
that
and
within
quick.
M
We
use
the
git
protocol
a
bit,
but
the
quick
transport
allows
us
to
yeah
to
have
multiple
streams
running
at
the
same
time,
which
is
quite
handy
and
then
finally,
identity,
which
is
a
complex
one.
I
think
a
lot
of
different
peer-to-peer
projects
are
trying
to
solve
this
at
the
moment
and
there
isn't
really
like
yeah.
So
ceramic
has
a
solution
for
this
as
well.
There
isn't
really
something
that
has
been
fully
accepted
yet
so
when,
when
we
started
developing
this,
we
were
thinking
of
the
idea
of
essentially
a
chain
of
trust.
M
So
essentially,
when
a
project
is
created,
an
identity
for
it
is
created,
and
when
that
identity
is
updated,
there
needs
to
be
a
sort
of
proof
of
that
update
and
whoever
is
trusted
in
the
original
project
is
trusted
to
make
that
change,
and
they
can
also
confer
trust
to
a
different
group
of
people.
So
here
in
this
little
example
on
the
right
at
the
bottom,
is
kind
of
like
the
first
version
of
the
identity
of
a
project
or
of
a
person.
M
So
it's
uses
the
same
people,
the
same
system
for
like
projects
like
code
repositories
and
for
people.
So
in
the
beginning,
let's
say
there's
your
a
so
you
created
the
the
project
and
and
you're
in
that
list
of
sort
of
signers.
Let's
say
we
call
them
delegates,
and
then
you
say:
okay,
I'm
going
to
add
b
and
now
b
can
also
sign
on
behalf
of
this
project
right
or
can
also
sign
for
this
project
as
well
as
me,
and
then
eventually,
a
and
b.
M
You
just
have
c
and
d,
but
you
can
always
trace
back
any
project
state
back
to
the
original
founder
of
the
project,
essentially
which
in
this
case
is
a
and
this
works
the
same
for
identities,
and
this
is
how
we
deal
with
the
multi-device
problem.
So
this
is
how
we
allow
a
user.
A
user
to
you
know,
have
a
laptop
and
a
mobile
phone
and
a
desktop,
and
it's
always
them-
and
we
don't
have
this
kind
of
issue
with
you
know
multiple,
multiple
devices.
M
Of
course
it
uses
publicly
crypto
and
again.
We,
when
we
think
about
storing
this
here,
there's
since
since
identities
are
they're,
not
really
a
dag
they're,
more
linear,
but
we
still
use
the
the
git
commits
to
represent
individual
versions
of
an
identity.
It's
it's
again
a
disjoint
branch.
So
it's
not.
Your
source
code
commits
it's
a
separate,
hidden
set
of
commits
that
are
part
of
the
git
object,
database
and
yeah,
and
just
then
just
a
little
bit
about
them.
M
The
way
this
works
the
kind
of
different
pieces
that
users
interact
with.
So
we
have
a
cli
now,
maybe
I
can
show
a
little
screenshot
or
something
which
is
how
users
are
onboarded,
so
you
create
your
identity
on
there,
you
create
your
keys,
etc.
You
create
projects
through
that.
You
have
your
your
local,
you
know
monorepo
as
we
call
it
which
is
stored
on
your
device.
The
cli
can
interact
with
the
web.
K
M
M
M
Let's
make
it
yeah,
okay,
yeah!
So,
like
a
user
would
basically
when
they,
when
they
want
to
use
radical
they
would
they
would
install
the
rad
command
line
tool,
they
would
run
rad
auth,
which
authenticates
them
or
it
creates
a
new
identity.
The
first
time
you
run
it.
You
know
username
passphrase,
which
protects
the
key
pair,
a
couple
of
other
things:
you'll
get
a
peer
id
which
is
per
device
and
then
you'll
get
a
urn
which
is
across
devices.
M
So
it's
your
user
id
kind
of,
and
then
you
will
run
something
like
rad
init
to
turn
a
git
repository
into
a
radical
project
which
doesn't
change
anything
in
the
repository
itself.
Really
I
mean
it
adds
a
remote,
but
it
doesn't
really
do
much
there,
but
it
creates
this
identity,
which
I,
which
I
showed
with
the
the
version.
So
it
creates
a
first
version
of
that
that
is
sort
of
content
addressed
to
the
to
the
to
the
commit
of
your
project
and
and
yeah.
And
then
you
can,
you
can
push
at
the
moment.
M
We
have
a
couple
seeds
running,
but
eventually
this
is
kind
of
all
going
to
be
abstracted
and
it'll
replicate
across
seeds
and
yeah.
This
is
the
kind
of
sinking
and
the
pushing
process
and
it'll
give
you
a
link
to
where
you
can
find
your
project.
Yeah
and
rad.
Clone
is
kind
of
the
reverse
it'll
it'll
it'll
clone
a
git
repository,
but
in
a
way
that
is
project
aware
essentially-
and
that's
it.
N
B
M
A
lot
of
people
are
asking
for
this.
The
answer
is
no.
This
is
something
that
is
possible
that
we've
been
talking
about
for
a
long
time
at
the
moment,
we're
kind
of
like
optimizing
for
the
open
source
use
case,
which
is
public
public
by
default.
Essentially,
there's
there's
one
sort
of
option
that
I
wouldn't
necessarily
recommend,
but
it's
it's
a
potential
path
forward,
which
is
that
you
can
kind
of
choose
where
you
want
your
data
to
be
replicated
and
if
you
don't
replicate
it
to
a
public
node.
M
M
D
D
D
M
B
M
M
Essentially,
that
creates
a
sort
of
network
of
people
who
can
drip
and
people
who
can
receive
drips,
and
this
is
kind
of
the
the
innovation
I
would
say,
because
if
you're
just
trying
to
stream
like
from
one
person
to
another,
there's,
that's
very
easy
to
write
a
contract
to
do
that,
whereas
with
drips.
What's
interesting
is
that
you
can
efficiently
stream
to
hundreds
of
people
as
well
as
receive
streams
from
hundreds
of
people.
M
So
for
things
like
crowdfunding
and
things
like
that,
it's
much
more
interesting
and
there's
a
mechanism
called
splits
which
I
think
is
also
super
interesting,
which
allows
you
to
yeah
when
you,
when
you
receive
a
drip
to
split
it
to
third
parties
to
anyone.
You
want
to
receive
a
share
of
that
money.
For
the
token.
O
O
We
are
100
founded
from
the
ethereum
foundation,
but
if
you
want
to
support
us
for
open
source
work,
we're
gonna
programmatically
splitting
100
of
those
funds
with
people
in
the
community
that
have
made
our
work
happen.
So
that's
one
of
the
unique
things
that
you
could
do
with
with
with
drips
and
the
website
is
drips.network
if
you
want
to
check
it
out.
L
Hey
so
there's
this
kitchen
and
there's
github
and
gitlab
and
like
the
kind
of
features
that
they've
like
added
over
the
years,
so
my
they're-
quite
even
you
mentioned
just
now
like
adding
comments,
so
my
questions
about
the
middle
to
long
term
scope
if
these
kind
of
things
like
ci
etc.
If
that
should
be
part
of
radical
itself
or
of
tooling
that
is
external
to
it.
What
you
envision
like
what
is
actually
part
of
it
or
what's
external.
M
Yeah
yeah
cool
yeah,
so
obviously
things
like
like
prs
and
issues
and
commenting
should
be
part
of
part
of
radical
because
there
needs
to
be
a
solution
for
yeah,
merging
histories
and
and
and
essentially
owning
your
own
data.
Right
like
you
want,
you
want
to
have
your
comments
on
your
machine.
You
don't
want
anyone
to
take
that
away
from
you.
You
want
to
be
able
to
work
offline
et
cetera
for
for
ci
cd.
I
think
it's
a
little
bit
different.
M
We
don't
really
intend
right
now
to
build
our
own,
like
you
know,
travis
or
or
github
actions
type
thing
like
our
own
ci
runner,
but
we
do
intend
to
integrate
with
an
open
source
solution
and
the
way
that
would
work,
I
think,
is
I
mean
the
the
main.
The
main
challenge,
or
the
main
thing
to
think
about,
is
getting
the
results
back
from
ci
right.
So
let's
say
you
so
today
you
could.
M
You
could
set
something
up
where,
essentially
you
say:
okay,
I
have
a
ci
runner
somewhere,
I'm
going
to
pull
a
a
git
repository
every
10
seconds
or
every
minute
for
changes,
and
since
radical
projects
or
seed
nodes
expose
a
git
repository
as
an
interface,
you
can
do
that
right
and
whenever
I
have
changes,
I'm
going
to
build
them
right,
so
the
the
ci
for
this
this
can
already
be
built
today.
The
question
is:
how
do
you
get
the
results
out
of
that
back
into
the
user
interface
right?
M
So
that's
one
thing:
we
need
to
figure
out
like
either
on
on
our
web
on
our
web
ui.
We
need
to
integrate
these
results
so
like
the
little
checks
right,
the
the
check
marks
on
your
pr
and
stuff
like
that
or
on
the
cli
and
then
the
second
thing,
that's
a
little
bit
more
complicated,
perhaps
is
trustless
ci
like
do
we
want
to
have
a
solution
for
first
something
trustless
where
you
you
can
say:
hey,
I'm
just
you
know
it's.
M
It's
maybe
going
a
little
bit
more
towards
something
like
fluence,
where
you're
saying
I
don't.
I
don't
know
where
this
is
going
to
be
run,
but
I
want
to
run
a
ci
job
and
I
don't
want
to
trust
anyone,
because
I
don't
really
know
who
to
trust,
but
I
want
the
results
to
be
verified
in
some
kind
of
way.
M
That's
obviously
much
more
complicated.
There
are
some
some
potential
solutions.
We've
we've
talked
about,
although
they
are
expensive,
they're
inefficient,
but
they're
possible,
and
one
at
one
potential
example
or
area
of
research
is
doing
something
like
a
bft
build
where
you
have
a
random
sample
of
like
three
nodes
that
build
that
run
your
ci
and
then
you
know
you
have
a
commit,
reveal
scheme
and
you
kind
of
see
like
okay,
they've,
all
agreed
on
the
ci
results.
M
Therefore,
it's
trusted
or
like
it's
sort
of
verified
or
oops,
one
of
the
one
of
the
the
nodes
has
a
different
ci
result
and
therefore
it
needs
to
be
rerun
because
it
looks
like
someone
is
lying
essentially
right
that
that's
complicated,
it
relies
on,
like
deterministic
builds
and
a
bunch
of
other
things
like
that
or
deterministic
tests.
But
it's
it's
potential
area
of
research.
G
M
So
not
yet
at
the
moment,
but
you're
working
on
this
yeah,
so
we
we
have
the
the
tech
to
do
that.
It's
not
super
reliable
right
now,
so
we
have
it
off
by
default,
but
yeah.
Essentially
that's
that's
kind
of
the
goal
is
to
sync
between
seed
nodes.
There
there's
there's
not
really
at
the
moment
like
we're,
not
really
looking
to
sync
between,
as
I
said,
like
user,
like
laptops
and
seed
nodes
due
to
like
things
like
nat,
traversal
and
and
all
the
complexity
there.
B
A
Yeah,
thank
you
speakers.
Thank
you
teams
today.
I
think
we
had
three
awesome
talks
and
have
now
more
information
about
all
the
projects
and
waiting
for
the
more
updates
and
releases,
and
thank
you
all.
Let's
enjoy
now
some
snacks
and
drinks
we
have
some
beer,
juices,
etc,
please
network
and
enjoy
the
evening.
Thank
you.
So
much.