Thank you all for coming. My name is John Light, and I'll be producing the Lightning
Talks track today and tomorrow. But each session is going to be hosted by a special guest host.
I want to thank all the hosts for volunteering to do that. It's really an honor to be back
here and co-creating the event with you all. So thank you for being here. In the interest
of kind of keeping things on time and on schedule, just a couple housekeeping items and I'll pass
it off to our first host to introduce the first Lightning Talk speaker. So first I want
to just note that presentations are going to be four minutes long with four minutes
of question and answer. So speakers, please help us keep things on time by sticking within
the four minutes for presentations and audience. If you're going to ask questions, please keep
the questions very brief so that we can end the questions on time at four minutes and
also try to get as many questions in that time as possible. So just keep your questions
short and your answers succinct. And with that, please give a warm welcome and round
of applause to our first host, Stefan Thomas from Coil. Thank you.
Thank you. I'll keep it super short because you're not here for me. My name is Stefan
Thomas. I've been in the blockchain space for about eight years, and I've always been
sort of on the connection point between the web and blockchain. As a JavaScript developer,
I've always wanted to make decentralized technologies more accessible. I created Bitcoin.js, which
was sort of the first Bitcoin implementation in JavaScript. And so I'm very excited to
see how much more activity there is in this particular space nowadays, and in particularly
some of the amazing speakers that we have for this Lightning Talk track today. So without
any further ado, I want to introduce Mikey Williams, who's a core contributor to the Secure
Scuttlebutt project. And if you've heard about it, you've probably noticed that there are
hundreds of different projects in that associated with that technology. And so to give you a
little bit of a tour, here's Mikey. I'm Mikey. I'm sort of the Scuttlebutt librarian
slash archaeologist. And this is going to be a quick fire hose, because it is only four
minutes long. So be aware of something quick. All of what I'm going to show will follow
some core principles, although it is made by many different authors of many different
styles of apps and styles of things that people have made. But here is kind of what binds
everything together. And so the first app is kind of our flagship app, which is Patchwork.
And Patchwork's a standard social network. It's kind of a cross between Twitter and Facebook.
It's what you'd expect. So Joey's going camping. Here's my profile. I have many different names,
many different avatars. It's very subjective. People can assign whatever they want to me.
And here I'm, like, coordinating private messages with Cell. Using a lightning talk, I wanted
to make sure we didn't conflict. We have events. You might have heard of this event. Some people
from Scuttlebutt showed up. We have polls. We have tags. But really Scuttlebutt is more
than just the technical features. It is the community and it is the culture that we're
building. And so here's Matt, the lead developer of Patchwork, releasing his new album on Scuttlebutt.
There's the mycogenist who's releasing how to grow biomaterials. And there's someone
living in Brazil talking about mesh network on Ego Village. There's someone who makes
a weekly summary of what's happening. So in case you miss things, you can catch up on
it. Someone posts every day about the funny pages, their favorite comics. And here's a
conversation almost three years ago that talking about a security centralized browser, might
have heard of it's now called Beaker browser. Every month where we got 200K in funding,
we've now funded over 30 grants. And this happens every month. We have a process to
do internal grant funding. We really care about the community and the community that
we're fostering. So we have that. Okay. Continuing on. Patch Bay, the next app. So similar thing.
Here's the profile of the lead developer. We also have gatherings. We have polls. You
can play chess. You can do book reviews. You can search the images. So all of our mascot
Hermes. You can do database queries and stuff. Continuing on. Codename for the mobile app.
We have posts, as you'd expect. You can see who's connected to you on the network. You
can see all of the raw data. So it's intimately affiliated with the database. Patch Fu, which
is a pure HTTP app. And so it works really well on light clients. Also, so we'll be giving
a talk about this. And he'll be also including we have get SSP and MPM on Scuttlebutt. It's
got a shell, a little task bar to run Scuttlebutt server. Patch Fox. There's also going to talk
by Soap Dog on this, which is Scuttlebutt in Firefox. Patch List. Dominic made minimal
Scuttlebutt interface. Tic Tac. It's focused on specifically blogging. Tailnet, which is
an idea skill sharing interface. Scat, which is a chat interface. NGX, it's made with Angular.
Everyone's kind of just playing around. It's pretty nice. Recipes. So you want to, like,
make things have the interface with each other. MVD. A light client. It's in the browser.
We also have interface or, sorry, clients in Rust. Go, C. And just going really quickly
for the amount of time. Graphs of the network. Because it's all open data. And then guides
that we have if you want to learn more. Zines that people have made. And blog posts of how
to get into it. Thank you.
How does it keep private messages private? So for private messages, you encrypt it with
your key. You actually encrypt a separate key for the private message. Then you encrypt
the key with their key. And so you receive, because everyone gossips messages, you receive
the private message. Because you're replicating everyone's diary. You see that there's this
gobbledygook of a private message. And you're like, you know who it's from because it's
on their feed. But you don't know who it's to. So you're just like, well, if it's to
me, then it's encrypted with my key. So I'll just try to decrypt it. And then if it's actually
for you, then you'll be successful in decrypting it. So we don't leak metadata in that way.
Because it's not like an email where you have all of the headers and then only the content
is encrypted. This, everything's encrypted except for sort of the signature chain parts.
Is there a performance advantage to having the local memory?
So the question is, is there a performance advantage to having local memory? And I'd
say yes. Scudabot's really great because you're on an airplane or you're on your sailboat.
Any sort of off-grid situation, you have all of your messages. And so you can do quick
searching. It's as if, I mean, it's better than how websites work now where you can query
and have the full experience. And then if you just have pockets of internet, you replicate
in those pockets to get more messages.
Patchwork is super fun. I recommend everyone try it. Do you have an estimate of how many
active users Patchwork has?
So the estimate is we have a website that tracks the active users, people who have made
some post or like or some interaction for the day. So we know that we have like 200
daily actives. We haven't done the stats of what that translates into. Like total number
of active users is probably over a thousand. But yeah.
So I actually used SSB a while ago. And one of the things I found that was difficult was
like getting set up on your first pub. Has there been any work on like making it a little
more welcoming to new users?
Yes. So onboarding is like the perennial problem. It's very difficult to make a good onboarding
system and it's something that we've invested a lot into, but it's, we'll never get to
the really amazing thing. And so the current focus for that of onboarding is we will, we
are having a new rewrite of the invite system so that pubs kind of fade away into the distance
and you get invited by a user. And like when you are onboarded, your friends inviting you
and you don't want to be like let into this like room with a bunch of strangers, you want
to find the friend who invited you. So the current thing is always trying to work towards
getting that new person to find the friend who invited them. So you don't kind of get
left hanging. They're like, where am I? This is weird. And then also trying to make pubs
kind of be a part of a user rather than being these kind of misky, oh, I'm running a pub,
but we don't really know what it is. It's like no, pubs are specifically for users and
this user hosts this pub.
Cool. Thank you everyone.
He's here to talk about Perky, which is a more secure way to store, share and sync your
data.
Here, we'll do one. We'll try one more thing. Otherwise, anyway, so I'll start the talk
already. I'm Paul and I'm here to talk to you about Perky. Perky is a personal storage
archiving system. So think of it as like the place to store your stuff for life. So data
under your control, everything else. So anyway, so you may have heard of Perky before. It's
actually previously called Camlostore. So Camlostore actually stands as a really geeky
acronym for content addressable multilayer index storage. So obviously, it's very understandable
by all regular users. And it's actually been around. It's been around a long time. It's
been around for eight years. Everyone can see this okay? All right. Anyway, so okay,
so it's Camlostore. And actually, it's so old that it's even cited in the original
IPFS paper. So as you can see, new solutions inspired by Git are emerging such as Camlostore,
a personal file storage system, and that. So there's actually a long history here.
But that name was kind of like geeky and hard for people to understand. So we rebranded
it to Perky this year. So it's the same awesome software with just better marketing. So the
nice thing about Perky is that it can actually import your data from a lot of different services.
You can actually add your own data if you want. But the nice thing about Perky is that
it's a place to keep all of your stuff from all the other places. And this is a problem.
So I worked on OpenSocial back in 2008. And there was a slide from one of my presentations
back then. It was the sort of confused developer. Anyone notice a problem with this? Well, yeah.
Orkut and Hi5 are no longer with us. I'm sorry to say. Anyway, so that's a problem. So enter
Perky. IndieWeb, anyone here? All right. IndieWeb has this concept called PESOs, publish everywhere,
syndicate your own site. And this is what Perky does for you. So I can post all the
tweets I want, all the photos I want, and it'll get pulled back into my personal archive
and no one can take that away from me. So looking at the sort of the broad picture.
So Perky implements like a bunch of stuff, a web UI, CLI, a bunch of front-end stuff
at the top. There's an API. There's a search layer. There's OpenPGP. There's a schema.
And the big important thing is this sort of blob storage at the bottom here. And this
is sort of that Git relation that we talked a little bit about. So it's a mess, a little
bit of a mess. But the nice thing is it's super extensible. So you can pull this data
in and then you can just share it out to other places. You can encrypt it. You can send it
to local files, but you can also replicate it out to storage out into the cloud. So anyway,
we just did a lot of this stuff.
So the one thing is I wanted to pay homage to IPFS, which was sort of the thing that
came after. So we said, let's do an IPFS blob storage. And everything in Perky is a blob.
So as you can see here, the data comes in, it gets encrypted, and then it gets replicated
out to IPFS. So we learned a few things about this. And this is sort of the master becomes
the student. So to make a blob server and go, you actually have to implement these four
things. You have to enumerate the blobs, you have to stat the blobs, you have to fetch
and receive the blobs. So some of that stuff is pretty easy with IPFS. But what about enumerate?
That's a little tricky because you need to be able to keep a list of all the things that
you've synced. So this is sort of the things we kind of encountered as we did this project.
So Perky and IPFS do come into conflict. They have hashing differences. Perky uses SHA-2-224.
IPFS uses base-58. So there's a lot of differences. So we have to keep a map of that. And doing
that is actually not that easy if you want to do it in a way. But it turns out Perky
is always writing in one direction. So that's pretty easy. We'll just keep track of that
using IPFS link structure. And then data formats. So Perky has a permenodes and claim based attributes
and a whole bunch of things that IPFS doesn't deal well with. So we're just going to store
those bytes. We're not going to use that. So anyway, so very quickly, this is what it
looks like in IPFS. There's some blobs. Look, it's in there. And anyway, so we're just going
to continue this experiment. We're going to release 1.0. We're going to integrate with
something called data transfer protocol. And here is where you can learn more and contribute
to Perky. Thank you.
Any questions?
This is a very common question. So Upspin, for those who don't know, is a similar but
different file storage project started by Rob Pike. Rob Pike also works on the Go team
just like Brad Fitzpatrick, who is sort of the instigator of this. So they're serving
slightly different markets where Upspin is more about a global file system and a unique
namespace. And Perky is more about just shoving blobs around. And it's also like Upspin is
very file oriented. And Perky is very much not file oriented. So the idea is to be able
to store data structures in ways that make sense. So I don't think you'll ever see them
merge. But I mean, they're both written in Go. And those two people both work in the
same building. So they used to, at least. So we might see some of that synergy happen
in the future.
Any more questions? Yes?
How is the performance of IPFS?
Which version? I mean, the version of how this operates on it. It's fairly good. I mean,
we'd like to make some improvements to this integration because right now it stores everything
in a linear list of blobs. If you looked at what IPFS is doing in terms of being able
to use different types of data structures, we could probably use a B-tree-like structure
within IPFS links to make it a little bit better. The other thing is we could also do
something better with performance in that if we have multiple writers, then we have
to use some different techniques. But otherwise, yeah, IPFS is working great these days.
All done? All right, cool. Thank you. And pair to pair.
So the idea is to be able to share recipes with others without depending on a centralized
service.
If we haven't built it yet, we will put something together in the near future. Right now we're
just at the idea collecting stage. We'd love to hear your ideas and your experiences.
My name is Jim and this is my wife, Barbara. We live in Vancouver. I'm a freelance developer.
I work with the Building Things with the DAT Protocol. If you're interested in building
something with that, I'd love to talk to you because I'm a freelancer and I have some availability
coming up next month.
So we were inspired by a Japanese website called Cookpad. It's very popular. It has
almost 3 million recipes and nearly 2 million users pay for the service. And this is a recipe
page on Cookpad. This particular recipe is for a totoro sushi roll. The totoro is a character
from a famous Japanese anime movie you might know. Here are the ingredients you need to
make the recipes and the steps with the photos.
What really makes the site popular in Japan is that it's a very social experience. They
have a feature they call sku-repo. It's not really a good equivalent in English, but sku-ru
means to make or to cook in Japanese and repo is just a shortened version of the English
word report. So it's make report. Let's look at some of the totoro sushi rolls. Some look
like chipmunks. There's a lot of places. People get really creative with when they remake
these recipes. Some aren't really that good.
We like Cookpad a lot, but it's centralized and that's not good. There's thousands of
recipe websites out there, but they come and go over time. People want to keep their recipes
forever. A lot of people just bookmark their recipes, but it's probably because the websites
change or disappear. What about just copying? That gets a little problematic from a legal
perspective. There's lots of apps out there that clip recipes from web pages for personal
use, but is it possible to reshare the things that you clip? Perhaps web archiving is part
of the solution for that. Let's talk about what pair-to-pair is going to be. We want
to build it with speaker browser. There's some features we think we could have. In order
to be social, we need to support profiles. Here's how you create a profile. We're using
the dog as our test user. And the name in there, and the profile is created.
We think we need a page that has many recipes that have been curated by a community. Something
like this. We just grabbed a screenshot, obviously, but the idea is that you can browse many recipes
and save some of them. Each recipe will have its own page. Here's one from Cookpad. In
Japanese, it basically says it's a dog with a hot dog in its mouth. You have a title,
description, photo, ingredients, and all the steps you would need to do. We'll have to
do this in pair-to-pair.
We want to have correct those too. We need to figure out an English name for it.
Here's a bunch of hot dogs. We have a social feed. We're just going to use Britter. We're
going to steal it. That's it. It's going to live here. It doesn't live there yet, but
you can find me at that.
Part of this is going to be a technical exploration using some of the technologies that the speaker
browser team have come up with, particularly Britter. Britter is built on a database called
WebDB, which is interesting. It's like a crawler and a database built together. I'm also working
with the DAT project team on multi-writer features. We want to build the community pages.
I would like to use this as a platform to explore how to do that.
What are some of the unexpected development challenges that you think you'll encounter
developing with this stack?
Having built some things with this, it's going to be onboarding, building something for a
non-technical audience. People are not going to know about peers and how to use cache space.
If you use the speaker browser and you publish something to the internet, since you close
the lid on your laptop, it goes away. People have to be able to put their recipes somewhere
to keep them alive. I think there's going to be interesting ideas around the copyright
and scraping and using web art cuts.
Thank you.
For anyone who's not familiar with Namecoin, it's like DNS, but on a blockchain. It's using
the.bit top-level domain. We're the first project that forged from Bitcoin back in 2011.
Use cases include things like censorship resistance, privacy improvements, and the decentralized
public key infrastructure.
First off, we released NCDNS, which is a tool that integrates Namecoin with the DNS system
in most major OSes. It's an authoritative name server for Namecoin, sports DNSSEC, and
that means it can integrate with things like Unbound and DNSSEC Trigger for system-wide
Namecoin resolution. We even have an automated Windows installer for this. Hopefully, automated
installers for other OSes will be coming very soon.
We also released software for integrating TLS with Namecoin. Among other things, this
works for some definition of works with most Windows apps, including Chrome. Many Linux
apps, including Chrome as well, and Firefox on most OSes. These are very experimental
right now. We're going to rewrite all that code later, but it does work.
Here's a screenshot. This is TLS verification succeeding on a Namecoin website in Chromium.
This is an example of what happens if a malicious certificate authority has signed a certificate.
It gets rejected by Namecoin.
A couple years ago when I was here, I complained about the ridiculous level of witchcraft that
was needed to actually make Namecoin TLS work in standard web browsers, and I asked the
browser vendors, hey, can you help us out with this? The bad news is the level of witchcraft
needed has actually gone up, not down. The good news is we are talking with Mozilla about
adding some APIs that might help with this, so we'll see if that goes anywhere.
We also integrated with Tor, including Tor browser. Here you can see that there's a.bit
domain using Namecoin that is pointing to a Tor onion service.
We also have a lightweight SPV-based name lookup client. It even is integrated into
the Windows installer, and kudos to Ross McCall and Sean Gilligan for some help with that.
We also have a lightweight name wallet based on Electrum, which is currently in development.
This is a screenshot of one of the latest betas of it. You'll notice it actually supports
names. Name support is not fully released, but it's coming soon.
Sadly, Namecoin isn't actually anonymous, but we do plan on fixing that by combining
it with things like Monero and Zcash. We presented a design plan at 34C3, and implementation
is beginning very soon.
We also integrated ncDNS with ZeroNet. Here you'll notice that talk.zeronetwork.bit is
actually pointing to ZeroNet. This works because ncDNS is intercepting the DNS request and
pointing it to ZeroNet.
I made a decentralized search engine for Namecoin websites using the open source project YASI
as a base. Code coming very soon on that.
We also have some initial usage estimates of how much Namecoin is being used in the
real world. I found about 80 Namecoin domains that use IPv4. There's more that use ZeroNet.
Some interesting ones I found. There's a game console modding shop and forum. There's an
intelligence analyst consulting business. There's a Taiwanese language appreciation
site. And there's a site offering news and information about Karen Island, so kind of
diverse.
Kudos to VirusNet for helping with that. And I made a search engine for ZeroNet sites that
uses Namecoin as well. I can show you a live demo of that later if you're curious. Kudos
to A. Wilcox and W. Linux for helping get that working.
I got invited to speak at ICANN. That was kind of cool. Turns out ICANN actually thinks
Namecoin is really cool. We got funding from NLNet Foundation last year. That's awesome.
They also fund cool things like Tor and CubesOS, so it's awesome to be in the company of awesome
projects like that.
Questions? Wow, it only went 15 seconds over. That's good.
When you say you're going to deal with questions of anonymity through Monero and whatever other
options develop in the future, can you talk a little bit more about how that would happen?
So for a full explanation, it would take quite a while, but there's actually a talk I gave
at 34C3 about that. And you can find the video at media.ccc.de. But the upshot is basically
we're going to use atomic cross-chain swaps so that you can start out with Monero or Zcash,
and that's anonymous, assuming that you trust Monero and Zcash. And then basically you purchase
some Namecoins using Monero and Zcash. Then you buy a name using those Namecoins. And
as long as the Namecoin wallet doesn't do anything to de-anonymize you, then if someone
tries to trace where this name came from, they'll get as far back as the Monero or Zcash
transaction, and then the trail goes cold. Good question. Other questions?
What is the main tools that people use to interact with Namecoin today?
The what tools?
The main tools. Like if someone just wanted to get started.
Yeah. So if you go to Namecoin.org and you click on the download link, which is near
the top of the page, honestly at this point, I would probably recommend going to the bottom
of that page and clicking beta downloads. NCDNS, which is the tool that integrates.bit
support with the operating system, that's under the beta downloads page. We're probably
going to move that to the main downloads page soon, because honestly it's more stable at
this point than the things that it replaces. But yeah, installing NCDNS is very, very easy
if you're on Windows. If you're on Linux or Mac OS, it's a little bit harder, but it's
not too hard, and you're always welcome to contact us on the matrix or IRC, and we'll
help you set it up.
Quick follow up. What is the SPV or light client situation with Namecoin today?
Yeah. So for doing name lookups, so if you want to view.bit websites, it's relatively
stable. The software for that is called Consensus J Namecoin. It's based on Bitcoin J. It's
similar to what the Android wallets for Bitcoin use. It's very stable. The only issue with
it is that it uses some patches against Sean Gilligan's Consensus J that aren't yet upstreamed,
which means basically it's a little harder for us to merge security updates and stuff
like that. We are working on getting that upstream. We made a lot of progress in the
past just a few months. For doing SPV wallet stuff, like for registering names or for currency
transactions, we have an Electrum port that is in progress. It already works for currency
transactions, including merged mining verification. Name support is about halfway implemented
there. There's going to be some work left to get that fully working, but it's actually
going really smoothly. And by the way, on that note, kudos to NLNet Foundation for funding
that work. The reason Electrum NMC is happening is because NLNet is funding that. So if you
ever see someone from NLNet Foundation, tell them you are awesome. Thank you.
My name is Ed Silverton. I work on a project called the Universal Viewer. So the Universal
Viewer is a IIIF viewer. It stands for International Image Interoperability Framework. I've been
working on this project for the last five years. It's an open source tool. And IIIF
is a web standard that aims to address the challenge of de-siloing content so that it
can be recombined and annotated. And it's used by hundreds of glam institutions around
the world. It's a very community-driven project. So why am I interested in peer-to-peer? Multiple
people and organizations can care about and identify with peer-to-peer technology as opposed
to single people or organizations. It empowers individuals to self-publish. So Beaker Browser
particularly has got really good tools for that. The picture here shows a kind of a manuscript
on the left with an illumination on the right. And the server in the middle there is failing
to serve that illumination. So it's finding it elsewhere and combining it in a IIIF manifest
and people are viewing it. And they're happy because they can see the content.
So why would you want to combine IIIF and peer-to-peer technologies? Just so everyone
has the power to publish interoperable content as opposed to just large organizations, large
libraries and museums. And it's kind of exciting possibility because IIIF now supports different
types of media other than images. So we're working on AV support at the moment, but I
also have a IIIF 3D community group for creating interoperable 3D scenes. And the prospect of
everyone being able to self-publish interoperable content and remix it any way they can think
of is quite exciting.
So I've done a few experiments to try to combine these technologies. So this is the first one
here. This is some image tiles being loaded over IIIFs. So you can see in the network
inspector there, that's coming by the IIIFs.io gateway. And I have an online guide. There's
a link at the end showing how to do these things. That was fairly straightforward to
do with IIIFs. Just generate the static image tiles and add them to IIIFs.
Second experiment. So this is the second experiment I did. I worked with Drew Winchett at Stanford
University Library and Pedro Tejera at Critical Labs. And this is another vehicle Mirador.
And we're creating annotations in there. And we're using a CRDT to sync Mirador with the
Universal Viewer. And when you create the annotations, the annotations are completely
decentralized. So you create them in one tool. The other viewer is listening on the same
network. And they appear in real time. And there's no central server.
So the final one is I experimented with creating an entire sort of application in that. So
I'm generating all of the IIIF manifest and content and storing the viewer itself in that.
And very finally, I've been working on an Electron app. So this allows you to drag and
drop some files into Electron and hit the button. And then it publishes it as a.archive.
And then there's an HTTP gateway, which links the viewer to.archive. And you can just drag
and drop your generated content into the viewer.
That's it.
No one else does? I'm curious as to what led you to kind of bring these tools together.
Was there a specific need that arose for you that brought you to kind of fuse this?
I think I was just interested and excited. I was at the last summit a couple of years
ago. And I think that kind of spurred me on to investigate and experiment with these technologies.
I just saw the potential for self-publishing. I kind of just want to make it so that anyone
can do this stuff. And you don't have to invest a lot of money and time and all of that. And
that, particularly, I've found is a really good fit with IIIF. It works straight away.
I had to do very little. But IPFS is going to get IPNS in JS and IPFS. So the two will
kind of be comparable in terms of what I can do with it. So IIIF needs mutability. It's
a core thing to it. So once I've got that in IPFS, I should be able to switch between
the two platforms.
Can you compare DAT and IIIFS?
No, probably not. I'm kind of just dabbling with these things. I don't consider myself
a deep expert. But DAT is kind of no JS, built in no JS. And IPFS can go. It has a go daemon.
And you have to kind of interface with that. Although there is now a JavaScript version,
but you can't do kind of mutability with it right now. But that's coming very soon, I
hear. So that's going to be interesting. So I think DAT and IPFS, especially JS, I guess
will have a lot of overlap. Similar use cases like mine will work in either. Which is quite
exciting. Maybe they can be standardized. Who knows?
We'll quickly dive into what ICN is about, talk about name functions, that my pet topic,
and also quickly talk about the intersection with the community we have here. And that
is what I saw when talking yesterday to people with the different projects, that we are really
currently two different communities and we really need to start talking about. I will
try to help you create that bridge.
So what is ICN about? It's information-centric networking as a next generation kind of internet.
We have still a lot of legacy. Next year we will have 50 years of the first request for
comments that is the foundation of all internet standards. 50 years and we have to move on.
And one of the really pains is that IP address problem, the locator identifier confusion.
With ICN the data is at the center. You give a name to a piece of data and the network
will make sure that it arrives to you. You have a fetch primitive, you put in the name
and you get the content. You can use that for single blobs, files. That is the basic
mechanism. It's all that. That is the new waste of the new internet, information-centric
networking.
Think also about what has changed. We are not talking about only about content delivery
networks. We are talking about reverse content delivery networks, sensors, IoT devices, sending
a massive amount of data into the cloud. I heard numbers about one terabyte per hour
for autonomous driving cars. This is the amount of data that has to go somewhere.
So at the first Decentralized Web Summit Van Jacobsen gave a talk. He was at the panel.
You might know the name. He invented congestion control for TCP which saved the internet from
collapsing in the 80s. I was in a sabbatical with him when he has excerpt part. Now he
is at Google. But in the field now things have moved on. Cisco has started concerted
effort at the Paris lab. UCLA is driving a lot the named data networking project. Huawei
is jumping on. So a lot of people are going for that. And there is recently also a research
project that started from Intel and NSF, a joint research project, looking at 5G where
exactly content distribution is one of the main elements.
So there is something coming here. Now named data is one thing. You can name the thing
and the network will deliver it to you wherever it is. Maybe you have the thing on your laptop
so we get it from there or we have to go into some cloud infrastructure. That will be the
task of the network. Now what we also need is you are not only interested in data. You
want to have results. Think about you have a movie but you want it to transcode in a
different resolution. Or you have a huge database about temperature somewhere. You want to filter
it for some time interval, some averaging. If it is a terabyte database you will not
download it locally to you. You want to move the function and let the network find out
what is the best place to execute that query. So the network understands what you want to
do with the data. You can name the data. You can name the function and you compose the things.
And what happened, like in the database community, that was a really important step when they
realized we need a query planning inside the database that make SQL and all that stuff
working. And this is what named function is about. You delegate to the network the possibility
to dissect the query and execute it in the most optimal way. It is obvious where that
leads. It is a seamless cloud abstraction interface that you get. It is at the network
level. You don't have to mess around with IP configuration stuff. It comes out of the
box that you can express these function calls and the references to the data. So that is
where the networking guide would continue and be of course dive into details. There
is now something that we start building on top of that and that is where the networking
community starts to exactly hit this community here when it comes to data structures running
over such an information centric network. And just a paper got accepted from mine that
I will present at the Boston Conference where we look exactly at the distribution of content
using these block storage and using CRDT all the things we hear at this community. So please
reach out for me if you are interested in information centric networking, named functions.
If you also want to talk with me about security, have some interest in private information
updates, a mobile code execution on malicious hosts, things like that. So thank you and
hopefully you join the ICM conference that is in Boston in September.
This is one of the starting points of named data. You don't tie the security to the channel
where the data is flowing through but to the data itself. So the chunks are signed, certificates
are just other pieces of chunks also signed. So it's from the basis on it's built in security
aware networking. So we don't rely exactly on that fragile TLS whatever infrastructure
that we rely right now on.
Man in the middle attack vectors throughout the network because the addresses aren't empowered
to change the data.
You can't change the data. You give the name, you can't cryptographically verify. This was
really what was signed by the producer of the data. You can also link the trust that
you build, that you get from the data to this name schema. There is schematized trust approaches.
So a lot of tools that you can put on top of just the network delivering you that verified
data to you. So there is a rich discussion about access control implemented exactly with
that technology without any tricks of TLS or whatever reachability whatever.
One last question. Compared to SOLID, the framework to connect applications and capabilities,
how does information centric networking compare to SOLID?
That's the one thing I have to discover from that community. Really I'm coming from the
networking now looking into that space. But we link the blocks by using exactly the name.
The name is the name of the game itself. And I will have to discover exactly how SOLID
does the game.
Thank you.
Have you talked with anybody at Ethereum or other large sort of platforms about how this
might work with those projects?
There have been some contributions that try to link the two domains. But from a transport
or network point of level, we really don't care too much about what is carried over it.
So there were some works exactly on securing the naming system where blockchain technology
make use. We need some lookup services and that's where I see an entry point. But not
for the basic delivery of the bits.
So Brewster talked a little bit about reader privacy. And one of the interesting things
I'm asking a lot of different peer-to-peer and other technologies like that is how do
you preserve reader privacy, especially when you can have side channel attacks against
for certain types of data. There are more observers within the system. How does name
data networking help preserve reader privacy?
Well, honestly, by itself it doesn't help. You will still have to develop these techniques.
Unfortunately, the names are leaking a lot of information. And currently the philosophy
was that you make names explicit. You have your internal data structures. You show the
names of how you structure your applications. That has to go away. So people have worked
on encrypted names. Also a private information retrieval using ICN. These are things that
are possible. But it is more a problem that ICN has no magic solution to that.
Okay. Thank you.
This slide, if it comes up, is the first article that I wrote about Bitcoin. There we go. I
just realized today it was on April Fool's Day of 2013. And right from that point I became
aware that the great thing about blockchain technology was its ability to create permanent
archives. And in my business, keeping hold of the truth and making sure that it's preserved
for the future is paramount importance. It took all this time, many years of talking
with different kinds of people before the right project came up where I could instantiate
this interest that I've long had. And last summer I hooked up with these guys at Civil.
I don't know if you've heard of it, but it is an Ethereum-based, it's going to be an
ERC-20 utility token that's going to be launched pretty soon. And they built a publishing platform
that I published a magazine on. And we are going to create a crypto economy on that magazine.
It's very exciting. A lot of the smart contract work is just being done now, but it's been
in development for like the full eight months. And so all this stuff is just on the point
of launching and it's really exciting. As far as like, one thing that I want to talk
about with people here is the regulatory environment for utility tokens and consumer tokens. Because
I've been through this thing and I'd like to swap notes with people, you know, like
all the different sort of regulatory concerns that there have been to prove to the public,
to regulatory agencies and everybody else that we mean what we say when we want to decentralize
these networks, not to make money, but to improve how this business can be done and
to create new ways of doing business that are not possible to do other than with blockchain
technology. So the actual token will be launched on that kind of trip. The token is going to
be launched through Token Foundry. It's not going to be in one of the big crypto exchanges.
You know what I mean? Or any of them. It won't just be like sort of let out into the wild.
It's going to be a limited thing where you have to take a quiz, you know, to be allowed
to participate, almost kind of like the old fashioned securities thing that would have
like only qualified investors, you know, like we're keeping this thing in the family of
people who are interested in using it and in helping us develop the crypto economy for
journalism. I can answer more questions about that later for anybody who's interested. But
basically here is this is Popula. We launched on the 10th of July. And it's been really
fun and successful and so far as like we've gotten a lot of readership and a lot of interest
not only from people in the crypto community, but from people in journalism, which is where
I come from. So I urge you to come check it out and ask any questions that you may have.
The sort of big piece that we had so far you might like to see. This was like a crazy thing.
I was I asked Anthony Bourdain who's interested in a lot of these things to talk with me and
he did in February and I gave him I mean, he invited me to talk with him and we spent
a couple of three hours together talking about all kinds of stuff like this. So I urge you
to check out that interview. It's fun. Thank you very much.
The civil platform that attracted you to it and like why do you what were you waiting
for? Like what does it solve that wasn't solved before?
Well, that's a really good question. The main thing was that they had made deals with journalists.
It was journalists who brought the project to me, Josh Benson, who was the founder of
Capital New York that was later acquired by Politico came and told me that they were going
to do this. And I'm like, before he was then talking, I'm like, let me tell you exactly
what we're going to do about the distributed publishing platform. Because I've been studying
it for a really long time. So that was one thing. The other thing is they're in partnership
with consensus. It was like, you know, they, their portfolio company basically of consensus
gave them a grant of like an investment of five million. So they had good tech partners
and they were really serious about bringing journalists in to make this thing happen.
So like, you know, we're up and running now. And the first one of the first things that
we're going to do is like, install a micro tipping platform. Like the way the crypto
economy works is really kind of meshes all in together. Like you have to be a member
to like, for example, to give a comment. But your comments can get tips. So it's a lot
like I don't know if you read Who Owns the Future, but it's a lot like Jared Lanier,
Jared Lanier's idea about like, sort of like what brave browser has also done about like
making it so that people who use the internet can benefit materially from that. And like
there's a whole kind of churn, you know, of like people talking and reading and making
the community and participating together that is kind of guaranteed by the token.
Any like there are a couple of strengths I can see with decentralized protocols for journalism.
Is there any of them that jump out most to you out of like being censorship resistant,
being accessible to everyone, being verifiable? Like what drives your kind of commitment to
this?
Like I first interviewed Brewster actually for that same column, like, I don't know,
a few years back about, he was one of the only people at the time who could talk about
having received a national security letter. He's been a hero of mine, like as long as
I've known there was such a thing as Brewster. So archiving is a huge, huge thing for me.
And one of the main things that we're doing is like republishing like for Matamasa, like
the basic, the thrust of Popula is it's a globalist publication. Like half, we aim for
like half of what we publish to be from outside the U.S., perspectives outside the U.S. I'm
surfacing stuff that's being censored and we are planning to archive, you know, consistently
either through IPFS or, you know, straight through the Ethereum network if we can to
kind of depending. But those are, those are things like archiving is very passionate interest
of mine.
I was unfamiliar with your project before attending the talk, but I was wondering, apparently
one of the problems journalism has now has to do with how is, how is it funded, right?
I'm sorry?
Apparently, in my view, one of the problems journalism faces now is about how is it funded
right?
How is it funded?
Apparently, a lot of the funds that eventually end up going to journalism or to quality journalism
seem to come from advertising.
Yeah, absolutely.
Which is kind of, I think it's kind of a problem. So I want to know if your project has any
alternative views or any possible solutions to that problem.
Well, you know, this is a 100% reader funded publication. There will never be any advertising
on my publication. There are other publications on Civil who are doing other kinds of experiments
there's grants, there's nonprofits, there's all this different stuff. We have right now
a staff of eight and I would like to just keep it that way. There's no owner, there's
no nobody with deep pockets, the thing was funded through a grant from Civil, but like
it's all journalists owned right now and it's going to stay that way. So it's journalists
and readers, all the money for it has to pay only for eight people. So there's nobody getting
rich off this thing and we don't intend for it to be that way ever. It's like a cooperatively
owned journalist project. It doesn't really take that much money to rent. So we need many.
Give us some, that'd be good. Or find us people, that'd be great. Okay. Are we good? Thank
you.
The New York City 20 token on Ethereum that you could bail in and bail out for Bitcoin.
And it's something I'm working on. But you know, as I started getting closer to the deadline
here, I thought, well, one of the problems we have kind of in this community space is
we have a lot of fantastic tech and a lot of passion and drive and we have a lot of
great projects. But for one reason or another, a lot of them don't get either implemented
or taken up or generate that user adoption that we need. So just to sort of step back
a bit, you know, as a community, like what are some of the things we do here? What are
some of our community values? For me anyway, you know, I'm looking for services that have
decentralized control, that are respectful of my privacy, where I have ownership of my
data and how it's given out. I also have ownership of my identity through self-sovereign identity
or something like it. And if we don't have Kennedy or cooperative ownership of a service
that we're using, at least we should have some serious say in how it's run. Because
after all, we're using it. So those are sort of my core principles, sort of when I think
about creating new systems. However, what ends up happening in real life is people will
pay lip service to this. But what ends up really happening is they're super focused
on ease of convenience or ease of use, convenience, low friction, low cognitive load, just give
me something easy to use. And they'll end up picking it and kind of disregarding some
of this. So one of the things that happens is some of the, you know, the existing dominant
companies, the FAANG companies, they're the Facebook, Amazon, Netflix, Google, Alphabet.
They have these large sort of modes that makes it very difficult to compete with them. One
is economic, you know, they have enormous balance sheets and cash value. They have,
you know, thousands of, you know, really high level software engineers and, you know,
terrific human resources throughout organizations. And then most of all, they have the network
effect, which is sort of governed by Metcapsule. The more people that use a service in many
cases, the more useful the service is. And so as you're starting out and you want to
build your own decentralized project, it's a chicken and egg, you know, how do I get
the first user if none of his or her friends are on the system? And then that becomes kind
of difficult to overcome. If we look at the basic theories of tech adoption, and I just
grabbed this right out of Wikipedia, there's a lot of interesting ways that the two-step
is sort of the opinion makers sort of, or the influencers sort of influence the masses.
There's, as you know, the hype cycle as a technology is adopted. I like personally the
lazy user model in which kind of like 7-Eleven are going to go for the convenience factor
and disregard a lot of other things just because they're in a hurry. So looking at this, you
can actually see a lot of, you know, if you take a look at some of the graphs that are
in here, just right off the Wikipedia page, tech adoption, you can kind of see how some
of these things get adopted, why they get adopted, why they don't get adopted. And,
you know, for me, it's like, give me convenience or give me death. I mean, that's what I see
a lot in the commercial sector. And so I think there's a little bit of that going on also
with some of these applications. Just looking at tech adoption historically and some of
the historical battles, you know, I lived through all of these and I remember for various
reasons, many of which are actually explained here. Some of these won out over others, you
know, and I was present for most of these and many of you were as well. And I think
we're kind of in the middle of the last one right now. So there are lessons to be learned
from the history. These cycles repeat themselves. One thing that's kind of critical in these
projects is, and by the way, forgive me. So what I'm going to say on this is kind of controversial,
so you can kind of slide me at the end, but ease of onboarding. There has to be, oh, okay.
I ran out of time already. I should be looking at the time, but ease of use is important.
Boarding is important. Balancing security. Going after the top five languages, et cetera.
And then sneaking those, you can actually sneak those in the end. You can actually sneak
those core principles that we talked about hidden away at the end. And then you can embrace
and extend and co-op other networks in order to overcome and pull hope over the moat. So,
I mean, that's basically the nutshell of the talk. Any questions? Rants? Concerns? Hey,
John?
Are there any projects that you would say are doing this well?
Well, I, you know, the core metric for that is I just look at adoption. You know, in the
past, we loved BitTorrent, and I was sad to see Tron buy it and kind of see, you know,
what's going on with that. I think right now, Mastodon is doing a fairly good job of getting
user adoption, but it's actually pretty easy to do. You would start to look at what's successful.
There are things that are, when I say successful, I don't mean successful. I mean, what are
people using? What's the user growth look like? Those are the ones to take a good hard
look at. Like, what do they do differently from the other projects? And it's not necessarily
the quality of tech.
Well, you say, you speak about ease of adoption, and I think one important thing is what kind
of value is being generated for the user, right? I think, for example, with Bitcoin,
there's a very clear value proposition that centralized alternatives don't have. I mean,
there are lower fees on Bitcoin and outside. Because, of course, this is all very important,
but maybe another way of seeing it is, are there any problems that are actually better
suited for decentralized solutions than for centralized ones? So do you see any other
problem besides Bitcoin that you think has that potential?
Well, sure. I mean, you know, if we follow these values, for example, social networks,
I mean, I'm not a huge fan of what's going on now. I don't want to sort of live in like
Facebook and Instagram land. I'd rather have a decentralized solution, something like Mastodon,
or I think about banking, I'd rather see a whole bunch of small co-ops. You know, basically,
you name it, everything from office productivity software, you know, we have LibreOffice instead
of MS Office. But then again, this is a power plant presentation. Like, what's easier to
use? And so I think in a lot of different areas, we should be like, seeing if we can
find a way to get our values into the ecosystem in such a way that we can generate user adoption,
user growth and have it as, I'd like to see like one of our solutions that has these properties
in mind, be the market leader, you know, be the incumbent, that'd be nice change. So,
you know, we've seen some stuff recently that kind of takes away from that, which is kind
of unfortunate. We've seen it go in the other way. It seems to be becoming more and more
decentralized. And so, we have to figure out how to pull vault over these moats and, you
know, get back to being competitive in the game. All right. Thanks a lot.
Great. So, I'm going to talk a little bit about scaling decentralized collaboration.
Noah has just mentioned, founder of Comacri, where we're doing token community awards.
And a lot of what I'm going to share with you today comes out of trying to build different
kinds of organizations, completely autonomous individuals collaborating. I started a company
that was a holacracy. We did a constitutionally based, you know, LLC where you could modify
the operating agreement, but tried a lot of different experiments. So, I just want to
share some of the principles or ideas about what I think could work, my personal opinion.
But before that, I'm going to kind of give a framework for how we might think about how
decentralized organizations or associations might be considered to scale. So, this guy
is Ronald LeCose in 1937. He wrote a paper called The Nature of the Firm, which is very
short and worth reading. And he asked this question, why and under what conditions should
we expect firms to emerge? So, in a way, we can think of decentralized association or
organization as being the sort of transformation of the firm, the transformation of the way
that people get things done together. So, the way that Coase breaks down the idea of
the firm is he looks at the costs of doing certain things. So, finding collaborators
with an aligned purpose, values and skills, making sense of the current state of things,
you know, learning things, making decisions, bargaining for personal or collective compensation,
and enforcing rules or values. And so, he looks at these costs. Actually, there's like
a few more. But we can look at the same set of costs and ask the question like, you know,
what would cause decentralized associations to be more effective than a centralized organization?
And the takeaway is that a decentralized association will be preferred if the coordination costs
are lower and the individual benefits are higher than a centralized firm. So, the other
kind of thing to think about is we talk a lot about emergent behavior. And it's just
useful to point out that we want to amplify emergent collaboration as opposed to emergent
disasters. And I think people don't necessarily think about this well enough. On the left
is the slime mold. On the right is a hurricane. And so, the other question is how do we get
the combination of factors that lead to effective decentralized collaboration? So, here's three
different sort of technique categories. One, design for collaboration. So, important thing
is you want to have people opt into an existing purpose rather than trying to define the purpose
after you get all the people together. So, if you have an initial statement of values,
an initial direction especially that you're going in, this is super important. It's very
difficult to get a group of people together and then decide on the purpose. And you want
to make sure that that can't be taken over. The other is you want repeat interactions
between people. You don't just want transactions. You want longer term reputation to form. And
you know, obviously people are finding that tokens as a form of ecosystem equity is really
valuable. I would recommend tracking your learning. Figure out the quantity of the – have
a learning log, time to answer. Figure out how reliable your evidence is. And think about
your rate of learning. And finally, you want to also have a measure the velocity of your
decision making. This is really important for designing an organization. How fast can
you make high quality decisions? How quickly can you onboard people into your organizational
system? And can you measure the outcomes of your decisions relative to your purpose that
you had when you formed the organization? The other last thing is make sure that you
are playing the right game. Prisoner's Dilemma is a game that incentivizes betrayal. What
you want is an alternate game called Stag Hunt where you pay off to – there's a payoff
to go hunt bigger game together rather than to go off and do your own thing. So look for
incentives that are designed around that. And you can connect with me on Comacri and
also here are some things that you can explore further. There's a self-organization constitution
that we came up with a while ago. And then there's a few other things that you might
want to check out. Nature of the Firm, Swarmwise, a book called Super Cooperators, Governing
the Commons by Eleanor Ostrom who is a Nobel Prize winner and The Evolution of Trust by
Nicky Case gives you an idea of how game theory works.
How do you – like would you say that the centralized organization is always better
or would you say that there are certain use cases for each and how do you decide?
I guess the way I think about it is to take a step back and see whether or not the purpose
is being achieved, whether you're dropping the cost to achieve the coordination of some
goals. And I think that it's really about – I would say decentralization – it needs
to satisfy that set of criteria and that will cause it to be more successful in many cases.
You mentioned Holacracy and your experience with it. I spent some time at Zappos I guess.
What were your pitfalls? What were the strengths, weaknesses, difficulties you encountered?
How did it go? I'm kind of curious. Not too many cases out there.
People meetings are awesome. Everybody hates governance meetings. It turns out that people
have a hard time thinking about how to restructure their organization and those conversations
are really painful. It's important to find a way to address that. Also what's missing
from Holacracy is it doesn't talk specifically about budgeting which is actually where the
control is and about HR which is about whether or not people will join your organization
that have the same values. Those two things have to be solved. Actually the self-organization
constitution was an open source version of a combination of Holacracy and Sociocracy
to try to simplify it to make onboarding faster and also later versions we try to address
the budget and questions. But I think it's an important piece of figuring out how to
do decentralized collaboration. I feel it's an essential experiment that's been running
for a while that's really valuable to run.
Quick question about the tokens. How do you balance the friction that gets added by having
to worry about tokens? Was this judgment fair and so on with just free flowing collaboration?
At some point you will have to deal with budgeting. Typically when people join an organization
and they have some incentive about the long-term purpose of that organization they'll get stock
in it. The token is the replacement for stock but it's stock in an ecosystem is the way
that I view it from a collaboration perspective. I think it's an essential negotiation that
has to occur for projects to actually be sustainable. It's just unavoidable in my view.
How do you see your work fitting into the platform cooperative movement where you have
multi-stakeholder type things where there's necessarily tension between people on one
side versus the other side and having a hard time making decisions?
I have a lot of good things to say about platform co-ops. I would just say pay attention to
the velocity of decisions. Technology organizations in particular have to make very fast decisions
and there's a penalty for not making those decisions so the decisions just have to be
fast. Likewise actually large hierarchical organizations have an implicit form of consensus
where you have to get approval from lots of folks and they actually fail on their velocity
of decision making as well. I don't think that necessarily cooperatives or decentralized
groups are bad at making quick decisions or any worse than other kinds of organizations
but it's just important to track that as a metric. How fast can we decide things and
what's the quality of the decisions?
Thanks once again to Stefan for hosting this session. We ended just a few minutes behind
schedule which is great considering all the little technical hiccups but thank you all
for your patience throughout the talks. Thank you so much for coming, participating, watching,
asking great questions. We're breaking for lunch now. We'll be back in this room for
more lightning talks at 1.30. Thank you.