►
From YouTube: Bluesky and IPLD - Jay Graber
Description
Bluesky
A
Hi
I'm
Jay
I
run
blue
sky
and
we
are
a
company
building
at
a
centralized
social
protocol
that
uses
ipld
you've,
probably
heard
of
us
in
association
with
Twitter,
since
we
started
out
as
a
project
there.
But
let
me
give
you
some
brief
background
to
catch
you
up
on
who
we
are
how
we
started
so
in
2019,
Jack
Dorsey,
who
is
Twitter's
CEO
at
the
time,
announced
that
they'd
be
funding
a
decentralized
social
protocol
in
his
initial
tweet,
he
listed
four
reasons
for
why
Twitter
would
be
funding
this
project.
A
A
Another
is
that
the
incentives
of
social
platforms
push
towards
promoting
content
that
generates
outrage,
and
this
doesn't
seem
very
healthy
for
society
and
then
another
point,
which
is
basically
some
observation
about
the
state
of
the
ecosystem,
which
is
that
new
decentralized
technologies
make.
It
seem
possible
to
rebuild
Twitter
as
a
protocol
in
a
way
that
didn't
seem
possible
10
years
ago.
A
So
I
agree
with
most
these
reasons
and
I
also
think
that
decentralizing
social
at
a
technical
level
doesn't
by
itself
necessarily
solve
all
these
problems,
but
it
distributes
power
over
the
network
and
it
allows
many
more
entities
Beyond
one
company
to
build
Solutions
and
many
more
communities
beyond
the
community
of
one
company
to
self-govern
their
part
of
the
network.
So
I
think
that
this
is
really
the
right
approach
to
start
solving
these
problems
at
the
higher
levels.
A
So
in
2020,
Twitter
brought
together
some
outside
collaborators.
In
a
matrix
chat
room,
including
myself,
to
discuss
the
problem.
Space
I
wrote
up
an
ecosystem
review
that
compared
existing
decentralized
social
networks
and
in
2021
Twitter
chose
me
as
the
Project
Lead.
So
I
set
up
an
independent
company
to
build
out
the
vision
for
Blue
Sky
I'd
proposed
I
did
not
want
to
be
a
part
of
Twitter
at
the
time,
because
I
figured
a
lot
of
things
could
change
and
even
though
Twitter
was
you
know,
wanting
to
really
work
closely
with
blue
sky.
A
At
the
time
who
knows
what
could
happen
in
the
future
and
I'm
really
glad
I
did
that?
Because
now
Elon
is
not
my
boss
and
whatever
changes
Elon
makes
I
hope
people
start
recognizing
that
it's
pretty
vulnerable
position
when
democracy
depends
on
discourse
happening
on
social
platforms
that
can
be
so
quickly
changed.
A
Centralization
is
a
structure
that
lends
itself
to
Rapid
change
and
that
change
can
be
for
good
or
bad,
and
now
that
we
know
the
basics
of
how
social
media
works,
I
think
it
might
be
healthier
to
turn
it
into
a
more
stable,
neutral
infrastructure
layer
for
public
conversations,
so
in
2022
I
received
some
funding
and
then
I
hired
a
team,
and
so
this
is
our
current
Dev
team.
We
have
three
developers
on
the
team.
A
A
A
So,
with
this
team
on
board,
we
did
some
more
research
and
settled
on
a
technical
architecture
this
year,
and
we
had
four
major
design
questions.
How
do
we
make
the
system
usable,
scalable,
portable
and
accountable
to
its
users?
We
want
it
to
be
as
scalable
as
mainstream
social
applications,
so
users,
sorry
as
usable
as
mainstream
social
applications
and
scalable,
so
that
users
don't
have
to
like
learn
too
many
new
things
like
you
know
the
problems
they're
just
talking
about
Key,
Management
I,
just
don't
expect
most
users
to
want
to
figure
this
out.
A
We
also
want
it
to
be
as
scalable,
so
you
have
billions
of
users
without
running
into
performance
limitations
that
require
you
to
be
doing
novel
r
d
on
the
fly
to
try
to
overcome,
and
so
these
considerations
suggested
that
we'll
need
some
traditional
service
providers
like
hosting
services.
But
if
there
are
entities
in
the
network
like
this,
we
want
user
data
to
be
easily
portable
between
them,
so
users
don't
get
locked
in
and
for
any
entity
that
ends
up
with
power
in
the
network.
A
A
A
A
The
problem
is,
you
can
get
locked
into
the
site
you
sign
up
at
so
if
you
sign
up
to
be
skydat
up,
it's
kind
of
hard
to
move,
even
if
the
network
tries
to
help
you
move
like
by
doing
a
redirect
user
server.
So
let's
be
willing
to
help
with
that
redirect.
So
if
someone
looks
up,
Alice
at
bsky,
dot
app
be
sky.app
has
to
say:
Alice
move
to
food.com
go
over
there,
but
what
if
the
sky.app
unexpectedly
disappears?
Alice
is
out
of
luck.
A
A
A
To
mitigate
these
downsides
of
federia
networks,
we
borrowed
some
properties
from
peer-to-peer
networks,
mainly
cryptographic,
IDs,
so
keys
and
content
addressing
hashes.
We
call
these
properties
self-authenticating,
meaning
the
Identity
or
data
can
be
independently
verified
without
a
server.
Although
you
can
have
one
for
convenience,
self-authenticating
authenticating
components,
they
don't
need
to
be
exclusive
to
peer-to-peer
networks,
but
peer-to-peer
networks
use
them
because
they
don't
have
servers
to
act
as
authenticating
authorities.
A
Another
possible
component
of
self-authenticated
protocols
is
verifiable
computation.
So
like
zero
knowledge
proofs,
these
groups
can
add
transparency
and
verifiability
to
computation,
that's
been
performed
and
there's
a
lot
of
new
use
cases.
This
could
unlock,
but
it's
outside
the
scope
of
our
current
design,
because
it's
new
and
complex
so
not
going
to
get
into
it.
A
Peer-To-Peer
social
networks
like,
for
example,
security,
but
if
you've
heard
of
that
use,
cryptographic
IDs
for
user
identities.
This
means
that
instead
of
your
base,
ID
being
like
Alice
at
bsky.app,
it
would
be
this
long
string
of
characters
representing
your
public
key.
You
can
give
this
key
a
nickname
like
Alice,
but
there's
nothing
unique
about
that
nickname
and
you
can't
find
the
user
by
it
to
find
people
in
the
network
at
all.
You
usually
have
to
introduce
some
kind
of
super
node
that
has
more
visibility
and
connections.
A
Ssp
calls
these
nodes
pubs,
I,
don't
think
it's
a
bad
thing,
but
it's
just
something
we've
observed,
which
is
that,
even
if
you
try
to
keep
your
peer-to-free
network
really
flat,
centralization
tends
to
emerge
when
you
start
optimizing
for
convenience
and
usability
ipfs
uses
content
addressing
to
find
data
by
hash
rather
than
by
location
in
the
network.
So,
instead
of
needing
to
know
where
something
or
someone
is
located,
you
can
just
look
them
up
in
this
distributed
hash
table.
A
A
So,
given
that
peer-to-peer
networks
have
these
really
cool
self-authenticating
properties,
but
tend
to
end
up
reintroducing
centralization
for
convenience,
we
decided
why
not
just
start
off
by
assuming
servers
are
going
to
do
the
heavy
lifting
to
create
a
good
user
experience.
So
our
architecture
combines
servers,
cryptographic,
keys
and
content.
Addressing
the
first
draft
of
the
protocol
we
put
out
was
called
adx
or
the
authenticated
data
experiment
which
we
released
on
GitHub
earlier
this
year,
and
now
it's
called
the
at
protocol
or
authenticated
transfer
protocol.
It's
maturing,
but
it's
still
not
done
so.
A
A
The
network
architecture
is
Federated,
so
there's
clients
and
servers
the
base.
Identifier
is
a
did
or
decentralized
identifier,
and
that
connects
a
human,
readable
name
like
alice.com
with
a
public
key.
The
did
method
we're
currently
using
did
PLC
is
really
just
a
placeholder
until
something
better
comes
along,
but
structurally.
We
think
this
is
probably
the
right
approach.
A
User
data
is
stored
in
repos,
which
are
analogous
to
git
repositories,
and
it's
these
repos
that
use
ipld
to
content
address
every
record.
So
git
and
GitHub
are
a
good
analogy
for
how
this
is
going
to
work.
Imagine
if
your
Social
account
was
hosted
in
git
repository
and
you
could
use
a
site
like
GitHub.
We
could
also
easily
move
to
an
alternative
like
gitlab
or
bitbucket.
This
is
the
relationship
between
the
user
repos
and
the
servers
that
we
call
pds's
or
personal
data
servers.
A
The
specific
kind
of
Merkle
tree
we're
using
is
the
Merkel
search
tree
and
the
nice
property
is
that
trees
are
always
probabilistically
balanced,
so
to
wrap
it
up.
Here's
a
high
level
overview
of
the
app
protocol.
Network,
you
have
users
with
the
human
readable
username
as
well
as
a
key,
and
it's
linked
through
a
did.
The
user
keys
are
currently
on
the
server,
but
that's
just
because
we
didn't
want
to
get
into
client-side
Key
Management
right
now,
because
we
weren't
super
confident.
We
could
create
a
really
smooth
user
experience
for
that
piece.
A
It's
possible
to
do,
though,
and
that's
something
that
we'll
definitely
pursue
in
the
future.
The
servers
Federate
with
each
other
and
to
get
a
global
view
into
the
network
and
do
things
like
search
a
trending,
hashtag
or
receive
curated
feeds.
There's
these
aggregators
that
index
content
across
the
network-
and
this
is
sort
of
the
basics
of
how
we
envision
this
network
working.
A
You
can
check
out
the
current
state
of
the
specs
on
atproto.com
and
the
code
is
on
GitHub,
to
put
it
all
together,
we're
building
a
client,
app
called
Blue
Sky
on
top
of
the
at
protocol
layer.
I
haven't
talked
about
some
of
the
things
Jack
mentioned
in
his
original
tweet,
like
moderation,
curation
in
communities,
because
these
are
really
application.
Level
experiences
that
we're
still
working
on,
but
this
year
was
about
length
infrastructure
and
making
sure
that
the
stuff
that
we
do
build
is
going
to
be
built
on
a
very
strong
base
layer
of
portability.
A
We
announced
a
waitlist
for
a
private
beta
last
week
and
we
got
over
60
000
users,
which
is
a
lot
more
than
we
were
expecting
for
a
test
group.
So
if
you
want
to
get
in
early
and
you're
willing
to
give
some
user
experience
feedback,
the
best
way
to
do
that.
Right
now
is
probably
just
a
DM
me
on
Twitter,
we'll
see
how
well
this
scales
and
also
we're
hiring.
A
We
could
use
a
mobile
Dev
to
help
out
with
the
app
front-end
ux
developer,
to
help
us
prototype
these
approaches
to
moderation,
reputation,
curation,
that
we're
taking
and
systems
or
protocol
engineer
to
work
on
the
app
protocol.
So,
if
you'd
like
to
join
us
reach
out-
and
these
are
the
relevant
websites,
if
you
go
there,
you'll
find
links
to
like
the
Matrix
Dev
room,
the
jobs,
everything
else.
So
thank
you.