Please Sign the Philly Mesh GPG Key!

Now that we have erected an SKS keyserver, I invite everyone to sign the Philly Mesh GPG key to help verify our identity. There are many GPG/PGP applications out there, but below I will provide steps for the gpg utility available on many POSIX systems (Linux, Darwin, etc.). Ideally, with enough signatures, the Philly Mesh key has a higher probability of entering the Web of Trust strong set, the largest collection of strongly-connected gpg keys.

Receive the Philly Mesh Key

Before you can sign the Philly Mesh key, you will need to download it to your system via a keyserver. Here is an example using the SKS server pool:

$ gpg --keyserver --recv-keys 0x8f5b291d3a3ca65a
gpg: requesting key 3A3CA65A from hkp server
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

Now, you should be able to list the Philly Mesh key in your public keyring. Make sure that the key has not been revoked and is not expired:

$ gpg --list-keys 0x8f5b291d3a3ca65a
pub   4096R/3A3CA65A 2017-11-25 [expires: 2027-11-23]
uid                  Philly Mesh <>
uid                  Philly Mesh <>
uid                  Mike Dank <>
sub   4096R/1744B74A 2017-11-25 [expires: 2027-11-23]

Bootstrapping Trust

Before you sign the Philly Mesh key, you want to make sure that it is actually owned by Philly Mesh. For some people, this is as easy as asking me online somewhere or in person. For others, you might want to check the verifications for Philly Mesh on Keybase which shows that this key has been verified by the domain. For those who want some instant verification that this key is associated with the domain, you can query against a DNS record on the domain which holds the key’s fingerprint.

First, let’s see the fingerprint for the key you have just received:

$ gpg --fingerprint 0x8f5b291d3a3ca65a
pub   4096R/3A3CA65A 2017-11-25 [expires: 2027-11-23]
      Key fingerprint = C58B 0431 C815 F315 7310  0959 8F5B 291D 3A3C A65A
uid                  Philly Mesh <>
uid                  Philly Mesh <>
uid                  Mike Dank <>
sub   4096R/1744B74A 2017-11-25 [expires: 2027-11-23]

Now, let’s query against, which pulls a live TXT record set up on the domain housing the trusted fingerprint:

$ dig +short -t txt
"C58B 0431 C815 F315 7310  0959 8F5B 291D 3A3C A65A"

The fingerprint from the gpg --fingerprint command should match the result from the dig command. If it doesn’t match, don’t trust the key. Someone may be in control of the domain and try to get you to trust their false key.

Sign the Key

Now, you are ready to sign the Philly Mesh key. At this point, we assume that you have already created a key of your own. While receiving the key in the initial section above, we also assume you have made sure the key has not expired or been revoked.

Sign the Philly Mesh key with your own key, following the prompts as they come up. At the time of this writing there are 3 uids (email addresses) associated with this key (listed below in the command output). They can each safely be signed:

$ gpg --sign-key 0x8f5b291d3a3ca65a
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2027-11-23
pub  4096R/3A3CA65A  created: 2017-11-25  expires: 2027-11-23  usage: SC
                     trust: ultimate      validity: ultimate
sub  4096R/1744B74A  created: 2017-11-25  expires: 2027-11-23  usage: E
[ultimate] (1). Philly Mesh <>
[ultimate] (2)  Philly Mesh <>
[ultimate] (3)  Mike Dank <>

Really sign all user IDs? (y/N) y

After signing, send the key back to the keyserver so the signature is recorded:

$ gpg --keyserver --send-key 0x8f5b291d3a3ca65a
gpg: sending key 3A3CA65A to hkp server

That’s all it takes! Your signature will now be recorded and the record will update across all keyservers in the SKS pool. You can check that your signature has been recorded here (it might take a few minutes to populate).

The Philly Mesh key has been signed by 0x1619ae4d7cf2a8f7.


Torrent Tracker Now Online

I’ve gone ahead and set up a BitTorrent tracker that only faces the Hyperboria network. This tracker runs the opensource OpenTracker software written by Dirk Engling, compiled with IPv6 support. It is available via either udp or tcp (udp preferred, as it is less resource intensive):


You can add this tracker to any torrent you create to distribute over the Hyperboria network. No peers outside of Hyperboria will be able to contact this tracker or send/receive any torrent data.


Philly Mesh OpenPGP SKS Keyserver Now Online

Hey all,

After a trial run of setting up a keyserver over the summer, I am now making the Philly Mesh OpenPGP Keyserver public for all to use.

The keyserver currently runs SKS, and is ideal for uploading or downloading gpg/pgp keys. A great feature of SKS is that it has what are known as “gossip peers.” Gossip peers help with the transmission of keys uploaded on each node by sending them to all other nodes they gossip with. This creates a web that allows all nodes to communicate and transfer keys through one another. Ultimately, if a key is uploaded to one node, it will end up on all of the others in the network.

The Philly Mesh keyserver, available at, is now part of several official server pools run by If you currently use the gpg utiliy, you may already be accessing it!

Of course, you can always use specifically instead of via a server pool. The server has unencrypted HKP available on ports 80 and 11371, and encrypted HKPS available on ports 443 and 11372.

Additionally, this keyserver is available with HKP access over Hyperboria at the address, and over the Tor network at the address phillygoh7mkcb44.onion. HKPS is not necessary over these networks as they are already end-to-end encrypted.

Here are some examples of how to access the keyserver:

# Clearnet access over HKP (IPv4/IPv6)
$  gpg --keyserver --recv-keys 3A3CA65A

# Clearnet access over encrypted HKPS (IPv4/IPv6)
# Note, you may need gnupg-curl, not just gnupg
# Do: sudo apt-get install gnupg-curl
$  gpg --keyserver 'hkps://' --recv-keys 3A3CA65A

# Hyperboria access over HKP
$  gpg --keyserver --recv-keys 3A3CA65A

# Tor access over HKP
$  gpg --keyserver phillygoh7mkcb44.onion --recv-keys 3A3CA65A

Installing Yggdrasil – A Toy Implementation of an Encrypted IPv6 Network

At Philly Mesh, we like to play around with pieces of technology that aren’t directly related to our core software stack. One such piece of software is Yggdrasil, an encrypted IPv6 networking implementation developed by Arceliar. Yggdrasil borrows many ideas from cjdns, but was primarily written to test a new routing scheme developed by Arceliar. While it is not production-ready software, Yggdrasil is an interesting foray into encrypted networking and fun to experiment with.

For this installation guide, we assume a Debian Stretch (or similar) Linux system with a non-root, sudo user.

First, we need to make sure we have a recent version of go. We can check our version using the following command:

$ go --version
go version go1.9.2 linux/amd64

Yggdrasil is built with Go 1.9. At the time of writing, Debian Stretch only comes with Go 1.3. If you need to install a more recent version of Go, you can do so manually. Below is an example installing Go 1.9.2 for the amd64 architecture using a download link from

$ sudo apt-get remove golang
$ cd /usr/local
$ sudo wget
$ sudo tar -xzf go1.9.2.linux-amd64.tar.gz
$ sudo ln -s /usr/local/go/bin/go /usr/local/bin/go

Now we will set up some environment variables to use Go:

$ mkdir ~/go
$ export GOROOT=/usr/local/go

Now we are ready to install Yggdrasil:

$ cd ~
$ git clone
$ cd yggdrasil-go/
$ ./build

If all goes well, Yggdrasil will have built successfully with no errors. Now we are ready to generate a config file:

$ ./yggdrasil --genconf > conf.json

The config file is pretty basic and allows for some customization:

$ cat conf.json
  "Listen": "[::]:0",
  "Peers": [],
  "BoxPub": "46d18cbcfa0d510fcd226f323efe279525c50eb15db925d4879ee675b99b0724",
  "BoxPriv": "727213ecb3caf601ee49596fa77469674bed177f10d8607ee76ec1f35e942310",
  "SigPub": "08565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
  "SigPriv": "4173f91e08ab2b6f7c5ae96cf9d61f7ac30b36be7a5eff298e00e0d08f6f5c9608565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
  "Multicast": true

If you want Yggdrasil to listen on a static port, you can change the Listen attribute to use an IP and/or port of your choosing like "". You can add entries to the Peers attribute by listing them as strings (IP:PORT) in the array (comma-separated). The Multicast attribute is currently set to true</code, but you could set this to false if you didn't want to auto-peer for some reason.

Here is a sample config that listens on port 1234 on all interfaces and connects to a peer at

cat conf.json
  "Listen": "[::]:1234",
  "Peers": [""],
  "BoxPub": "46d18cbcfa0d510fcd226f323efe279525c50eb15db925d4879ee675b99b0724",
  "BoxPriv": "727213ecb3caf601ee49596fa77469674bed177f10d8607ee76ec1f35e942310",
  "SigPub": "08565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
  "SigPriv": "4173f91e08ab2b6f7c5ae96cf9d61f7ac30b36be7a5eff298e00e0d08f6f5c9608565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
  "Multicast": true

Now, we can start Yggdrasil in the background:

sudo ./yggdrasil --useconf < conf.json &

You should now have a tun interface up for your Yggdrasil node:

$ ip a 
43: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet6 fd00:4645:d147:7c16:98f2:20ea:d0ba:7174/8 scope global
       valid_lft forever preferred_lft forever

Now, you can ping other Yggdrasil nodes on the network:

$ ping6 -c4 fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e
PING fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e(fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e) 56 data bytes
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=1 ttl=64 time=14.4 ms
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=2 ttl=64 time=12.6 ms
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=3 ttl=64 time=15.1 ms
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=4 ttl=64 time=12.9 ms

--- fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 12.673/13.783/15.105/1.017 ms

Further documentation for Yggdrasil is available here, and a whitepaper draft is available here.


GPG and ProtonMail

Philly Mesh now has a public GPG key that you can use for any email correspondence you would like (it is completely optional to use). Using GPG ensures that Philly Mesh will be the only entity that can read any email you send. The 4096-bit GPG key has been uploaded to the MIT Public Key Server, and can be checked here, where you will also be able to see that it was signed by me personally. Additionally, you can also see the key over on Keybase.

Philly Mesh now also has a ProtonMail email address at for any sensitive matters that you do not believe can be discussed through any other email provider. The address for this account is at

In our ever-changing world, you never know who or what may be reading.

For easy access, the GPG key is pasted below!

Version: SKS 1.1.6
Comment: Hostname:


State of the Network Page Now Live

Hey all,

I’ve created a State of the Network page to summarize what we are doing and how we are doing it. I hope that this is a good compliment to the About page as well as the Get Involved page, though there may be some overlap for the time being.

We have received a lot of interest in Philly Mesh this week, and I hope this new page helps provide more information to newcomers.

As always, come chat with us if you have any questions or want to say hi!


OpenNIC DNS Server Now Online

I’ve recently configured a public DNS server in Amsterdam that resolves domains within the OpenNIC root, as well as the traditional ICANN registry. This means you can resolve domains using free OpenNIC TLDs (such as .geek, .null, and .pirate) as well as all of your old favorites (you know, those sites on .com, .net, and all the others).

My DNS server is available on the clearnet via IPv4 (at and IPv6 (at 2a03:b0c0:0:1010::1a7:c001) on port 53. Additionally, you can also access the server via Hyperboria with the address fc16:b44c:2bf9:467:8098:51c6:5849:7b4f, also on port 53.

I have also added DNSCrypt support on port 5353 for all of the addresses above, which allows for authentication between client and server using cryptographic signatures. To connect using DNSCrypt, you will have to install the client and authenticate with the, and the DNSCrypt-KeyB88F:4860:5517:3696:A3D2:BFE0:ECC7:6175:198F:E012:E101:B4FE:869C:1E9C:4C35:E74F.

I perform no logging on the server, so you don’t have to worry about your queries being cached!

Feel free to try it out, or check the health of the server here.


Node Page Now Live

I’ve put together a page on the site to keep track of nodes within the Philly Mesh network. Not all nodes are in, or even around Philadelphia, but they are all managed by the group. Check out the new page, here!

All nodes currently listed minimally display a name, a location, contact information, and a status indicator that is refreshed at every page load. Additionally, all of these nodes are available to peer with, just send a message to the email address listed under the respective node(s)!

Where applicable, each node also lists its hosting provider, along with a referral link if you wish to sign up for any of the hosting services. Nodes may also list both Hyperboria and clearnet services that are publicly available. These can be updated periodically, and announcements will be made for anything new.

Happy meshing!


Matrix, Wekan, & Map Online!

For the past week I’ve been heavily investing time into the Philly Mesh infrastructure by setting up new resources for the group. I’ve spun up a new VPS through Vultr, located in New Jersey, to host some of the more intensive applications. Information for peering with this box will be available shortly, as it is already up and running on the Hyperboria network!

The new VPS hosts three main services for the time being:

First is a Matrix server ( for group communication. All existing addresses and bridges (like IRC) will continue to work and this new server just supplies another federated endpoint to get on the network. Please don’t hesitate to say hi (we also host our own webchat for Matrix ( though Riot is available for many platforms)!

Second, we are hosting a Wekan installation ( This kanban-style application will help organize and keep track of current projects and map out needs for future ones. The Wekan has open registrations at this time, though it may be a bit empty at first!

Third, in collaboration with Toronto Mesh I am working on a new node map ( based off of NYC Mesh’s map source. This is a work in progress and will ultimately have a GitHub repository available for anyone to use for node submission. I am also looking at other meshnet mapping solutions such as NodeShot, but they are proving to be unusable for the time being.

Rough notes for the installations are currently available through our documentation repo on GitHub and will be cleaned up and expanded upon in the future!


Set Your Hyperboria Node’s Domain Name on the fc00 Map

fc00, a project aimed to make the Hyperboria network more accessible, has been hosting a network map of Hyperboria peers for a few years. The map, updated throughout the day, is available to view here. Unlike geographic maps, the fc00 map shows the network topology. While I won’t be able to see if my node in Seattle neighbors any other nodes I’m not connected to, I can see the edges between nodes and view the centrality of the network.

The node map at the time of writing.

The fc00 map also has a handy search feature where you are able to look up nodes based on their IP address or domain name to view cjdns version, connected peers, and centrality. However, domain names are not discovered automatically and need to be added manually via a GitHub repository.

Adding your node’s domain name to the GitHub repo is a relatively simple process, and serves as a good introduction to creating pull requests for any git project. This guide assumes you have a web browser, a GitHub account, a DNS AAAA record pointed to the IPv6 address of your Hyperboria node (subdomains work too!), and a non-root, sudo user on a Linux machine. Commands for a Linux-based workstation will be shown, but should translate easily to a workstation running OSX or BSD.

Forking the Repository

The node list lives in a GitHub repository, Obviously, this is not our own personal repository, so we will first need to fork the repository to our own GitHub account. This will duplicate the repository’s current state so we can perform edits. Navigate to the repository’s page and press the Fork button on the right side of the page, near the top.

Press the fork button.

If prompted for a location to fork the repository to, choose your profile. You will now have a complete copy of the repo within your account. Now, on the right side of the page, press the button labeled Clone or download. In the small popup that appears, copy the URL from the field with ctrl-c to get it on our clipboard.

Press the Clone or download button and copy the URL.

Cloning the Repo

On the Linux machine, let’s do a little housekeeping and install git so we can get to work:

$ sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install git

Now we will clone the repository to our local machine, pasting the link we copied earlier:

$ git clone
]Cloning into 'nodedb'...
remote: Counting objects: 578, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 578 (delta 4), reused 0 (delta 0), pack-reused 568
Receiving objects: 100% (578/578), 163.20 KiB | 91.00 KiB/s, done.
Resolving deltas: 100% (256/256), done.
Checking connectivity... done.

Next, we can change into the directory and start making updates:

$ cd nodedb

We will only be running a script in the repo to automatically add the node to the proper location in the file (sorted by address). We will be running and pass in our node’s IPv6 Hyperboria address and the domain with an AAAA record pointing to it. Note: this domain should be a fully qualified domain name (FQDN). Here is an example with domain which points to fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b:

$ ./ fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b

If we happen to have two or more domain names pointing to the node, we can add them all via one command (though currently on the first in the list is searchable on the fc00 map):

$ ./ fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b ""

The changes are now made, so we can commit them to our local, working copy of the repo with a message describing our changes:

git commit -am "Added famicoman's node0"
[master 125b493] Added famicoman's node0
 1 file changed, 1 insertion(+), 1 deletion(-)

Finally, we will push the changes back to our repo on GitHub:

$ git push origin master
Username for '': Famicoman
Password for '':
Counting objects: 3, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 292 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
   3f94d16..125b493  master -> master

Creating the Pull Request

Back on Github, we can view the changes to our repository by clicking the link labeled Compare on the right side of our fork’s page.

Click the Compare link.

This will show the changes between our fork’s repository and the official repository at zielmicha/nodedb. From here, all we have to do is press the button labeled Create pull request. This will automatically create a request for a change at the official zielmicha/nodedb repository which the author can then approve and merge into the main branch.

Press the button for Create Pull Request.

Making Updates

Later on, we may want to go back and add more nodes to the list or otherwise edit nodes we have already added. We already know the commands to run to get our changes into our fork, but by this time it may be out of date! Luckily we can force an update to our fork from the main zielmicha/nodedb branch so we can perform our edits on the most up-to-date version of the repository.

Back on the Linux machine, simply run the following set of commands:

$ git remote add upstream
$ git fetch upstream
$ git checkout master
$ git reset --hard upstream/master
$ git push origin master --force

Now we are free to add nodes, commit, push changes to our fork,and create a new pull request!


Creating pull requests through GitHub is a simple task, and adding a node to the fc00 map is a perfect introduction to the process. After your pull request gets successfully merged, be sure to check out your node on the map!

My (small) node.