►
From YouTube: Local Offline Collaboration Monthly 2021-03-10: Fission
Description
On our March 10 call, Boris Mann (https://twitter.com/bmann) and Brooklyn Zelenka (https://twitter.com/expede) introduced us to Fission's approach to fast, local-first app publishing on IPFS.
https://fission.codes/
Learn more about the monthly calls of the IPFS Local Offline Collaboration Special Interest Group: https://github.com/ipfs/local-offline-collab/issues/25
A
We've
got
everything
from
data
oriented
problems,
challenges
that
we
might
be
able
to
use
these
technologies
for
sometimes
demonstrations,
and
today
we
would
like
to
welcome
phishing,
boris
and
brooklyn,
who
will
be
talking
to
us
about
their
work
in
developing
the
web
native
file
system
and
a
set
of
technologies
that
allow
people
to
get
onto
the
decentralized
web,
but
using
very
familiar,
centralized
technologies,
metaphors
and
tools.
So
without
further
ado.
Welcome
show
us
what
you
got.
B
B
It
is
kind
of
a
lot
so
for
us
we're
thinking
of
this
as
designed
for
front-end
developers,
so
you
don't
have
to
become
a
full
stack,
developer,
devops
expert,
the
main
open
source
sdk
that
we
create.
We
call
web
native
right
now
it
has
user
accounts
file
and
data
storage
and
more
that
you
can
just
add
to
your
app.
B
B
So
a
recent
slide
from
brook.
So
we
really
think
that
you
can
build
entire
apps
at
the
edge
and
they
can
be
offline
first
and
local,
which
means
not
having
to
learn
servers,
datastore
devops
pieces.
So,
instead
we
put
those
things
into
the
front
and
into
the
client
side,
so
just
in
javascript,
anything
that
compile
down
to
javascript
can
work
with
our
sdk,
so
obviously
interesting
things
in
the
direction
of
stuff
like
web
assembly
as
well.
B
The
way
that
we
think
about
it
is
that
we
set
ourselves
the
goal
that
this
stuff
should
work
in
any
browser,
including
mobile
without
plugins,
so
we
lean
pretty
heavily
into
modern
browser
apis,
specifically,
we
target
things
that
work
on
all
major
browsers,
including
mobile,
and
that's
kind
of
our
line
in
the
sand.
If
something
only
works
on,
one
browser
doesn't
really
help
us.
So
that's
what
we're
targeting
the
web
crypto
api
is
a
key
piece
where
we
in
fact
link
your
identity
with
a
private
key
held
by
your
browser.
B
Web
workers,
service
workers,
indexeddb,
pwa
and
web
app
manifests.
So
for
that
we
really
think
that
every
app
on
fission
powered
by
web
native,
should
it's
an
app
in
in
fact
should
use.
Some
of
this
modern
tech
should
be
configured
as
a
pwa
should
be
added
to
a
home
screen
should
be
be
able
to
have
its
own
separate
icon
if
you're,
if
you're
on
on
desktop-
and
you
should
set
it
up
so
that
the
the
parts
of
your
app
that
makes
sense
do
in
fact
work
offline.
B
If
you
take
the
servers
out
and
you
make
accounts
owned
by
users,
then
you
have
to
change
how
this
stuff
works.
We
also
put
a
bunch
of
stuff
in
dns.
Ipns
is
not
something
that's
reliable
enough
today,
for
a
variety
of
reasons
and
dns
ends
up
becoming
a
cache,
and
we
use
dns
link,
obviously
to
also
work
with
the
rest
of
the
web
by
running
ipfs
gateways.
B
So
people
can
visit
a
fission
app
and
it
they
will
visit
it
over
https
and
then
web
native
loads,
js
ipfs
and
from
then
on.
The
app
actually
communicates
directly
and
natively
over
ipfs
the
web
native
file
system,
which
dietrich
mentioned
off
the
top
that's
another,
something
that
brook
has
architected
and
developed
we're
basically
developing
an
encrypted
file
system.
B
It
secures
metadata,
is
performant
and
designed
to
to
kind
of
hold
all
the
users
data
and
hold
permissions
for
which
apps
can
read
it
right
into
it.
So
any
any
browser
device
that
you
link
in
you
can
then
access
your
file
system
and
it's
just
there
and
it
continues
to
be
end
encrypted.
So
fission
helps
sync
and
store
this
data
natively
over
ipfs,
but
it's
the
encrypted
portions
are
encrypted.
We
don't
have
the
key
and
of
course,
because
all
of
these
things
are
represented
by
ipfs
hashes.
B
B
B
B
B
So
it's
talking
over
web
sockets
with
js
ipfs,
it's
being
served
up
by
the
gateway
that
we
run
when
people
first
visit
it,
and
we
have.
I
don't
know
what
the
latest
is
over
over
1200
apps
deployed
on
the
main
fission
service
right
now
and
yeah.
Just
talking
about
we
use
haskell
and
elm,
as
as
our
main
internal
languages.
B
B
Not
a
cache
per
se,
but
basically
saying
we're
essentially
publicly
putting
various
things
in
dns,
so
each
user
has
their
own
file
system
in
the
web
data
file
system,
and
so
we
need
to
keep
track
of
the
route.
So
we
only
keep
track
of
root,
sids
and
so
the
root
sid
is
at
a
well-known
location
in
dns.
So
every
user
account
has
a
dns,
subdomain
and
dns
link
entry
and
every
app
has
a
subdomain
and
a
dns
link
entry.
So
you
could
do
various
things.
B
I've
been
thinking
about
how
we
could
build
something
for
users
where
they
could
pin
apps
and
their
own
file
system,
and
it
would
be
simple
to
just
look
that
up
in
dns
and
make
sure
that
you've
got
the
latest
hash
that
you're
that
you're
pinning
with
the
nice
properties.
That,
of
course,
we
get
all
of
the
files
and
blocks
underneath.
C
B
B
Yeah,
so
there's
even
actually
apps
that
aren't
published
on
vision,
so
you
can
use
the
web
native
sdk
and
put
your
static
site
anywhere,
so
that
doesn't
even
count
all
of
them.
The
main
thing
that
people
have
said
is
that
oh
wow,
it
was
80
lines
of
code
to
add
a
user
account
system
and
persistence
and
file
storage
and
data
storage.
That
was
really
smooth.
B
That
was
really
easy,
so
we're
gonna
get
a
lot
of
people
who
ideally
are
in
the
front
end
and
instead
of
having
to
pick
like
step,
one
being
learning
how
to
become
a
full
stack
developer,
what
we're
seeing
is
like.
Oh
it
in
fact,
was
easy
to
add
these
interactive
full
app
abilities
to
it.
That's
the
consistency
and
I'd
say
the
other
side
is
that
people
are
very
interested
in
user-owned
data.
D
And
just
to
jump
in
really
quick,
one
of
the
really
nice
things
since
you
have
antenna
encryption
encryption
at
rest
is
your
data
can
be
stored
literally
anywhere
and
replicated,
and
it's
fine
right
assuming
that's
their.
You
know
the
encryption
works
right.
So
sometimes
people
have
concerns
about
like
well.
B
Yeah
brooke
was
on
the
ipfs
ipld
security
call,
so
that
was
great
fission
drive.
So
this
is
our
first
party
app
that
we
built
as
a
default
browser
that
users
can
actually
inspect
and
look
at
their
entire
file
system,
because
each
app
actually
stores
data
in
the
user
file
system.
The
user
can
in
fact
browse
to
that
data.
Look
at
it
inspect
it
and
so
on.
B
So
think
of
this,
as
maybe
your
library
folder
or
your
documents
folder
in
in
your
operating
system,
where
apps
put
stuff
increasingly
desktop
and
mobile
advertise
mobile
operating
systems.
Ask
for
permissions
for
things
and
that's
the
same
pattern
that
fission
is
following,
so
I've
shown
here
a
screenshot
of
you
actually
have
to
give
drive
itself
access,
so
we
can't
cheat
because
it's
all
cryptography
where
fission
can't
say
like
oh
well,
let's
give
fission
drive
special
permission.
We
can't
do
that.
It's
up
to
the
user,
so
I've
showed
this.
B
I
can
show
it
in
as
a
demo
as
well.
It
does
work
offline,
stephen
who's.
The
author,
the
primary
lead
author
on
the
on
this
app
and
a
lot
of
the
web
native
api,
is
on
the
call,
so
it
mix
and
matches
with
local
storage
and
indexeddb
to
store
things
and
then
sync
again
when
it's
online
work
in
progress
always
hard
to
do
across
browser
and
mobile
and
and
all
that
good
stuff
and
our
good
friend
ios
is
always
a
bit
cranky
about
various
things.
B
B
B
B
The
apps
folder
I've
linked
it
to
an
app
called
tiddlywiki,
and
it's
got
a
little
index
file
in
here
all
of
this
stuff.
The
default
view
is
that
we
users
should
be
secure
in
knowing
that
their
stuff
is
private
by
default.
So
you
specifically
have
to
go
into
the
public
folder
and
put
things
in
the
public
folder,
so
I
can
browse
in
the
screenshots.
B
B
F
B
B
And
say
not
red,
no
red,
not
red
and
green,
and
I
will
hit
save
and
close,
and
I
will
right
click
again
so
underneath
it
should
give
me
a
link
to
a
new
file
that
I
will
paste
in
and
this
is
not
red.
So
I've
just
done
a
live
edit.
It's
pushed
it
to
ipfs,
I
get
the
link
to
it.
Obviously,
the
other
file
still
exists
and
it's
still
red,
because
we've
got
this
unique
hash
in
the
middle
and
I
can
also
get
the
direct
sid.
B
B
B
B
I'll
sign
in
what
it's
going
to
do
is
it's
going
to
say
you
know:
can
I,
as
the
quotes
app
right
to
an
application
folder
and
if
you
want
to
use
a
vision
app,
you
have
to
give
access
to
at
least
the
application
folder,
because
it
needs
a
place
to
put
its
files
because
it
doesn't
have
its
own
dedicated
storage.
Today,
so
I
say
yes,
it
shows
what
I'm
logged
in
as
here
I'll.
B
That
was
said
by
bill
french
way
back
in
the
day.
So
just
a
little
like
personal
quotes
thing
and
then
what
I
can
do
is
I
can
go
back
up
here
and
I
may
need
to
do
a
hard
refresh.
We
don't
have
like
live
updating
or
anything.
That's
pushing
live
changes
right
now,
so
that'll
that'll
be
coming
yeah.
So
this
is
not
not
live
in
here
right
now.
F
G
B
B
So
just
talking
through
how
the
cli
works,
I
think
this
is
very
interesting.
I
believe
that
we
are
the
only
cli
tool
that
is
natively
used
as
ipfs,
and
this
is
what
I
mean
by
that,
so
we
are
actually
downloading
and
installing
our
own
ipfs
node.
So
our
target
market
is
not
necessarily
people
that
are
deep
into
the
decentralized
web,
but
our
target
market
is
everyone,
so
a
front-end
developer
should
be
able
to
get
all
of
these
features
without
even
having
to
know
that
ipfs
is
involved.
It's
just.
B
F
B
Mac
os
right
now
we're
recommending
that
windows
users
use
wsl2
to
do
that,
we'll
circle
back
around
for
any
of
windows.
Support
at
some
point
vision,
app
register:
you
can
create
a
new
app
with
subdomain,
we'll
will
generate
a
huge
subdomain
name
for
you
and
then
vision,
app,
publish
this
actually
publishes
the
app
natively
over
apfs,
so
most
other
systems
that
we've
seen
will
actually
publish
over
an
http
call
and
then
turn
it
into
ipfs
on
the
server
side.
B
B
We
turn
off
the
node
right
now
when,
when
the
publish
succeeds,
you
can
also
give
it
a
watch
flag
and,
as
you
do
edits,
it'll
just
live
update
your
your
files
and
the
dns
link
root.
In
the
background.
So
that's
a
pretty
neat
thing.
I
could
have
done
that
and
just
refreshed
a
page
and
showed
you
that,
as
I
was
making
edits,
it
was
it
was,
live
and
available
everywhere
at
a
dns
address.
B
B
So
you've
got
everything
running
locally.
You've
got
a
hash
published
it's
actually
available
in
your
local
node.
So
if
you're
running
fission
watch
theoretically,
you
should
be
able
to
just
run
that
directly
locally
offline
in
your
in
your
browser.
That's,
but
that's
the
published
version.
It's
the
same
as
the
there's,
no
difference
we
bootstrapped
to
the
vision,
servers
and
I'm
sorry,
I'm
I'm.
I
may
pronounce
your
name
wrong
marcin.
Is
that
how
you
pronounce
your
first
name?
C
B
Okay,
I
I
like
to
ask
before
people
using
the
link
name
light.
All
it
is
so
lidl
has.
Has
this
issue
already.
We've
looked
at
some
of
these
things.
Steven
has
written
this
up.
I'll
share
the
link
afterwards
as
well
in
our
forum
of
a
couple
of
different
ideas,
of
how
to
make
this
work,
and
you
know
we.
B
We
would
love
this
to
work
more
reliably.
It's
ridiculous
that
we
can
run
a
node
locally,
but
then
can't
really
connect
to
it,
and
so
here's
a
couple
of
different
ideas
of
of
of
stuff
that
we
might
need
to
do
and
enable
by
default,
is
always
the
huge
thing
right.
If
we
don't
get
to
enable
by
default
in
ipfs
in
various
things,
then
very
few
people
will
discover
it
right
comments,
libel
or
steven.
C
It's
doable
because
you
don't
need
a
tls
cert,
a
localhost's,
secure
context
and
we
should
be
able
to
enable
that
by
default
in
ipvs,
desktop
and
brave,
even
before
go
itfs
decides
to
do
that
in
go
ipfs
doing
that
by
default
may
make
less
sense
because
it's
usually
run
on
the
like
server
in
on
the
server
context.
But
there
are
like
some.
We
have
some
ideas
how
to
like
automate
the
tls
search
we
have.
C
B
B
F
B
So
that's
a
method
to
kind
of
do
stuff.
That's
that's
somewhat
collaborative.
We
do
plan
on
having
you
know
a
shared
permission
and
group
structure,
so
permissions
and
encryption
are
key
and
we're
gonna
do
stuff
with
that
to
to
to
give
that
capability
to
to
developers
building
apps.
Definitely,
as
you
saw
I
had
to
hard
refresh,
I
think
one
of
the
biggest
challenges
is
in
fact
that,
like
caching,
local
storage,
do
I
have
the
newest
version
of
this
app
even
never
mind
the
data
inside
of
it.
B
So
we've
already
thought
about
things
like.
Oh,
we
should
probably
do
a
server-side
check
and
if
there's
a
newer
app,
then
we
give
one
of
those
little
banners
that
says,
do
you
want
to
reload?
And
you
see
that
in
I
use
an
email,
app
called
missive,
you
see
it
in
rom
research
that
have
this
like:
hey
you've
got
a
new
version,
you
should
refresh
and
then
the
other
thing
is
something
like
pub
sub.
We
use
it
for
device
linking
today.
B
D
D
Secure
session
on
top
of
the
web
sockets,
we
also
used
to
do
this
on
top
of
pub
sub,
where
we
do.
What
looks
it's
not
exactly
the
same
but
similar
to
like
a
tls
handshake,
do
key
exchange
with
a
session
key
and
then
can
securely
pass
information
back
and
forth
yeah
so
that
that's
the
real-time
stuff
there's
also
because
boris
mentioned
you
know
getting
the
latest
update
on
an
app
pushing
the
top
sid
of
file
assistant,
apps,
etc
over
pub
sub,
so
that
each
peer
is
now
broadcasting
hey.
D
I
did
an
update
or
hey
I
published
this
and
the
htcp
gateway
accepted
it.
Here's
the
signature!
You
should
all
synchronize
with
this
version
now
something
that
we're
calling
the
and
from
you
know
several
slides
ago.
It's
in
that
stack
an
ephemeral
store
so
that
we
can
do
really
quick
updates
and
then-
and
things
like
you
know,
per
character,
changes
and
then
persist
it
at
some.
D
You
know
known
interval
or
when
things
are
in
a
good
state
or
or
whatever,
so
that
that's
more,
it's
a
little
bit
more
of
a
flexible
store,
rather
than
our
actual
persistent
file
system,
which
also
has
some
extra
stuff
in
there
too.
It's
non-destructive
and
whatnot.
So
we
have
to
keep
a
bunch
of
links
for
each
change.
So
we
want
this
to
be
to
be
larger,
collaborative
editing.
D
Yeah,
we
looked
at
auto,
merge,
yjs,
a
bunch
of
ct
based
systems.
They
pretty
much
work,
especially
for
real-time
collaboration,
which
is
great
but
for
longer
documents
and
longer
term
data.
They
they
fit
less
well
or
for
large
data
sets
they
they
fit
lost.
Well,
so
I
have
been
thinking
about
and
and
actually
the
the
main
guy
behind
auto
merge
has
also
done
a
little
bit
of
work
in
this
direction
too
different
model,
zero,
dt
for
collaborative
editing
and
then
large
scale.
D
Aggregation
of
data
so
pushing
over
essentially
gossip
sub
gossip
pub
sorry
information
in
a
series-
that's
just
purely
set
based
and
based
on
data
log,
and
then
we
can
get
all
kinds
of
nice
properties
like
much
much
much
better
performance.
Only
syncing
subsets
of
data
being
able
to
put
data
together,
pull
it
back
apart.
It's
isn't
fall,
tolerant,
like
there's
a
bunch
of
stuff
like
that.
That
falls
out
of
this
and
doesn't
matter
if
it's
going
through
the
internet
or
on
a
local
device
sharing
between
multiple
apps.
D
D
So
having
that
be
able
to
be
this
substrate
for
real
time
and
data
set,
sharing
and
doing
databases
where
parts
of
the
data
are
available
to
one
one
participant,
but
not
another
right
and
having
everything
still
work,
which
is
also
related
to
this.
This
database
idea
project
cambria
data
schema
merging.
We
have
some
thoughts
on
doing
shared
schemas
between
applications
as
well
and
how
to
translate
between
them.
D
Since
everything
is
data
log
based
in
the
current
model,
we
still
have
to
do
a
little
bit
more
r
d
around
this,
it's
fundamentally
schema-less,
so
there's
cambria
lets
you
take
schema
and
schema
b
and
translate
between
the
two
and
it's
potentially
lossy
like
you,
you
may
lose
information
or
have
some
defaults
put
in
if
you're
going
one
direction
or
another,
the
schema-less
layer.
There's
this
extra
step
of
you've
got
to
take
from
the
this.
D
Somebody
recently
described
it
as
this
just
loose
soup
and
bring
it
up
into
some
structured
data,
and
so
typically
we
should
be
able
to
skip
the
translation
from
schema
to
schema,
but
we
may
still
need
to
have
some
default
fields
and
whatnot,
so
it
ends
up
looking
a
lot
like
cambria
or
if
an
application
expects,
expects
things
in
a
certain
format
and
needs
to
deliver
it
to
say
a
traditional.
You
know
rest
based
api.
You
can
then
translate
that
and
send
it
across.
So.
B
Specifically
for
offline
apps,
this
is
the
the
simplified
version
that
my
tiny
brain
understands
about.
Project
cambria
is,
and
we
have
a
video
presentation
about
that-
that
that
I
can
throw
in
the
links
as
well
is
basically
that
a
version
one
app
can
collaborate
with
a
version
1000
app,
so
not
just
drift
over
the
data,
but
you
have
drift
over
the
app
itself
and
project
cambria
helps
solve
some
of
these
things
again.
Some
of
this
is
well
known
for
building
things
like
desktop
apps
or
mobile
apps.
B
B
We
then
looked
at
other
things
like
orbit
db,
and
it
doesn't
really
have
the
concept
of
encryption
or
private
data,
and
so
we
have
been
finding
it
easier
to
build
on
top
of
our
system
that
has
already
solved
privacy
and
permissions,
because
that's
the
key
point,
not
the
data
store
layer,
there's
other
folks
that
are
adopting
some
of
our
stuff.
So
the
query
team
has
looked
at
and
implemented.
B
Open
specs.
We
have
a
white
paper
and
a
bunch
of
other
stuff
where
we've
documented
it
we're
happy
to
work
at
the
r
d
layer
at
the
protocol
layer,
as
well
as
up
at
the
app
layer.
I'm
happy
to
work
with
people
on
any
of
this
stuff.
Final
thing
that
I
kind
of
wanted
to
say,
and
I
think
this
is
my
lab.
I
think
this
is
my
last
side
the
way
that
we
think
about
fission.
All
our
stuff
is
open
source,
so
we
run
a
hosted
service.
B
B
I've
been
using
this
term
constellation
provider
and
we're
focused
on
on
developers
and
users
being
able
to
just
sign
up
and
stuff
works
and
we're
getting
good
adoption,
and
we
are
looking
to
have
more
of
that.
But
you
from
that
diagram
that
I
showed
earlier
like
you
know
you
need
to
know
some
devops
you
need
to.
B
What
vision
does
having
their
own
app
names,
because
we've
got
this
user
identity
and
publishing
and
file
system
in
a
box
that
makes
for
a
really
really
strong
set
of
capabilities
already,
and
what
we
want
to
do
there
is.
We
want
to
federate
so
web
finger
is
probably
the
obvious
thing
there
rosano
who
I
mentioned
earlier.
B
He
and
I
did
a
little
experiments
because
he's
coming
from
the
remote
storage
world
and
that's
where
we've
gotten
to
so
far
is
you'll
enter
in
something
that
looks
like
an
email
address.
So
this
is
a
common
pattern
across
things
like
matrix
or
mastodon,
or
other
systems
that
matrix
doesn't
use.
Webfinger
mastodon
does,
but
we
think
that's
a
pretty
strong
common
pattern
across
things,
and
then
you
know
that's
what
we
envision
is.
B
We
can
have
lots
of
this
stuff
running
and
federate
between
all
of
these
things,
and
then
you
have
more
and
more
folks
online
running
things
that
are
in
this
client-side
app
mode
and
more
ipfs
with
strong
links
between
them.
It
doesn't
matter
if
an
app
is
published
on
fission,
server,
2
or
vision,
server,
one.
It
should
all
just
work
and
be
cached
and
pinned
transparently
and
that's
it
for
me.
G
B
Yeah
there's
a
lot
here
if
you
haven't
seen
it
before
yeah
we've
been
we've
been
working
on
this
for
a
while.
We
essentially
with
the
github
actions.
We
essentially
have
parody
with
netlify.
At
this
point
at
the
publishing
layer
you
know
we
can
handle
custom
domains.
Various
other
things
like
that.
The
new
upcoming
thing
that
I'm
super
excited
about
is
non-developers
being
able
to
clone
apps.
A
Very
interesting,
I
had
a
quick
question
about
platform
portability,
so
efficient
services
go
down
today,
my
application,
does
it
still
run?
What
do
I
have
to
do?
All
my
data
might
be
there?
Do
I
have
to
manually
set
up
some
things
like
sync
application
resources
and
assets
to
my
own
repo
or
data
store?
How
does
that
look
like
for
I'm
a
business
who's,
betting
on
vision
as
a
hosting
platform,
yeah
great
question.
B
B
Which
is
the
actual
issue
here
right,
so
you
know
we.
We,
we
map,
we're
just
running
cnames
for
all
of
these
things
which
which
map
to
one
ipfs
gateway.
I
run
my
personal
site
bmanconsulting.com
using
the
cloudflare
gateway,
where
the
current
version
of
that
of
that
hash
update,
will
remain
up
and
will
remain
available
right,
so
cloudflare
handles
that
layer.
So
the
critical
point
becomes
the
gateway
right
now
and
the
http
link
to
that.
B
It
should
just
be
run
and
keep
updated,
and
then
the
question
becomes
one
of
trust,
and
where
do
you
look
for
like
truth
of
the
like
newest
version
and
stuff,
like
that,
brooke
briefly
mentioned
things
like
signing
updates.
We've
got
this
proof
chain
because
everybody's
using
a
private
key
with
the
server.
So
you
you
we,
you
know
you
could
even
verify
on
your
own
that
in
fact
it
was
a
certain
identity
that
did
those
things
so
yeah.
That's
that's
kind
of
what
it
looks
like
right
now.
Dietrich
is.
B
B
B
D
That
actually
might
be
worth
mentioning
really
briefly,
because
you
know
a
lot
of
printing
services
spend
time
managing
pin
sets
for
users,
which
we
don't
do.
Everybody's
all
of
your
stuff
is
in
one
dag,
and
then
you
update
that
and
the
old
one
has
a
link
back
to
the
old
one
and
a
bunch
of
links
in
between
to
the
new
one
right.
B
C
D
D
D
Rather,
every
time
you
add
a
link,
because
it's
obviously
you
can't
have
loops
right
every
time
you
add
a
link,
it's
calculating
all
of
the
history
again
into
the
size
of
the
dag,
because
the
algorithm
is
just
very
simple:
it's
a
just
tree.
You
know
aggregation
applied
to
a
dag.
So
if
you
have
multiple
routes,
the
same
file
you'll
get
that
same
file
counted
multiple
times.
D
B
But
overall
you
know
every
release
of
go
away.
Pfs
is
more
stable
and
has
more
features
and-
and
that's
been
really
well
like
very
often
sometimes-
we've
had
issues
where
we're
like.
Okay,
we're
just
gonna
move
to
0.6.
You
know
there
were
very
0.4
point
x
days
where
we're
like.
Have
we
made
the
right
decision,
so
you
know
thank
you
to
the
protocol,
lab
teams
and
so
on
for
for
keep
doing
that.
I
think
the
rest
of
it
ends
up
just
being
okay.
What
does
it
mean
to
run
a
constellation
provider?
B
F
B
A
D
We
it's
like
there,
there
isn't
really
a
between
nodes.
It's
our
web
server
makes
async
requests
to
every
node
in
the
cluster
and
we
wait
for
the
first
one
to
finish.
So
we
get
streaming
updates
with
timeouts
and
something
you
know
stuff
like
that.
But
we
wait
for
the
first
one
to
finish
report
back
to
the
user
and
then
let
the
rest
of
them
keep.
D
B
In
part
is
leaning
into
the
native
protocol
in
it
in
a
very
nice
way
right
like
that's
the
thing
like
we
get
all
this
dedupe
and
all
this
other
stuff
like
that.
So
you
know,
there's,
there's,
there's
this
stuff
like
app
cloning
that
we're
gonna
put
people
like.
How
are
you
pulling
that
off
we're
like
that?
It's
it's
actually
mainly
the
protocol,
and
we
gave
it
a
name
and
put
stuff
on
top
of
it
and
give
you
a
new
subdomain
which
isn't
particularly
hard
but
is
novel.
A
Yeah,
that
is
one
of
the
visceral
mind-blowing
parts
of
people's
beaker.
Experience
is
they're
like
hey,
I
just
cloned
a
website,
and
now
it
put
my
name
on
it.
I
like
the
design
or
the
features
in
that
one
one
click
now
I
have
my
own
copy
that
I
can
run
and
modify
and
change
is
key
and
theme
and
we
need.
B
B
B
Yeah
yeah
exactly
this
is
great
like
thank
you
for
inviting
us.
I
think
you
know
like
just
let
us
know
how
else
we
can
help
with
this.
I
think
there's
probably
pieces
here
at
the
app
layer.
I'd
say.
One
thing
that
I
didn't
flag
is
as
another
item
to
kind
of
work
on
is
a
lot
of
apps
that
work
offline,
pwas
end
up
being
created
as
single
page
apps,
depending
on
the
framework.
B
F
B
C
Please
drop
a
comment.
If
you
have
like
something
that's
not
mentioned
there,
it
will
be
very
useful
because
we
will
block
some
time
this
year
to
create
a
proposal
I'll
make
sure
to
include
you
in
the
loop.
But
if
you
have
like
anything
not
already
written
down,
please
drop
it
there
because
that's
like
something,
we
really
need
to
do.
C
Yeah
yeah-
and
I
I
agree
specifically
for
like
the
routine
comment
most
of
problems
disappear.
If
you
use
subdomain
gateways,
I
mean
like
most
of
problems
disappear
when
you
like
have
like
the
content.
Root,
becomes
the
root
of
the
path
of
the
url
and
I'm
afraid,
there's
no
better
way
that
works
in
all
browsers
and
we
will
be
moving.
B
C
That
we
will
be
slowly
during
this
year
putting
some
pressure,
soft
and
hard
pressure
for
people
to
migrate
away
from
paths
which
start
with
ipfs
to
sub
domains.
Mainly,
we
will
be
disabling
things
like
cookies
or
some
like
more
advanced
apis
on
those
paths
and
that
way
people
who
really
want
to
run
websites
will
be
kind
of
like
slowly
transitioning
to
secure
subdomains
or
just
subdomain.
C
I'm
not
saying
that
those
sub
domains
with
cids,
but
just
like
you
said
you
are
giving
the
pet
name
subdomain
for
user,
and
also
it's
great
for,
like
kind
of
like
an
entry
drag
for
people
to
take
like
this.
Like
idea
of
self
identity,
they
may
experiment
with
your
own
names
fusion.app,
but
then,
if
they
have
their
own
domain,
just
like
did
you
ask
about
what
happens
if
your
service
goes
away
or
someone
wants
to
run
their
own?
C
B
So
one
of
the
things
that
fission
would
like
to
do
is
is
help
people
get
their
pwas
published
to
the
android
play
store
and
the
windows
store,
and
as
part
of
that,
so
manifest
made
me
think
about
it.
We're
essentially
we're
gonna
have
apps
on
fission,
or
we
have
already
and
we're
just
basically
gonna
we're
not
gonna,
come
up
with
a
new
format,
we're
going
to
ask
people
to
fill
out
their
manifest
file
and
you
get
an
icon
and
you
get
a
description
and
so
on.
B
B
F
Hello,
just
one
quick
comment:
the
best
thing
about
phishing
is
that
I
I
can
have
any
app.
I
can
see
all
my
data.
It
doesn't
matter
where
it
is
host.
It
doesn't
matter
where
it
is
all
your
data
is
really
accessible
across
any
apps.
I
mean
that
that
is
just
really
significant
that
without
any
any
special
effort.