Tesla Coils & Corpses report—filecoin, secure invitations, Ice Backup

Zooko Wilcox-OHearn zooko at leastauthority.com
Fri Sep 5 21:55:30 UTC 2014


.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-
.. -*- indent-tabs-mode: nil -*-

LAFS Tesla Coils & Corpses, 2014-09-05
======================================

in attendance: Zooko (scribe), Daira, Nathan, Brian

We looked at http://filecoin.io/filecoin.pdf . We wondered why
everyone should pay miners to store all files, instead of people who
care about specific files paying miners to store those specific files.

Brian said "I'm kind of excited about filecoin because it seems like
we (the industry) are slowly circling back around to Mojo Nation. And
I'm hopeful that we've learned something in the last 20 years and will
do it better this time..."

Daira asked "Are any of these people referencing Mojo Nation? I don't think so."

Zooko had something on the whiteboard behind him that looked like a
capitalization table. When asked about it, he said it was very
exciting.

We wonder if the Proof-of-Work part of filecoin is there *solely* to
provide a random beacon, in order to prevent miners from "stacking up"
their winning result in the current mining round, plus setting up
future rounds...

We don't understand what reward filecoin miners get for satisfying a
GET transaction.

Zooko says that Andrew Miller says that Bitcoin has a mechanism design
flaw, which is that one miner gets a reward for adding a UTXO, thus
obligating all future miners to store the UTXO if they want their
reward. Eventually, says Nathan, the cost of storing those will rise
to exceed the mining reward.

We want to organize a videocall chat session with all the "distributed
storage" folks: Tahoe-LAFS, Filecoin, Permacoin, StorJ, Ethereum, and
MaidSafe.

We talked about documenting and advocating the Tahoe-LAFS format (the
process of getting from a piece of plaintext to an immutable file read
cap). Zooko believes that the presence of erasure-coding in Tahoe-LAFS
excludes it from a lot of use-cases where people don't need
erasure-coding and don't want the added baggage of it being defined in
the format. Nathan argues that we could offer a simplified version in
which the erasure-coding is still in the format but is "hard-coded" to
k=1, n=1. Nathan suggests that libraries/APIs could be re-used instead
of or in addition to specifications.

What will we talk about at the next Tesla Coils and Corpses? Maybe
"secure invitations", which Brian has been experimenting with in
PetMailV2, and might want to bring back into Tahoe-LAFS. A
user-experience-oriented approach: I'm a user. I have this vague idea
that I want to use Tahoe-LAFS. What does that mean?

The user experience flow would be a lot like the current flow, in
which you get an email that says "Alice wants to share something with
you on blahblah", except instead of Alice introducing you to a
centralized service in order to share something with you, she's
introducing you to a decentralized network.

Brian has an experiment of a more transparent, visible backup process,
named "Ice Backup" in which it shows all the files on your system in a
"sunburst" display, and a dotted line is sweeping around like a clock
hand showing how many files it has already hashed in order to find out
if they have changed and need to be backed up, and another clock hand
is sweeping around showing which ones have been backed up.


-- 
Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.


More information about the tahoe-dev mailing list