Skip to content

Instantly share code, notes, and snippets.

View paulkernfeld's full-sized avatar

Paul Kernfeld paulkernfeld

152 followers · 114 following
View GitHub Profile
@paulkernfeld
paulkernfeld / exandria.md
Last active September 5, 2016 19:29
Exandria: A decentralized public file library

Exandria: A decentralized public file library

There are many great file repositories online: WikiLeaks and The Internet Archive are two prominent examples. Even these two notable sites are centralized, however. This means that censorship-happy governments can and do find ways to attack these sites by going after their founders, servers, or DNS records.

This article describes Exandria, a design for a file library with decentralized ownership. Any owner can vote to add or remove content, making Exandria extremely difficult to censor.

Properties:

  • Searching: users can search filenames
  • Downloading: the ability to download files
@paulkernfeld
paulkernfeld / modular-dynamic-hypercore.md
Created March 3, 2016 14:24
Modular dynamic Hypercore feeds

Modular Dynamic Hypercore Feeds

Purpose: Create distributed single-writer append-only logs with hypercore while keeping the hypercore protocol simple.

Design

The core of this design is that hypercore itself would remain mostly the same, and that most of the logic to support dynamic feeds would stay out of the hypercore protocol. This relies on a separate module that can securely replicate a small mutable value (a "signed value feed").

Every time data is appended to a hypercore feed, the ID of the feed will change. This ID is the hash of all the feed's Merkle tree roots. The feed's owner will then broadcast the new ID over a signed value feed. When a reader receives a new feed ID distributed over the signed value feed, it can use this ID to discover a swarm for the feed, connect to that swarm, and download the content in the normal way.

@paulkernfeld
paulkernfeld / burn-name.md
Last active March 31, 2018 10:04
BurnName is a proposal for a simple and practical decentralized name registration system. Feedback wanted!

BurnName: simple decentralized username registration

BTW, this is implemented as burn-name and burn-name-writer.

BurnName is a proposal for a simple and practical decentralized name registration system. In BurnName, users burn bitcoins to bid for names. The user who bids the most for a name owns that name, after a delay. BurnName uses the existing Bitcoin blockchain and network, and it can be used by various applications.

Example applications

  • GitTorrent or a similar "decentralized GitHub"
  • Domain name registration: your username doubles as a domain name
  • Human-memorable Bitcoin addresses: map from your username to your Bitcoin address
@paulkernfeld
paulkernfeld / burndns.md
Last active November 28, 2016 12:41
I'm looking for feedback on BurnDNS, a proposal for an efficient decentralized DNS system based on burning bitcoins.

BurnDNS

BurnDNS is a proposal for an efficient decentralized DNS system based on burning bitcoins. It emphasizes ease of implementation and the ability work with SPV clients.

In BurnDNS, anyone can register a new DNS entry by burning (i.e. destroying) bitcoins. Each time you burn bitcoins, you include a mapping from domain name to address. It's possible for one domain name to map to multiple addresses; in this cases, the addresses should be tried in order of the amount of bitcoins burned.

BurnDNS is simple because it uses only the Bitcoin blockchain; there is no other network required for BurnDNS to function. BurnDNS software can be implemented on top of existing Bitcoin libraries.

It's practical because it can be used with simplified payment verification (SPV) clients. This means that a BurnDNS client only ever downloads block headers and relevant transactions. This uses over 10,000 times less bandwidth than downloading the whole blockchain.

@paulkernfeld
paulkernfeld / signaling-over-webrtc.md
Last active January 29, 2016 15:29
Exchanging signaling info over WebRTC

Original description:

Basically it would work like a PEX message in BitTorrent except it would work with the 2 way handshake WebRTC requires.

Considering something like this

  1. Peer A and B are connected to each other
  2. Peer A in addition know about peer C
  3. Peer A sends an extension message to B saying he knows about C
  4. Peer B replies with signalling data which A forwards to C.
@paulkernfeld
paulkernfeld / dat-get-irc.txt
Created January 10, 2016 21:09
Trying to get IRC logs with `dat`
paul ~/repos/hyperdrive dynamic $ node example.js 196d0fbc76ffc4e92dcfe506f1a3342df93be05632050ff3a09a12d55f26c329
Connecting to 192.168.0.5:60289
Received new connection
Connecting to 208.167.254.222:60289
Connecting to 208.167.254.222:60289
Connecting to 208.167.254.222:60289
Connecting to 208.167.254.222:61264
Connecting to 208.167.254.222:60289
Connecting to 208.167.254.222:60289
Connecting to 208.167.254.222:60289
@paulkernfeld
paulkernfeld / vespucci.md
Last active May 17, 2016 18:48
Vespucci is a proposed protocol that uses the Bitcoin blockchain for decentralized application discovery.

Vespucci

Vespucci is a proposed protocol that uses the Bitcoin blockchain for decentralized application discovery.

Although there have been other proposals on this topic, Vespucci is to my knowledge the first one that does not require the entire blockchain to be downloaded. This results in a massive performance improvement.

The Problem

In order for an application to join a P2P network, the application must somehow find the IP address of one or more peers to connect to. This is called bootstrapping, and it can be difficult. BitTorrent and Bitcoin clients typically include hard-coded addresses of bootstrapping nodes, long-lived server nodes. This works well for established P2P networks with multiple bootstrap nodes like Bitcoin and BitTorrent. It doesn't work well for new and/or small P2P networks, because a small network might only have a single bootstrap node, creating a single point of failure.