Merge commit '1f62015d7f88eb0eb261df2e38bca34def674004' as 'doc'

doc/README.md

@@ -0,0 +1,6 @@
+# Documentation
+*Documenting things related to the meshnet*
+
+We're writing documentation for meshnet related things. Feel free to submit pull requests.
+
+See [index.md](index.md) for current progress. We'd love more languages!

doc/achievements.md

@@ -0,0 +1,71 @@
+It has long been speculated that a file like this would be a great thing for Hyperborian newcomers to have, but no one has ever gotten around to writing it:
+
+...behold!
+
+# Hype Achievements
+
+Apparently people don't do things just because they're a good idea. If keeping track of achievements via some arbitrary points system makes you feel better about following best practices, who am I to argue?
+
+Each achievement will have an associated value. Your score is the sum of these points. See if you can get your score [over 9000](http://knowyourmeme.com/memes/its-over-9000)!
+
+Achievements expire, so if at any given time you don't qualify, you lose those points!
+
+1. Generate a PGP key
+2. Install Git and create a Github account so you can submit Pull Requests and issues.
+3. Build cjdns from source
+4. Successfully peer with somebody.
+5. Run only the latest version of cjdns on all your nodes.
+6. Extra points for every node running the latest crashey branch.
+7. `nmap` yourself and close down any exposed services (unless you intend for other people to use them).
+8. Create a `~/.cjdnsadmin` file for use with the admin api.
+9. Launch and maintain a webserver on Hyperboria.
+10. Provide an RSS feed so others can subscribe for updates.
+11. Help a newb on EFNet.
+12. Read everything in [Project Meshnet's documentation repository](https://github.com/projectmeshnet/documentation).
+13. `watch` the Documentation repository so you hear about updates.
+14. Set up an IRC bouncer and point it at HypeIRC so you don't miss anything. Combinations of command line clients and tmux or screen are considered equivalent.
+15. Contribute to the documentation repository at least once a month.
+16. Participate in [keysigning Tuesday](#).
+17. Make (or contribute to) a meshlocal page for your area.
+18. Have a hype-enabled xmpp account
+19. Configure a persistent link between nodes independent of the internet.
+20. Blag about cjdns or Project Meshnet.
+21. Design some form of rich media for Project Meshnet (graphics, video, animation, audio, presentation slides).
+22. Discover a bug in cjdns, and give it a memorable name.
+23. Host or register a cjdns, Project Meshnet, or Mesh-local mailing list.
+24. Subscribe to any of the above lists.
+25. Learn HTML
+26. Have someone else quote you and commit the results to a HypeIRC bot's factoid system.
+27. Build cjdns on an android phone.
+28. Read all of [xkcd](http://xkcd.com/).
+29. Install at least one Linux distribution other than Ubuntu.
+30. Erase Microsoft windows from every computer you own.
+31. Host your own email server.
+32. Host your own ircd.
+33. _Don't_ run your irc client as root!
+34. Host a show on [HypeRadio](http://radio.cynical.us/hostashow.html).
+35. Cross compile cjdns for another platform.
+36. Contribute to [Hyperboria's news agency](http://news.hyperboria.net/).
+37. Document an undocumented function or component of cjdns.
+38. Implement a function or component of cjdns in an alternate language
+39. Translate an article into another language (and maintain it).
+
+## Penalties
+
+Avoid qualifying for these _achievements_, as they count against your score.
+
+1. Provide peering credentials without including a means of getting in contact.
+2. Provide peering credentials with extra information in the form of line or block comments. (You should be embedding them as JSON attributes instead!)
+3. Provide peering credentials without the IPV6 included. (You can get by with just a password and publicKey, and your IPV6 can always be inferred from your publicKey, but it means more work to figure out who you are).
+
+
+## You may have noticed some patterns...
+
+* **You need to pay attention to your nodes**. A network is an inherently social construction. Out of date, buggy nodes can actually have quite a negative effect on the nodes around them. Update often, and keep track of how different versions perform, we need feedback!
+* **RSS, mailing lists, and other subscription protocols are really valuable**! Improving this software (and the network built on top of it) means gathering feedback. You can't respond to questions unless you are first aware of them.
+* **Source code is always better**. At this point in time, the most authoritative definition of the cjdns protocol is [cjd's github repository](https://github.com/cjdelisle/cjdns). If you are using another source, it is far more likely to be out of date.
+* **Newest is best**. Every now and then there are intentionally breaking changes. This happens when the network is suffering because of old nodes. In such cases, modifications are made which cause up to date nodes to drop old nodes' traffic. If you don't update, you might fall off the map. If you are running a protocol in between the cutoff point and the bleeding edge, you may be the link which allows older nodes to continue participating in the network. Please update so we can all use the latest features to better diagnose bugs.
+* **There is no substitute for understanding**. People build tools that streamline difficult processes, but ultimately you cannot rely on software to fix all of your problems. At some point, bad behaviour has to change, and that means understanding the principles behind security, exercising discipline, and informing those around you when they are putting themselves (and possibly others) at risk.
+* **We cannot rely entirely on the experts**. This is closely related to [Brooks' Law](http://en.wikipedia.org/wiki/Brooks%27s_law). An expert in a subject is in an excellent position to push further, and learn those things which are out of reach of those with less experience in the subject. Unfortunately, this often means they are in the position of having to choose between learning more about the subject in question, and spending their time sharing disseminating their knowledge. It is very important to understand that when people take the time to help you understand a difficult subject, they need you to help share that information with those who know are less experienced than you. In the Hypeborian community, we've taken to referring to this method as [WTFM](http://www.roaming-initiative.com/blog/posts/wtfm).
+
+

doc/bugs/black-hole.md

@@ -0,0 +1,40 @@
+Those familiar with **cjdns** have likely heard others refer to a **black hole routing bug**. This is one of the central problems we have to solve. Thus far, we have had a hard time fixing this issue because we don't fully understand what is causing it.
+
+Firstly, it's quite possible that we are referring to an apparent behaviour which is actually caused by a number of different bugs. For that reason, it may be helpful to use the term to refer to the behaviour, and find other terms to refer to the actual causes, once we understand them.
+
+The bug is so named partially because it is so difficult to diagnose (actual black holes cannot be seen directly), and partially because the end result is that information seems to disappear (black holes absorb light).
+
+The simplest possible network configuration in which the bug can arise is in a **chain** topology. Suppose Alice connects to Bob, and Bob to Charlie. Situations have arisen in which Alice is able to connect to Charlie, and yet unable to communicate directly with Bob. In such a situation, it's obvious that something strange is happening. It becomes less obvious as the network grows.
+
+If you find that you are unable to route to a peer that you believe you should be able to reach, you can help us solve this bug by collecting as much information as possible about your node at the time:
+
+Create a bug report:
+
+```bash
+# what version are you using?
+cd cjdns;
+./cjdroute -v > ~/cjdns-bug-report.txt
+
+# more specifically, which git commit?
+git rev-parse HEAD >> ~/cjdns-bug-report.txt
+
+# let us know your cjdns ipv6 address
+ip a | grep " fc" >> ~/cjdns-bug-report.txt
+```
+
+```bash
+# Dump your routing table to a text file:
+cd contrib/nodejs/tools;
+./dumptable.js >> ~/cjdns-bug-report.txt
+
+# peerStats might be helpful too
+./peerStats.js >> ~/cjdns-bug-report.txt
+```
+
+Add some comments to your bug report telling us about the problem in as much detail as you can think of.
+
+```Bash
+$EDITOR ~/cjdns-bug-report.txt
+```
+
+Post it, or host it, and get on IRC!

doc/bugs/santa.md

@@ -0,0 +1,39 @@
+## The Secret Santa Scenario
+
+This is a possible routing issue that may be related to the **black hole routing bug**. I (ansuz) decided to give it a distinct name because it may be an entirely different problem with the routing behaviour. More distinctive names are more likely to get remembered, and ∴ they are more likely to be _reported_. At least, that was my reasoning.
+
+## The Expectation
+
+**cjdns** distributes a network's routing table across its constituent nodes. Individual nodes decide which other nodes they should keep track of by a combination of two main metrics:
+
++ a **logical** proximity metric (in which nodes which are a small number of hops away are considered close)
++ a **key-wise** proximity metric (in which nodes with similar addresses (by a xor metric) are considered close)
+
+The idea is that nodes should know which peers are logically proximal, for obvious reasons, but they should also track a number of distant peers which are chosen randomly. Rather than using continuous random functions, nodes capitalize on the assumption that private-key generation (upon which each node's ipv6 address is dependent) should be random. As such, we expect ipv6 addresses to be distributed without any predictable correlation to physical proximity.
+
+If a node **A** goes looking for a node **M**, **A** first checks if **M** is a logically proximal peer, then falls back to asking peers with similar keys if they know of a path to **M**. We expect that any node should be able to find any other node in `log(n)` lookups, where `n` is equal to the size of the network.
+
+## The problem
+
+This method of distributing paths among nodes (aka constructing a Distributed Hash Table (**DHT**)), is based upon **[Kademlia](http://en.wikipedia.org/wiki/Kademlia)**. There may be a problem with this (this is the part where I bring Santa into it).
+
+Many of the world's nations have a holiday practice sometimes referred to as a [Secret Santa gift exchange](http://en.wikipedia.org/wiki/Secret_Santa). The premise is that some group of people (often the employees of some organization) each put their name into a receptacle. Once each member has inserted their name, they take turns removing a name (drawing again if they draw their own name). Once every member has received a name, they give gifts to their random recipient. When it goes well, everyone receives a gift.
+
+The assumption is that even if they do not know their chosen recipient well, they have enough common acquaintances that they can learn enough about them to deliver a suitable gift. Furthermore, it should go without saying that they should have the capacity to deliver this gift. The Kademlia method is generally implemented as a dynamic overlay network. Its member are assumed to have a path to one another.
+
+This is not the case with **cjdns**, as it is intended to be used to form a **[pseudonymous](http://en.wikipedia.org/wiki/Pseudonymity)** network. In other words, it is not guaranteed that there already exists a path to the their target node (or gift recipient, to return to the metaphor).
+
+## Relying on chaos
+
+Suppose I need to find a node: I ask my peers, they ask their peers, and so on. Since their is not necessarily a common mode of communication shared between all nodes, there are edge cases in which we will never find the node in question. Despite the assurances that our random distribution **should** be even, it is possible that we are only able to see four hops away, and the nearest node which happens to have a path to the target node is 7 hops away. Nodes which are three hops from us **should** be able to see as far as we are able to (four hops), but in reality the directions in which they are able to see may not be in the right direction. They may be able to see further into one part of the network than another (like a car's blind spot, or in the eye of an individual afflicted with cataracts).
+
+To put this in human terms: 
+
+* Our work is organizing a secret santa gift exchange.
+* We work for a multinational corporation.
+* We receive a name we aren't familiar with.
+* We ask around, nobody knows the individual in question.
+* We ask the human resources department, and they inform us they can't give away that information (it's private).
+* That person never gets a gift.
+* This happens through the company, and lots of people don't get gifts.
+* Bummer.

doc/cjdns/Operator_Guidelines.md

@@ -0,0 +1,46 @@
+# Operator Guidelines
+
+When you become part of the network, you have become an ISP. This gives you certain responsibilities to the rest of the community.
+
+---
+
+### Lock Down Your Box
+
+When you start up cjdns, you become an IPv6 host. Many programs, such as http, ssh, or smtp servers, will automatically bind to this new address. If you do not want these services to be available over your cjdns interface, you should either modify your `ip6tables` rules, or edit the configuration file of the service in question (a simple Google search can help with this for most programs).
+
+To scan your box for running services, first get your cjdns address by running:
+
+`$ ip addr | grep "inet6 fc"`
+
+and then port scan that address with:
+
+`$ nmap -6 <CJDNS ADDRESS>`
+
+---
+
+### Peer Efficiently
+
+Murphy's Law applies to cjdns routing: if a packet can take a weird or inefficient route, it probably will. When you choose bad peers, it degrades the quality of the entire network. When you are peering over the internet, you should be peering with those who are in relative geographical proximity to you.
+
+You should only be peering with people whom you (moderately) trust. Peering with total strangers ruins the friend-of-a-friend nature of the network.
+
+---
+
+### Keep Peering Credentials Safe
+
+On the same lines as peering efficiently, be careful that nobody steals your peering credentials.
+
+The passwords should not be passwords, they should be long strings of gibberish that are practically impossible for an attacker to guess. To generate a strong password, you can run this bash command:
+
+```
+$ cat /dev/urandom | strings | head -n 20 | tr -d '\n"`\ \t{}' | head -c 40 && echo
+
+```
+
+DO NOT transfer peering credentials over any sort of plaintext medium, such as IRC or unencrypted email. It's probably also a good idea to use a service like [EZCrypt](https://ezcrypt.it) (also available [on Hyperboria](http://cjdns.ezcrypt.it)) or send your peering details via encrypted email with PGP.
+
+---
+
+### Get on IRC!
+
+As a service provider, you need to be available in case someone needs you.

doc/cjdns/anatomy.md

@@ -0,0 +1,88 @@
+# Anatomy of a running cjdns
+
+We examine a running cjdns instance using standard UNIX tools.
+
+For the rest of this document, we assume that cjdns has been started with the default config, using the following command:
+
+```
+# cjdroute --genconf > cjdroute.conf
+# cjdroute --nobg < cjdroute.conf
+```
+
+
+## Processes
+
+```
+# ps aux | grep cjd
+root      3020  0.0  0.1  18052  2908 ?        Ss   22:55   0:00 /usr/sbin/cjdroute --nobg
+root      3022  0.0  0.0   9276   948 ?        S    22:55   0:00 /usr/sbin/cjdroute angel client-angel-2mtr2h715xzmlpy97pt9z4x1t6082z
+nobody    3023  1.1  0.2  18672  3856 ?        S    22:55   0:27 /usr/sbin/cjdroute core cq9xvsmb1l95mltplt23jl7n56sbwz
+```
+
+We're seeing three processes.
+
+1. The process we started, which doesn't serve any particular purpose, apart from staying in the foreground, and capturing the other two processes' log output.
+  - The `--nobg` switch is equivalent to setting `"noBackground": 1` in `cjdroute.conf`.
+  - If we omit `--nobg`, we will see a bit of log output from cjdns' starting up. Then the process will exit and cjdns will continue to run in the background.
+2. The Angel process
+  - Child of the process we started
+  - If we omit `--nobg`, it will get re-parented to pid 1 (usually `init`.)
+  - Reponsible for system integration -- bind sockets, create TUN interface, etc.
+3. The Core process
+  - Child of the Angel process
+  - It drops permissions and runs as `nobody`
+  - Responsible for actual routing and switching
+
+Find out more about the Angel/Core split: [Security mechanisms](security.md)
+
+Notes:
+
+- Busybox' `ps` doesn't support the options used above. That means we'll use just `ps | grep cjd` on systems like OpenWrt or Android.
+
+
+## Listening ports
+
+```
+# netstat -ulp | grep cjd
+udp    0   0   localhost:11234     *:*      3023/cjdroute
+udp    0   0   172.17.42.1:60814   *:*      3023/cjdroute
+udp    0   0   *:60814             *:*      3023/cjdroute
+udp6   0   0   [::]:55709          [::]:*   3023/cjdroute
+```
+
+We're seeing a couple of listening UDP ports.
+
+1. [Admin API](admin.md)
+2. UDPInterface on my local docker0 bridge
+3. Default UDPInterface listening on all interfaces
+4. RainflyClient, which is dead code (admin/angel/Core.c:439 ff.)
+
+
+## Network interface and routes
+
+```
+# ifconfig tun0
+tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
+          inet addr:192.168.223.2  P-t-P:192.168.223.2  Mask:255.255.255.255
+          inet6 addr: fc06:c135:28a5:8c0b:dd4e:bcb6:d4d6:c96d/8 Scope:Global
+          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1312  Metric:1
+          RX packets:1449 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:2289 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:500
+          RX bytes:1389870 (1.3 MB)  TX bytes:310214 (310.2 KB)
+
+# netstat -nr
+fc00::/8                                    ::   U    256 5     0 tun0
+fc06:c135:28a5:8c0b:dd4e:bcb6:d4d6:c96d/128 ::   Un   0   2   254 lo
+```
+
+We notice a few things about this TUN interface.
+
+1. The lack of a link encapsulation (e.g. Ethernet) or MAC address (`HWaddr`). The `tun0` interface isn't backed by a physical interfaces, as `eth0` or `wlan0` are. It's backed by a userland process instead (cjdroute).
+2. The `inet` and `P-t-P` addresses, which are assigned by cjdns' tunneling functionality: [IPTunnel](iptunnel.md)
+3. The `RX` and `TX` values, which count the IP traffic received and transmitted by this cjdns node.
+
+The routes look a bit more obscure.
+
+1. All packets for addresses starting with `fc` are handed to cjdns' TUN interface.
+2. TODO: what's the reason for the additional route?

doc/cjdns/changelog.md

@@ -0,0 +1,81 @@
+# Changelog for cjdns
+
+crashey is for development, master is rolling release
+
+A few words about Version.h
+
+Current state: 5fa245c - remove check code (Tue Feb 3 23:25:10 2015 +0100)
+
+## v15 -- January 2015
+
+crashey since: 74e7b71 - Configurator should attempt a ping before beginning to setup the core (might fix startup errors for some people) (Fri Jan 23 23:45:04 2015 +0100)
+
+master since: 97161a5 - shitfuck missed a line (Thu Jan 29 19:25:39 2015 +0100)
+
+- The configurator now tries to ping the core process before starting to configure it.
+  This might fix a possible race condition during cjdroute startup.
+- A bug with ETHInterface auto-peering has been fixed.
+- A segfault in peerStats has been fixed.
+- The `-O` cflag for build-time optimization has been fixed. It can now be set as
+  `-O2` to optimize for performance, or `-Os` to optimize for disk space usage.
+- We now try to remember and use the last known route to a node.
+- Short-form IPv6 addresses are now supported.
+- The tools in `contrib/nodejs/tools/` have moved to `tools/`.
+- The sessionStats tool has been added; ping and traceroute tools can now resolve DNS domains.
+- The search tool has been added, and DHT searches are now available in the
+  Admin API as `SearchRunner_search()`.
+- The ping and search tools now allow a `-c` option for setting the number searches
+  or pings.
+- The Admin API functions `NodeStore_nodeForAddr()` and `NodeStore_getLink()` no
+  longer require authentication.
+
+## v14 -- January 2015
+
+crashey since: 670b047 - Fixed bug in getPeers which caused it to return the same peers every time (Sun Jan 18 17:13:53 2015 +0100)
+
+master since: 601b6cd - Oops, lets bump the version while we're at it (Fri Jan 23 07:47:05 2015 +0100)
+
+- The Hidden Peers bug has been fixed; it manifested in flapping peerings because
+  of dropped pings on the switch layer.
+- A bug in NodeStore_getPeers() has been fixed, which caused it to always return
+  the same peers.
+- `ETHInterface` can now bind to `all` network interfaces, and auto-peer on all
+  of them, being more resistant against interface going down or up during runtime.
+- `ETHInterface` now also brings the respective interfaces up when starting.
+- A crash related to the bit alignment of switch ping error responses has been fixed.
+- The ping and pingAll tools have been improved, pingAll now performs both
+  router and switch pings.
+- `InterfaceController` has been rewritten to allow for easier development of
+  custom interfaces.
+- Documentation for debugging using traffic analysis has been added.
+
+## v13 -- January 2015
+
+crashey since: bb06b63 - Added 2 new command line tools, traceroute and cjdnslog (Thu Jan 1 17:10:39 2015 +0100)
+
+master since: 185fe28 - Nodes trying to ping themselves causing crashes (Fri Jan 2 09:37:32 2015 +0100)
+
+- Nodes running v11 or below are not supported any longer. They can still
+  establish peering to every other node (also v13), but from v13 on, their
+  traffic won't be switched any longer. They also won't make it into v13 nodes'
+  routing tables.
+- The ETHInterface wire protocol now includes the payload length. A few ethernet
+  adapters don't strip the checksum which is appended to the packet by the
+  sender, and thus confuse the decrypter.
+- `NodeStore_getBest()` no longer takes DHT k-buckets into accounts -- the
+  respective code has been commented out. From the code comments:
+
+> The network is small enough that a per-bucket lookup is inefficient
+> Basically, the first bucket is likely to route through an "edge" node
+> In theory, it scales better if the network is large.
+
+- The Admin API function `InterfaceController_peerStats()` now includes the peer's
+  `protocolVersion`, and doesn't require authentication any longer.
+- `cjdroute --genconf` now has an `--eth` switch which enables the ETHInterface
+  and auto-peering.
+- There is now a script which adds peering passwords to both the config file and
+  the running process, avoiding the otherwise neccessary restart:
+  `contrib/bash/peers.sh user user@example.net <user's ipv6>`
+- Minor Fixes for Android
+- It's now possible to cross-compile for ARM, on an OSX host.
+- Documentation, and scripts in `contrib/` have been improved.

doc/cjdns/data_structures/Address.md

@@ -0,0 +1,29 @@
+### Address
+
+- uint32_t protocolVersion;
+  - The protocol version of the node.
+
+- uint32_t padding;
+  - unused
+```javascript
+union {
+    struct {
+        // tricksy: this is effectively a 64 bit rotate of the following bytes array
+        uint32_t three_be;
+        uint32_t four_be;
+        uint32_t one_be;
+        uint32_t two_be;
+    } ints;
+
+    struct {
+        uint64_t two_be;
+        uint64_t one_be;
+    } longs;
+xxxxi  - $diwx
+    uint8_t bytes[Address_SEARCH_TARGET_SIZE];
+} ip6;
+```
+- uint8_t key[Address_KEY_SIZE];
+
+- uint64_t path;  
+TODO: This struct is in dire need of some annotation

doc/cjdns/data_structures/Allocator.md

@@ -0,0 +1,12 @@
+### Allocator
+
+const char* fileName;
+  - The name of the file where this allocator was created.
+
+int lineNum;
+  -The number of the line where this allocator was created.
+
+int isFreeing;
+  - Non-zero if allocator is currently freeing.  
+
+TODO: Copy/Remove allocator documentation and premise to somehwere more appropereate.

doc/cjdns/data_structures/EventBase.md

@@ -0,0 +1,4 @@
+### EventBase
+
+- int unused;
+  - TODO: check to see that this is unused.

doc/cjdns/data_structures/Identity.md

@@ -0,0 +1,40 @@
+### Identity
+
+We don't know how its mistress works maybe we don't want to know
+
+```javascript
+#if defined(Identity_CHECK)
+
+    /** This goes in each structure which will be checked. */
+    #define Identity \
+        unsigned long Identity_verifier;
+
+    #define Identity_set(pointer) \
+        (pointer)->Identity_verifier = Identity_MAGIC
+
+    #define Identity_check(pointer) \
+        (__extension__ ({                                                      \
+            __typeof__(pointer) Identity_ptr = (pointer);                      \
+            Assert_true(Identity_ptr->Identity_verifier == Identity_MAGIC);  \
+            Identity_ptr;                                                      \
+        }))
+
+    #define Identity_ncheck(pointer) \
+        (__extension__ ({                                                                       \
+            __typeof__(pointer) Identity_ptr = (pointer);                                       \
+            Assert_true(!Identity_ptr || Identity_ptr->Identity_verifier == Identity_MAGIC);  \
+            Identity_ptr;                                                                       \
+        }))
+
+#else
+    #define Identity
+    #define Identity_set(pointer)
+
+    #define Identity_check(pointer) \
+        (__extension__ ({                                                      \
+            (pointer);                                                         \
+        }))
+
+    #define Identity_ncheck(pointer) Identity_check(pointer)
+#endif
+```

doc/cjdns/data_structures/Log.md

@@ -0,0 +1,4 @@
+### Log
+
+- Log_callback print;
+  - TODO: Explain what is going on here

doc/cjdns/data_structures/Log_callback.md

@@ -0,0 +1,7 @@
+### sorry not sure what to make of this quite yet
+typedef void (* Log_callback) (struct Log* log,
+                               enum Log_Level logLevel,
+                               const char* file,
+                               int line,
+                               const char* format,
+                               va_list args);

doc/cjdns/data_structures/NodeStore.md

@@ -0,0 +1,22 @@
+Used in NodeStore_pvt
+defined in NodeStore.h
+### NodeStore
+
+- struct Address* selfAddress;
+<br>
+
+- struct Node_Two* selfNode;
+<br>
+- int peerCount;
+- int linkedNodes;
+  - corolated data
+<br>
+<br>
+- int nodeCount;
+- int nodeCapacity;
+  - corolated data
+<br>
+<br>
+- int linkCount;
+- int linkCapacity;
+  - corolated data

doc/cjdns/data_structures/NodeStore_pvt.md

@@ -0,0 +1,27 @@
+### NodeStore_pvt
+
+- struct [NodeStore][] pub
+- struct [Node_Link][]* selfLink
+- struct [NodeRBTree][] { struct [Node_Two][]* rbh_root; } nodeTree;
+  - inplace struct [NodeRBTree][] generated here  
+    it contains a tree holding all nodes orderd by ipv6 address?
+- struct [Allocator][]* alloc;
+- struct [Node_Link][]* linksToFree;
+  - operated on by freePendingLinks()
+- struct [RumorMill][]* renumberMill;
+  - nodes that have probably been reset?
+- struct [Log][]* logger;
+  - [sic] The means for this node store to log.
+- struct [EventBase][]* eventBase;
+  - To track time?
+- [Identity][]
+  - mesterious checking macro
+[NodeStore]: ./NodeStore.md
+[Node_Link]: ./Node_Link.md
+[Node_Two]: ./Node_Two.md
+[NodeRBTree]: ./NodeRBTree.md
+[Allocator]: ./Allocator.md
+[RumorMill]: ./RumorMill.md
+[Log]: ./Log.md
+[EventBase]: ./EventBase.md
+[Identity]: ./Identity.md

doc/cjdns/data_structures/Node_Link.md

@@ -0,0 +1,51 @@
+defined in Node.h
+Used by NodeStore_pvt
+### Node_Link
+
+- struct {
+    struct [Node_Link][]* rbe_left;
+    struct [Node_Link][]* rbe_right;
+    struct [Node_Link][]* rbe_parent;
+    int rbe_color;
+} peerTree;
+  - Used by the parent's [RBTree][] of links (?).
+
+- int inverseLinkEncodingFormNumber;
+ - The Encoding Form number which is used to represent the first director in the path from  
+   child to parent.(?)
+
+- uint32_t linkState;
+ - The quality of the link between parent and child,  
+   between 0xFFFFFFFF (perfect) and 0 (intolerable).
+
+- uint64_t timeLastSeen;
+  - The time this link was last seen carrying traffic. (Currently limited to ping traffic.) 
+
+- struct [Node_Two][]* parent;
+  - The parent of this peer, this is where the root of the [RBTree][] is. 
+  
+- struct [Node_Two][]* child;
+  - The child of this link.
+
+- struct [Node_Link][]* nextPeer;
+  - linked list
+  - The next link which points to the same child.
+  - For each child there are many links pointing to it,
+
+- struct [Node_Link][]* nextInSplitList;
+  - linked list
+  - Used internally by NodeStore for creating a list used for splitting links.
+
+- uint64_t cannonicalLabel;
+  - The label which would be used to reach the child from the parent.
+  - This label is in a cannonical state and must be altered so that the first Director uses
+  - at least as many bits as are required to reach the grandparent from the parent
+  - in the reverse direction.
+
+- uint64_t discoveredPath;
+  - The path which the incoming packet followed when this node was discovered.
+
+Identity
+[Node_Link]: ./Node_Link.md
+[Node_Two]: ./Node_Two.md
+[RBTree]: ./RBTree.md

doc/cjdns/data_structures/Node_Two.md

@@ -0,0 +1,52 @@
+Defined in Node.h
+Used by [Node_Link][]
+Used by [NodeRBTree][] inside of [NodeStore_pvt][] and others
+
+### Node_Two
+
+- uint32_t reach_pvt;
+  - The reach of the node (how big/fast/close it is).
+  - Since reach is a fraction, the reach number represents a percentage where 0xFFFFFFFF = 100%
+  - DO NOT ALTER THIS OUTSIDE OF NODESTORE
+
+- uint64_t timeLastPinged;
+  - Time the node was last pinged
+  - **not** reset on path changes.
+- int marked;
+  - This is only used to mark/sweep nodes in getWorstNode(), it is meaningless otherwise.
+
+- struct [Address][] address;
+  - addr of current node
+
+- struct [EncodingScheme][]* encodingScheme;
+  - The encoding method used by this node.
+    - TODO: list encodeing methods here
+
+- struct [PeerRBTree][] { struct Node_Link* rbh_root; } peerTree;
+  - Peers of this node for which we know the forward direction.
+  - Use RB_NFIND(PeerRBTree, node->peerTree, struct type* elm)
+
+- struct [Node_Link][]* reversePeers;
+  - Used for freeing the links associated with this node.
+
+
+- struct [Node_Link][]* bestParent_pvt;
+  - The best link for getting to this node.
+
+- struct { struct [Node_Two][]* rbe_left; struct [Node_Two][]* rbe_right; struct [Node_Two][]* rbe_parent; int rbe_color; } nodeTree;
+  - Used by nodeStore's RBTree of nodes by address.
+
+- struct [Allocator][]* alloc;
+  - TODO: find out what this does
+
+- Identity
+  - Magical macro mostly a noop  
+
+[Node_Link]: ./Node_link.md
+[NodeStore_pvt]: ./NodeStore_pvt.md
+[Node_Two]: ./Node_Two.md
+TODO: finish these links
+[NodeRBTree]: ./NodeRBTree.md
+[EncodingScheme]: ./EncodingScheme.md
+[Address]: ./Address.md
+[PeerRBTree]: ./PeerRBTree.md

doc/cjdns/data_structures/RumorMill.md

@@ -0,0 +1,11 @@
+
+The rumor mill is for new nodes which have been discovered by search and
+getPeers requests but, we(who?) have never actually communicated with them so 
+we(who?) are not sure if they exist. More importantly, we(who?) *cannot* link
+them into the nodeStore tree because we(who?) are not sure of their encoding
+scheme.
+
+### RumorMill
+
+- int count;
+  - TODO: Provide some more information about this one.

doc/cjdns/functions/Address_xorcmp.md

@@ -0,0 +1,24 @@
+##### int Address_xorcmp(uint32_t target, uint32_t negativeIfCloser, uint32_t positiveIfCloser)
+```javascript
+if (negativeIfCloser == positiveIfCloser) {
+    return 0;
+}
+```
+
+
+```javascript
+uint32_t ref = Endian_bigEndianToHost32(target);
+return ((Endian_bigEndianToHost32(negativeIfCloser) ^ ref)
+           < (Endian_bigEndianToHost32(positiveIfCloser) ^ ref)) ? -1 : 1;
+```
+Endian_bigEndianToHost32 is a macro with a large branching trail what you need to understand about it is
+if machine endian ness is big return what was passed 
+
+without the macros it looks like:
+
+```javascript
+uint32_t ref = target;
+return ((negativeIfCloser ^ ref) < (positiveIfCloser ^ ref)) ? -1 : 1;
+```
+simple stuff right?
+TODO: explain how the build config files tie in to this Endian business.  

doc/cjdns/functions/compareNodes.md

@@ -0,0 +1,23 @@
+#### static int compareNodes(const struct [Node_Two][]* na, const struct [Node_Two][]* nb)
+call [Address_xorcmp][] over 4 hunks of the ipv6 address 
+in the address struct the data is stored like this:
+uint32_t three_be;  
+uint32_t four_be;  
+uint32_t one_be;  
+uint32_t two_be;  
+
+compareNodes accesses them in counting order
+
+ret = Address_xorcmp(0, na->address.ip6.ints.one_be, nb->address.ip6.ints.one_be);  
+if (ret) { return ret; }
+<BR>
+ret = Address_xorcmp(0, na->address.ip6.ints.two_be, nb->address.ip6.ints.two_be);  
+if (ret) { return ret; }
+<BR>
+ret = Address_xorcmp(0, na->address.ip6.ints.three_be, nb->address.ip6.ints.three_be);  
+if (ret) { return ret; }
+<BR>
+ret = Address_xorcmp(0, na->address.ip6.ints.four_be, nb->address.ip6.ints.four_be);  
+
+if all of these values from node a are equal to node b return 0
+if something other than 0 from Address_xorcmp return that.

doc/cjdns/functions/comparePeers.md

@@ -0,0 +1,10 @@
+#### static int comparePeers(const struct [Node_Link][]* la, const struct [Node_Link][]* lb)
+
+if the number of leading bits of cannicalLabel for la and lb are equal  
+return 0
+
+after reverseing the order of every bit in a and b  
+if a is less than b
+return positive  
+else  
+return negitive

doc/cjdns/nodeinfo-json.md

@@ -0,0 +1,52 @@
+# nodeinfo.json
+
+*A way for nodes to provide info about themselves and improve discoverability.*
+
+This is an evolving standard, we've generally agreed on this format, but we'll
+see what people do with it.
+
+A JSON file at `/nodeinfo.json` that looks something like below. Parsers should
+have no expecations about this file, in my tests found several 404 or other
+non-JSON pages at that path returning HTTP 200. Further, all keys are optional.
+Additional fields can me made up by other node operators. This spec
+will change as we see how people use it. Please provide at least a contact
+email, and ideally a PGP fingerprint with the full key on public keyservers.
+
+Sample Files:
+ * http://[fcef:96c2:7226:a4b1:97ea:59bf:cb2e:51f0]/nodeinfo.json
+ * http://[fcec:ae97:8902:d810:6c92:ec67:efb2:3ec5]/nodeinfo.json
+
+
+```json
+{
+  "key": "cjdnspublickey.k",
+  "hostname": "your.nodes.fqdn",
+  "contact": {
+    "name": "Your name, handle, nick, whatever",
+    "email": "you@domain.tld",
+    "xmpp": "you@domain.tld",
+    "other cool communication service": "whatever identifier they use",
+  },
+  "last_modified": "2014-11-30T00:35:48+00:00",
+  "pgp": {
+   "fingerprint": "FULL40CHARFINGERPRINT",
+   "full": "http://link.to.download/full.key",
+   "keyserver": "hkp://pgp.mit.edu"
+  },
+  "services": [
+    {
+      "uri": "http://[fc00:]/",
+      "name": "My awesome http website",
+      "description": "my blag and stuff"
+    },
+    {
+      "uris": {
+        "webInterface" :"http://example.tld/",
+        "otherthing": "cactus://example.tld/"
+      },
+      "name": "MutliURI service"
+      "description": "Some service with multiple URIs"
+    }
+  ]
+}
+```

doc/cjdns/order-of-compilation.md

@@ -0,0 +1,386 @@
+Here is the order of compilation on  my Linux box (3.13.0-43-generic #72-Ubuntu SMP x86_64) of `*.c` files when `./do` spawns `gcc` using '`-c`', '`-S`' or '`-E`':
+
+The top-most files were compiled first, and has the least number of dependencies. This listing includes the compilation of `cnacl` and `libuv` libraries included in the source tree.
+
+1. `cjdns/node_build/dependencies/cnacl/randombytes/devurandom.c`
+1. `cjdns/node_build/dependencies/cnacl/okcompilers/abiname_xcompile.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_hashblocks/sha512/inplace/blocks.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_scalarmult/curve25519/donna_c64/base.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_scalarmult/curve25519/donna_c64/smult.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_verify/16/ref/verify.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_hash/sha512/ref/hash.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_box/curve25519xsalsa20poly1305/ref/after.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_box/curve25519xsalsa20poly1305/ref/before.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_box/curve25519xsalsa20poly1305/ref/box.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_box/curve25519xsalsa20poly1305/ref/keypair.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_onetimeauth/poly1305/amd64/verify.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_stream/xsalsa20/ref/stream.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_stream/xsalsa20/ref/xor.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_core/salsa208/ref/core.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_stream/aes128ctr/core2/stream.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_stream/aes128ctr/core2/xor.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_hashblocks/sha256/ref/blocks.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_core/hsalsa20/ref/core.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_verify/32/ref/verify.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_core/salsa2012/ref/core.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_hash/sha256/ref/hash.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_core/salsa20/ref/core.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_auth/hmacsha256/ref/hmac.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_auth/hmacsha256/ref/verify.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_secretbox/xsalsa20poly1305/ref/box.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_auth/hmacsha512256/ref/hmac.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_auth/hmacsha512256/ref/verify.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_0.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_1.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_add.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_cmov.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_copy.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_frombytes.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_invert.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_isnegative.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_isnonzero.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_mul.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_neg.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_pow22523.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_sq.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_sq2.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_sub.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/fe_tobytes.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_add.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_double_scalarmult.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_frombytes.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_madd.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_msub.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p1p1_to_p2.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p1p1_to_p3.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p2_0.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p2_dbl.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p3_0.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p3_dbl.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p3_to_cached.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p3_to_p2.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_p3_tobytes.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_precomp_0.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_scalarmult_base.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_sub.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/ge_tobytes.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/keypair.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/open.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/sc_muladd.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/sc_reduce.c`
+1. `cjdns/node_build/dependencies/cnacl/crypto_sign/ed25519/ref10/sign.c`
+1. `cjdns/node_build/dependencies/libuv/src/fs-poll.c`
+1. `cjdns/node_build/dependencies/libuv/src/inet.c`
+1. `cjdns/node_build/dependencies/libuv/src/version.c`
+1. `cjdns/node_build/dependencies/libuv/src/uv-common.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/async.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/core.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/dl.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/fs.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/getaddrinfo.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/loop.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/loop-watcher.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/pipe.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/poll.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/process.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/signal.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/stream.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/tcp.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/thread.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/threadpool.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/timer.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/tty.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/udp.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/proctitle.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/linux-core.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/linux-inotify.c`
+1. `cjdns/node_build/dependencies/libuv/src/unix/linux-syscalls.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-async.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-fs-stat.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-async-pummel.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-getaddrinfo.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-loop-count.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-million-async.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-million-timers.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-multi-accept.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-ping-pongs.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-pound.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-pump.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-sizes.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-spawn.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-thread.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-tcp-write-batch.c`
+1. `cjdns/node_build/dependencies/libuv/test/benchmark-udp-pummel.c`
+1. `cjdns/node_build/dependencies/libuv/test/dns-server.c`
+1. `cjdns/node_build/dependencies/libuv/test/echo-server.c`
+1. `cjdns/node_build/dependencies/libuv/test/blackhole-server.c`
+1. `cjdns/node_build/dependencies/libuv/test/run-benchmarks.c`
+1. `cjdns/node_build/dependencies/libuv/test/runner.c`
+1. `cjdns/node_build/dependencies/libuv/test/runner-unix.c`
+1. `cjdns/node_build/dependencies/libuv/test/blackhole-server.c`
+1. `cjdns/node_build/dependencies/libuv/test/echo-server.c`
+1. `cjdns/node_build/dependencies/libuv/test/run-tests.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-get-loadavg.c`
+1. `cjdns/node_build/dependencies/libuv/test/runner.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-active.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-async.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-async-null-cb.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-callback-stack.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-callback-order.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-close-fd.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-close-order.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-connection-fail.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-cwd-and-chdir.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-delayed-accept.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-embed.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-emfile.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-fail-always.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-fs.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-fs-event.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-get-currentexe.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-get-memory.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-getaddrinfo.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-getsockname.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-hrtime.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-idle.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-iocp.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-ipc.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-ipc-send-recv.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-loop-handles.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-loop-alive.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-loop-stop.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-walk-handles.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-loop-time.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-watcher-cross-stop.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-multiple-listen.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-osx-select.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-pass-always.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-ping-pong.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-pipe-bind-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-pipe-connect-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-pipe-server-close.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-platform-output.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-poll.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-poll-close.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-process-title.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-ref.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-run-nowait.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-run-once.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-semaphore.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-shutdown-close.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-shutdown-eof.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-signal.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-spawn.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-signal-multiple-loops.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-fs-poll.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-stdio-over-pipes.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-bind-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-bind6-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-close.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-close-accept.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-close-while-connecting.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-connect-error-after-write.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-shutdown-after-write.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-flags.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-connect-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-connect-timeout.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-connect6-error.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-open.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-write-to-half-open-connection.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-writealot.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-try-write.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-unexpected-read.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tcp-read-stop.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-threadpool.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-threadpool-cancel.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-mutexes.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-thread.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-barrier.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-condvar.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-timer-again.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-timer-from-check.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-timer.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-tty.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-dgram-too-big.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-open.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-ipv6.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-options.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-send-and-recv.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-multicast-join.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-dlerror.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-udp-multicast-ttl.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-ip4-addr.c`
+1. `cjdns/node_build/dependencies/libuv/test/test-ip6-addr.c`
+1. `cjdns/node_build/dependencies/libuv/test/runner-unix.c`
+1. `cjdns/admin/angel/cjdroute2.c`
+1. `cjdns/contrib/c/publictoip6.c`
+1. `cjdns/contrib/c/privatetopublic.c`
+1. `cjdns/contrib/c/sybilsim.c`
+1. `cjdns/contrib/c/makekeys.c`
+1. `cjdns/crypto/random/randombytes.c`
+1. `cjdns/test/testcjdroute.c`
+1. `cjdns/util/platform/Sockaddr.c`
+1. `cjdns/util/Hex.c`
+1. `cjdns/crypto/Key.c`
+1. `cjdns/benc/String.c`
+1. `cjdns/util/CString.c`
+1. `cjdns/memory/Allocator.c`
+1. `cjdns/util/Assert.c`
+1. `cjdns/dht/Address.c`
+1. `cjdns/crypto/AddressCalc.c`
+1. `cjdns/memory/MallocAllocator.c`
+1. `cjdns/crypto/random/Random.c`
+1. `cjdns/crypto/random/seed/RandomSeed.c`
+1. `cjdns/util/log/Log.c`
+1. `cjdns/exception/Except.c`
+1. `cjdns/util/log/WriterLog.c`
+1. `cjdns/util/Security.c`
+1. `cjdns/util/events/libuv/Process.c`
+1. `cjdns/util/events/libuv/Pipe.c`
+1. `cjdns/util/SysInfo.c`
+1. `cjdns/util/ArchInfo.c`
+1. `cjdns/net/SwitchPinger_admin.c`
+1. `cjdns/benc/serialization/standard/BencMessageWriter.c`
+1. `cjdns/benc/serialization/standard/BencMessageReader.c`
+1. `cjdns/benc/serialization/json/JsonBencSerializer.c`
+1. `cjdns/io/FileWriter.c`
+1. `cjdns/io/FileReader.c`
+1. `cjdns/interface/UDPInterface_admin.c`
+1. `cjdns/interface/InterfaceController.c`
+1. `cjdns/net/SwitchPinger.c`
+1. `cjdns/dht/dhtcore/RouterModule_admin.c`
+1. `cjdns/dht/dhtcore/RouterModule.c`
+1. `cjdns/dht/dhtcore/NodeStore.c`
+1. `cjdns/dht/SerializationModule.c`
+1. `cjdns/dht/ReplyModule.c`
+1. `cjdns/crypto/CryptoAuth_benchmark.c`
+1. `cjdns/admin/Configurator.c`
+1. `cjdns/admin/AuthorizedPasswords.c`
+1. `cjdns/crypto/CryptoAuth.c`
+1. `cjdns/admin/angel/Core.c`
+1. `cjdns/net/Ducttape.c`
+1. `cjdns/util/version/Version.c`
+1. `cjdns/tunnel/IpTunnel.c`
+1. `cjdns/admin/angel/Hermes.c`
+1. `cjdns/switch/SwitchCore.c`
+1. `cjdns/dht/dhtcore/RumorMill.c`
+1. `cjdns/dht/dhtcore/Router.c`
+1. `cjdns/dht/dhtcore/Node.c`
+1. `cjdns/switch/EncodingScheme.c`
+1. `cjdns/benc/List.c`
+1. `cjdns/dht/DHTModuleRegistry.c`
+1. `cjdns/admin/angel/AngelInit.c`
+1. `cjdns/admin/angel/InterfaceWaiter.c`
+1. `cjdns/admin/AdminClient.c`
+1. `cjdns/admin/Admin.c`
+1. `cjdns/util/events/libuv/EventBase.c`
+1. `cjdns/benc/Dict.c`
+1. `cjdns/io/ArrayWriter.c`
+1. `cjdns/util/events/libuv/Timeout.c`
+1. `cjdns/crypto/random/libuv/LibuvEntropyProvider.c`
+1. `cjdns/util/log/FileWriterLog.c`
+1. `cjdns/io/ArrayReader.c`
+1. `cjdns/./interface/tuntap/windows/test/TAPInterface_root_test.c`
+1. `cjdns/./interface/tuntap/windows/test/TAPDevice_root_test.c`
+1. `cjdns/./util/platform/test/Sockaddr_test.c`
+1. `cjdns/./interface/tuntap/test/TUNInterface_ipv6_root_test.c`
+1. `cjdns/./interface/tuntap/test/TUNInterface_ipv4_root_test.c`
+1. `cjdns/./interface/tuntap/test/TAPWrapper_root_test.c`
+1. `cjdns/./dht/dhtcore/test/VersionList_test.c`
+1. `cjdns/./crypto/random/test/Random_test.c`
+1. `cjdns/./util/test/UniqueName_test.c`
+1. `cjdns/./util/test/Seccomp_test.c`
+1. `cjdns/./util/test/Process_test.c`
+1. `cjdns/./util/test/Map_test.c`
+1. `cjdns/./util/test/Identity_test.c`
+1. `cjdns/./util/test/Hex_test.c`
+1. `cjdns/./util/test/Endian_test.c`
+1. `cjdns/./util/test/Checksum_test.c`
+1. `cjdns/./util/test/Bits_test.c`
+1. `cjdns/./util/test/Base32_test.c`
+1. `cjdns/./util/test/Base10_test.c`
+1. `cjdns/./util/test/AverageRoller_test.c`
+1. `cjdns/./util/test/ArchInfo_test.c`
+1. `cjdns/./util/test/AddrTools_test.c`
+1. `cjdns/./tunnel/test/IpTunnel_test.c`
+1. `cjdns/./switch/test/PenaltyFloat_test.c`
+1. `cjdns/./switch/test/NumberCompress_test.c`
+1. `cjdns/./switch/test/LabelSplicer_test.c`
+1. `cjdns/./switch/test/EncodingScheme_test.c`
+1. `cjdns/./memory/test/Allocator_test.c`
+1. `cjdns/./io/test/FileReader_test.c`
+1. `cjdns/./interface/test/UDPInterface_test.c`
+1. `cjdns/./interface/test/UDPInterface_communication_test.c`
+1. `cjdns/./interface/test/MultiInterface_test.c`
+1. `cjdns/./interface/test/InterfaceController_test.c`
+1. `cjdns/./interface/test/InterfaceController_multiIface_test.c`
+1. `cjdns/./interface/test/FramingInterface_test.c`
+1. `cjdns/./interface/test/FramingInterface_fuzz_test.c`
+1. `cjdns/./dht/test/DHTModules_handleOutgoing_test.c`
+1. `cjdns/./dht/test/DHTModules_handleIncoming_test.c`
+1. `cjdns/./crypto/test/ReplayProtector_test.c`
+1. `cjdns/./crypto/test/CryptoAuth_unit_test.c`
+1. `cjdns/./crypto/test/CryptoAuth_test.c`
+1. `cjdns/./crypto/test/CryptoAuth_async_test.c`
+1. `cjdns/./admin/test/Admin_test.c`
+1. `cjdns/./test/threeNodes_test.c`
+1. `cjdns/./test/printIp_test.c`
+1. `cjdns/./test/cjdroute_routerPing_test.c`
+1. `cjdns/./test/cjdroute_injection_test.c`
+1. `cjdns/./test/CryptoAddress_test.c`
+1. `cjdns/util/events/libuv/Time.c`
+1. `cjdns/crypto/random/seed/SystemRandomSeed.c`
+1. `cjdns/util/Seccomp.c`
+1. `cjdns/util/Base10.c`
+1. `cjdns/interface/UDPInterface.c`
+1. `cjdns/dht/dhtcore/ReplySerializer.c`
+1. `cjdns/util/Pinger.c`
+1. `cjdns/util/AverageRoller.c`
+1. `cjdns/dht/dhtcore/VersionList.c`
+1. `cjdns/util/events/libuv/Event.c`
+1. `cjdns/interface/SessionManager_admin.c`
+1. `cjdns/interface/SessionManager.c`
+1. `cjdns/util/Security_admin.c`
+1. `cjdns/util/platform/netdev/NetDev.c`
+1. `cjdns/util/log/IndirectLog.c`
+1. `cjdns/tunnel/IpTunnel_admin.c`
+1. `cjdns/memory/Allocator_admin.c`
+1. `cjdns/interface/addressable/PacketHeaderToUDPAddrInterface.c`
+1. `cjdns/interface/DNSServer.c`
+1. `cjdns/interface/RainflyClient_admin.c`
+1. `cjdns/interface/RainflyClient.c`
+1. `cjdns/interface/FramingInterface.c`
+1. `cjdns/interface/InterfaceController_admin.c`
+1. `cjdns/interface/InterfaceConnector.c`
+1. `cjdns/interface/tuntap/TUNInterface_linux.c`
+1. `cjdns/interface/ETHInterface_admin.c`
+1. `cjdns/util/events/libuv/UDPAddrInterface.c`
+1. `cjdns/dht/dhtcore/Janitor.c`
+1. `cjdns/dht/dhtcore/NodeStore_admin.c`
+1. `cjdns/dht/dhtcore/SearchRunner_admin.c`
+1. `cjdns/dht/dhtcore/SearchRunner.c`
+1. `cjdns/dht/EncodingSchemeModule.c`
+1. `cjdns/admin/angel/Angel.c`
+1. `cjdns/admin/AdminLog.c`
+1. `cjdns/switch/Penalty.c`
+1. `cjdns/benc/serialization/cloner/Cloner.c`
+1. `cjdns/interface/tuntap/test/TUNTools.c`
+1. `cjdns/admin/testframework/AdminTestFramework.c`
+1. `cjdns/interface/tuntap/TAPWrapper.c`
+1. `cjdns/interface/tuntap/NDPServer.c`
+1. `cjdns/crypto/random/test/DeterminentRandomSeed.c`
+1. `cjdns/util/Order.c`
+1. `cjdns/test/TestFramework.c`
+1. `cjdns/util/platform/Socket.c`
+1. `cjdns/interface/MultiInterface.c`
+1. `cjdns/crypto/random/seed/ProcSysKernelRandomUuidRandomSeed.c`
+1. `cjdns/interface/MultiInterface.c`
+1. `cjdns/crypto/random/seed/ProcSysKernelRandomUuidRandomSeed.c`
+1. `cjdns/crypto/random/seed/LinuxRandomUuidSysctlRandomSeed.c`
+1. `cjdns/crypto/random/seed/DevUrandomRandomSeed.c`
+1. `cjdns/util/platform/netdev/NetPlatform_linux.c`
+1. `cjdns/memory/BufferAllocator.c`
+1. `cjdns/interface/ETHInterface_linux.c`
+1. `cjdns/dht/dhtcore/SearchStore.c`
+1. `cjdns/interface/addressable/AddrInterfaceAdapter.c`

doc/cjdns/order-of-linking.md

@@ -0,0 +1,5 @@
+Here is the order of linking on  my Linux box (3.13.0-43-generic #72-Ubuntu SMP x86_64) of various build targets:
+
+The type of files are color coded, so see the legend below the image for more understanding. Tip: Try opening the image in a new tab for better legibility.
+
+![CJDNS Build Targets And Order Of Linking](/en/cjdns/order-of-linking.png)

doc/cjdns/peering-over-UDP-IP.md

@@ -0,0 +1,252 @@
+# Peering over UDP/IP
+
+[Outbound Peer](#outbound) --> UDP/IP --> [Inbound Peer](#inbound)
+(The arrows only refer to the _initiation_ of the connection. Information flows both directions)
+
+Structure:
+
+- [Dynamic IP](#dynamic-ip)
+- [cexec](#cexec)
+- [Adding Peers](#add-peers)
+    - [Information gathering](#info-gathering)
+    - [Inbound Peering](#inbound)
+        - [Authorized passwords](#authorizedpasswords)
+        - [connectTo block creation](#connectTo)
+        - [Edit cjdroute.conf](#edit-cjdroute-inbound)
+        - [Update cjdroute](#update-cjdroute-inbound)
+        - [Update your peer](#update-peer)
+    - [Outbound Peering](#outbound)
+        - [Edit cjdroute.conf](#edit-cjdroute-outbound)
+        - [Update cjdroute](#update-cjdroute-outbound)
+
+Prerequisites:
+
+- cjdroute
+- a network to peer over
+- _preferably_ a static IP
+- some time
+
+If you have a static IP, reading this document in-order should make learning about what needs to be done easy and logical. If you experience disorentation or the urge to start drinking, stop and please drop by the IRC
+
+## Dynamic IP <a name="dynamic-ip"></a>
+
+Giving other people your IP address will not be a good way for your peer to reach you over the UDP/IP layer because, your IP address is subject to change without notice. However, if you know of someone with a static IP you can still connect by making an **outbound** connection to them.  
+**tl;dr** don't choose an option below where you give out your IP address.
+
+## cexec <a name="cexec"></a>
+
+If you have any trouble in this section it is safe to skip but, you will need to use another tool or shutdown your cjdroute to add a new peer.  
+
+Usage:
+
+- make a file here `~/.cjdadmin`
+
+put something like this inside:
+
+```script
+{
+    "password": "from your admin section in your cjdroute.conf",
+    "config": "/path/to/cjdroute.conf",
+    "addr": "127.0.0.1",
+    "port": 11234
+}
+```
+make an alias:
+```script
+alias cjdadmin='/path/to/cjdns/contrib/python/cexec'
+```
+If you like you can put it in your `~/.*rc` for your terminal flavor.
+
+## Adding peers <a name="add-peers"></a>
+
+It is essential at this point in time that peers stay connected the network is small and subject to do strange things.  
+Reasons you should have your peers contact information:
+
+- Network diagnosis
+- Network community
+- You can contact them if you need to move your node
+
+### Information Gathering <a name="info-gathering"></a>
+
+- IP address can be found by a google of "whatismyip"
+- public key is right here:
+
+```script
+    // This key corresponds to the public key and ipv6 address:
+    "publicKey": "3u2fz3fcyblrz7nspwzkcxp7xph80h5hwu1qu4qrumrqym80r0u0.k",
+    "ipv6": "fc5e:8c49:b6ce:d1f5:b89c:fcd6:e536:a479",
+```
+
+- port is right here:
+
+```script
+    "interfaces":
+    {
+        // The interface which connects over UDP/IP based VPN tunnel.
+        "UDPInterface":
+        [
+            {
+                // Bind to this port.
+                "bind": "0.0.0.0:43653",
+
+                // Nodes to connect to.
+                "connectTo":
+
+```
+
+
+### InboundPeering<a name="inbound"></a>
+
+You give your peer your IP address, port, and password.  
+Prerequisites:
+
+- A long passphrase that you do not have to remember
+- Your pubkey
+- Your static IP
+- The open port your cjdroute is listening on
+- Any other information you would like for your peer to have
+
+#### Make your authorizedPasswords block <a name="authorizedpasswords"></a>
+
+```script
+        {
+                "password": "vt1ly5f4ydmm9gjk196t160z23t6uju",
+                "name": "[put your peers name here]",
+                "contact": "[put your peers contact info here]"
+        },
+```
+Things that are parsed:
+
+- password
+
+Everything else is for humans.
+
+#### Make your peers connectTo block <a name="connectTo"></a>
+
+(alredy indented just enough for the current cjdroute.conf section it goes in)
+
+```script
+                        "[your IP address]:[your open port]": {
+                                "password": "[your long passphrase]",
+                                "location": "New York City, NY, US",
+                                "[insert cool noun here]": "[something witty]",
+                                "contact": "[email address, phone number, ICQ, jabber take your pick]"
+                                                "ipv6": "fcth:isis:notE:ssen:tial:butg:oodt:know",
+                                                "publicKey": "thisIsFromYourCjdrouteConfAtTheTopItEndsWithADotanda.k",
+                    },
+```
+Things that are parsed:
+
+- IP address and port number combo
+- password
+- pubkey
+
+Everything else is for humans.
+
+#### Edit cjdroute.conf <a name="edit-cjdroute-inbound"></a>
+
+After verifying that your made up password matches the password you will give to your friend, paste your authorizedPasswords block into your authorizedPasswords section.
+
+Like this.
+```script
+   //
+    "authorizedPasswords":
+    [
+        //note the comma added to the end of each block
+        //default password
+        {"password": "pnc8q05llp9sx7d1b4bc3d6ru0krgbl"},
+        {
+                "password": "vt1ly5f4ydmm9gjk196t160z23t6uju",
+                "name": "[put your peers name here]",
+                "contact": "[put your peers contact info here]"
+        },
+
+        // More passwords should look like this.
+        // {"password": "tjrwwlsh4ugddk032yu8vrnv11v8z5f"},
+        // {"password": "pm0643f911j71w0pctj5s7bkk0s8htv"},
+        // {"password": "2vls52j3q4151dk8h2kz939kt0ldu75"},
+
+        // Below is an example of your connection credentials
+        // that you can give to other people so they can connect
+        // to you using your default password (from above)
+        // Adding a unique password for each user is advisable
+        // so that leaks can be isolated.
+        //
+        // "your.external.ip.goes.here:43653":{"password":"vt1ly5f4ydmm9gjk196t160z23t6uju","publicKey":"3u2fz3fcyblrz7nspwzkcxp7xph80h5hwu1qu4qrumrqym80r0u0.k"}
+    ],
+```
+Save cjdroute.conf
+
+#### Update cjdroute <a name="update-cjdroute-inbound"></a>
+
+There are 2 ways to do this.  
+`sudo killall cjdroute`
+Or
+```script
+cjdadmin 'AuthorizedPasswords_add("[YourLongPasswordYouWillGiveAway]","[peerUserName_aka_frendlyname]",1,0)'
+```
+Find out more about this command in the [admin/README.md][cjd-admin-readme] ([clearnet][cjd-admin-readme-clearnet]) section of the cjdns repository.
+
+#### Update your peer <a name="update-peer"></a>
+
+Securely transfer the connectTo block you created for your peer.  
+Ways to do this:
+
+- Get [GPG][]
+- Get [OTR][]
+- Get [Tox][]
+- Write it down and walk to their house.
+
+### Outbound Peering<a name="outbound"></a>
+
+You will receve a connectTo block through secure means.  
+Prerequisites:
+
+- A peer that has agreed to accept an inbound connection
+- A connectTo block from your peer
+
+#### Edit cjdroute.conf <a name="edit-cjdroute-outbound"></a>
+
+Paste your peers info inside your connectTo block.
+```script
+                // Bind to this port.
+                "bind": "104.131.101.214:61522",
+
+                // Nodes to connect to.
+                "connectTo":
+                {
+                        // Note the comma at the end of their block
+                        "[address]:[port]": {
+                                "password": "[longPasswordYourPeerGaveYou]",
+                                "location": "New York City, NY, US",
+                                "hostname": "example.com",
+                                "contact": "Alice@gmail.com"
+                                                "publicKey": "ThisisFromTheirCjdrouteConfAtTheTopItEndsWithADotand.k",
+                                                "ipv6": "fc00:0000:0000:0000:0000:0000:0000:0000",
+                    },
+                    // Add connection credentials here to join the network
+                    // Ask somebody who is already connected.
+                }
+```
+Save cjdroute.conf
+
+#### Update cjdroute <a name="update-cjdroute-outbound"></a>
+
+There are 2 ways to do this.  
+`sudo killall cjdroute`
+Or
+```script
+cjdadmin 'UDPInterface_beginConnection("[yourPeersPubkeyGoesHereItEndsWith.k]","[address]:[port]",0,"[longPasswordYourPeerGaveYou]")'
+
+```
+Find out more about this command in the [admin/README.md][cjd-admin-readme] ([clearnet][cjd-admin-readme-clearnet]) section of the cjdns repository.
+
+## questions?
+
+
+
+[Tox]: https://tox.im/
+[OTR]: https://otr.cypherpunks.ca/
+[GPG]: https://www.gnupg.org/
+[cjd-admin-readme]: http://gitboria.com/cjd/cjdns/blob/master/admin/README.md
+[cjd-admin-readme-clearnet]: https://github.com/cjdelisle/cjdns/blob/master/admin/README.md

doc/ctrls.md

@@ -0,0 +1,16 @@
+# 3rd Party Tools for managing/working with cjdns
+
+To automate some simple tasks with cjdns, there are a lot of scripts that people use. Here's just a few:
+
++ https://github.com/kpcyrd/yrd
+  + Displays nodeinfo
+  + Shows your neightbors and their neighbors
+  + Show bandwidth
+  + Ping nodes
+  + Dump nodestore
+  + Show uplinks of a node
+
++ https://github.com/noway421/cjdmaid
++ https://github.com/inhies/cjdcmd
++ https://github.com/ehmry/cjdcmd-ng
++ tcjdns (ask prurigro)

doc/faq/general.md

@@ -0,0 +1,96 @@
+## What is Project Meshnet?
+
+Project Meshnet is an organization that aims to build a versatile, decentralized network built on secure protocols for routing traffic over private mesh or public networks independent of a central supporting infrastructure.  
+  
+## What is Cjdns?
+
+Cjdns (Caleb James DeLisle's Network Suite) is a networking protocol and reference implmentation. It is founded on the ideology that networks should be easy to set up, protocols should scale smoothly, and security should be ubiquitous.  
+  
+## How do I install Cjdns?
+
+Instructions are on [github](https://github.com/cjdelisle/cjdns)
+
+## What is Hyperboria?
+
+[Hyperboria](http://hyperboria.net) is an encrypted [Mesh Network](http://en.wikipedia.org/wiki/Mesh_networking) designed for privacy and resiliency to censorship.
+
+It currently exists as an [Overlay](http://en.wikipedia.org/wiki/Overlay_network) test network for [Project Meshnet](https://projectmeshnet.org/), and is only accessible to those who install [cjdns](http://en.wikipedia.org/wiki/Cjdns). 
+
+Ultimately, we hope to build a viable alternative to the regular internet, which we call [clearnet](http://www.urbandictionary.com/define.php?term=clearnet). Our ultimate goal is to replace the existing hierarchical internet with a non-hierarchical model.
+
+You are encouraged to set up your own means of communication that does not rely on the internet, maybe using something like [this woktenna](http://geobray.com/2010/02/07/woktenna-for-3g/)?
+
+In order for this to be plausible, we require a sufficiently dense number of nodes. Neighbouring nodes need to be able to communicate with each other somehow.
+
+Chains of nodes are vulnerable to being shut off if even one link is taken offline, so we aim for clusters of interconnected nodes.
+
+This is called a [Meshlocal](/locals). I am trying to start a [Toronto-based MeshLocal](/toronto).
+
+To join the network, you need a password and a public key from someone who is already on the network. If you're in Toronto or the surrounding area, and are interested, <a href="/contact">contact</a> me.  
+  
+## Is Cjdns anonymous?
+
+No, Cjdns is not anonymous, nor is it intended to be. For a more in-depth explanation, take a look at the <a href="https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md">whitepaper</a>.  
+  
+## I can ping||curl||wget a cjdns ipv6, but I can't browse to it. What's up?  
+
+It's most likely a problem with your browser. If you are using Firefox||Iceweasel||Chrome||Chromium, we know about this, and there's a fix.  
+
+In Firefox or Iceweasel, everything should work out of the box (on Debian and Ubuntu, at least). Mint is weird, and has for some reason disabled IPV6 by default in their Firefox package. You can turn it on by entering `about:config` in your omnibox. You may get some sort of warning about it being possible to break things, ignore it and proceed. Enter `IPv6` in the search field that appears. There should be an entry: `disableIPv6`, and it is likely set to `true`. Set it to be false, and just to be sure, close the browser completely and reopen it to test things out.
+
+If you are using chrome or chromium, you probably need to relaunch the browser using a flag that enables ipv6. `chromium-browser --enable-ipv6` or `google-chrome --enable-ipv6` should do the trick.  
+
+If you're having trouble browsing to a raw ipv6 string, keep in mind that different programs still use different formats for entering such ip addresses. Most browsers require that you enclose the address in square brackets, like `http://[fce3:4ece:ab11:505e:21aa:fc21:bf42:62b9]/` <- this.  
+
+Some irc clients (Hexchat) need you to enter `fcbe:5f12:67d8:77ea:e4d8:aecc:2b4f:a4b/6667`  
+  
+## It's still not working  
+
+It's also possible that everything's configured properly, but you don't have a route to the node you're trying to find. When this is the case, you can try to strengthen the connection according to <a class="clearnet" href="http://en.wikipedia.org/wiki/Hebbian_theory">Hebbian Theory</a>, which, in neuroscience, is the idea that 'cells that fire together, wire together'. You might not know a route to that node, but it might have one to you. Getting them to ping you, if possible, should give you a better connection. If they can't, have them ping nearby nodes that they can find. You should do the same. Consult <a href="http://www.fc00.org">www.fc00.org</a> to get a better idea of what nodes you should look for.  
+  
+## Is it possible for a central server to know routes to every other node?
+
+There are limits to the size of any node's routing table, but at hyperboria's current size, one server can know it all. That won't remain true as it grows.  
+
+## What is Hyperboria's solution for DNS?  
+
+* HypeDNS
+* RainflyDNS
+* Parabolic DNS
+* why not namecoin?
+
+## What crypto does cjdns use?  
+
+* Salsa20
+* NaCl
+
+## How can I host my own website on Hyperboria?  
+
+* Apache
+* Nginx
+* NodeJS
+
+## Can cjdns be made to automatically run||update?
+
+* If you are using the master branch, things should be stable enough to periodically update. You probably shouldn't do this if you're using crashey. I prefer to run updates manually so I know when things have changed.
+* There are many ways to set cjdns to always run in the background, though methods will vary depending on your system.
+
+## Do I need to run cjdroute as root?
+
+Short Answer: Pretty much
+
+Longer Answer: You generally need root permissions to create the encrypted tunnel interface that cjdns uses to communicate with other nodes. Once that is created, all extraneous permissions are dropped. In any case, cjdroute is limited to reading/writing from 0 files, so even if someone could exploit it, they wouldn't be able to access anything of any value.
+
+## What systems are supported?
+
+Short Answer: not windows.
+
+Long Answer: Check the dependency list. You need access to a C99 compiler, NodeJS, Python, LibUV...
+
+## Can I use UPNP to bypass NAT?  
+
+cjdns does not interact at all with your NAT setup. Use some other upnp client to control your router.  
+
+## Is there a linux distribution that works best as a Hyperboria node?
+
+Pretty much any distro will work, though some may require more tweaks.

doc/faq/glossary.md

@@ -0,0 +1,29 @@
+# Glossary
+
+## Proposed rules
+
+This is an incomplete list of terms used in direct context of cjdns.
+
+- Please add terms convering cjdns itself, tools and best practices, peering,
+  community, Hyperboria, similar routing protocols --
+  e.g. NodeStore, peer stats, WTFM, buildbot, 802.11s
+- Please don't add terms which are out of scope --
+  e.g. BitTorrent or Peer To Peer
+- Abbreviations are okay, e.g. P2P, DHT, OLSR
+
+## List of Terms
+
+### Hidden Peers
+
+This was a peering bug which was fixed in cjdns v14. Please make sure none of
+your peers is affected, and if there is one, tell them to update.
+
+    tools/peerStats | sort
+
+### NodeStore
+
+The internal name of cjdns' routing table.
+
+### P2P
+
+Abbreviation of Peer To Peer.

doc/faq/peering.md

@@ -0,0 +1,147 @@
+## What is Hyperboria?
+
+[Hyperboria](http://hyperboria.net) is an encrypted [Mesh Network](http://en.wikipedia.org/wiki/Mesh_networking) designed for privacy and resiliency to censorship.
+
+It currently exists as an [Overlay](http://en.wikipedia.org/wiki/Overlay_network) test network for [Project Meshnet](https://projectmeshnet.org/), and is only accessible to those who install [cjdns](http://en.wikipedia.org/wiki/Cjdns). 
+
+Ultimately, we hope to build a viable alternative to the regular internet, which we call [clearnet](http://www.urbandictionary.com/define.php?term=clearnet). Our ultimate goal is to replace the existing hierarchical internet with a non-hierarchical model.
+
+You are encouraged to set up your own means of communication that does not rely on the internet, maybe using something like [this woktenna](http://geobray.com/2010/02/07/woktenna-for-3g/)?
+
+In order for this to be plausible, we require a sufficiently dense number of nodes. Neighbouring nodes need to be able to communicate with each other somehow.
+
+Chains of nodes are vulnerable to being shut off if even one link is taken offline, so we aim for clusters of interconnected nodes.
+
+This is called a [Meshlocal](/locals). I am trying to start a [Toronto-based MeshLocal](/toronto).
+
+To join the network, you need a password and a public key from someone who is already on the network. If you're in Toronto or the surrounding area, and are interested, <a href="/contact">contact</a> me.  
+  
+## Can I run Cjdns in a virtual machine?
+
+You can, but you might have trouble finding willing peers, since you're not really contributing much to the network by having a 'sometimes-on' node.  
+  
+## Why is it taking so long to find a peer?  
+
+This project is run entirely by volunteers. In fact, 'run' might give you the idea that it's some kind of beureaucratic body. It isn't. We argue about things, sometimes <a class="clearnet" href="http://www.bestbytepc.com/uploads/2/6/6/1/2661857/7237729_orig.jpg">IN ALL CAPS</a>. Sometimes people <a href="https://encyclopediadramatica.es/Quitting_IRC_forever">QUIT IRC FOREVER</a>. We reach a consensus, or we don't, and people just do what they want. Actually, even if we do reach a consensus, we're still just doing what we want. If you expected something other than anarchy, I encourage you to read more about what a meshnet is.  
+
+That means you should be patient, since you're relying on other people's good will (crazy, I know). This is a friend of a friend network, which shocks people, because they actually have to make friends. Tell us about yourself. Where are you located? Do you operate any servers, or are you new to this? If you're new, why do you want to learn? Maybe you maintain a <a class="clearnet" href="http://blag.xkcd.com/">blag</a> or something? That's pretty much what we do on Hyperboria. If you aren't interested in doing that kind of thing, but want access, I'm not sure what your motivation is. We're basically a bunch of DIYers making our own internet. That kind of thing takes time. Think in terms of years, not months. Read <a class="clearnet" href="http://en.wikipedia.org/wiki/Internetwork">this</a> and <a class="clearnet" href="http://en.wikipedia.org/wiki/History_of_the_Internet#Three_terminals_and_an_ARPA">this</a> to get a sense of context for what this project is about.  
+
+With that in mind, say hi, tell us what you're doing. We're pretty enthusiastic about sharing our interests if it's unlikely that you're a <a class="clearnet" href="http://www.urbandictionary.com/define.php?term=feds">FED</a>.  
+
+Read [this document](/cjdns/peers) on peering for more info.
+  
+## Why should I prefer the friend of a friend model?  
+
+Hyperboria is a pseudonymous network, your direct peers can tell where you are (by virtue of their connection), no one else can (unless you expose your data personally).  
+
+A network that presupposes this principle is resistant to censorship because people cannot simply find you and punish you for your opinions. Many of the links that make up our network cross between legal jurisdictions, and are not subject to the whims of a single government.  
+
+Other networks which do more to guarantee absolute anonymity tend to attract behaviour which would be reprehensible in almost any other social situation. We are proud of our network's ability to promote free speech, while minimizing behaviour which violates human rights. Some have made the point that restriction of any kind of content is censorship, and our views are self contradictory.  
+
+The premise is simple: you get to decide who you connect to, provided they consent. It is not some centralized body which will decide to disconnect you if you use our bandwidth for malicious purposes. You are only accountable to your peers. The rest tends to sort itself out.  
+
+## Can I run cjdns from home (dynamic IP/NAT'ed connection)?
+
+We describe it in terms of 'inbound' and 'outbound' peers
+
+Inbound means people can connect to you, which requires either not being behind a router, or being able to forward ports
+
+Anyone who can install and run cjdns can be an outbound peer
+
+## Do I need to exchange credentials with all my peers?
+
+No, you do not. One of you needs to have an accessible IP in order to establish a connection, but once connected, traffic flow is bidirectional.  
+
+It won't hurt for you to add each other to your conf file, but unless one of your IPs suddenly changes, there isn't much benefit to the redundancy.  
+  
+## What information should I provide with my peering credentials?  
+
+<a href="https://wiki.projectmeshnet.org/User:Thefinn93">thefinn93</a> recommends offering <a class="clearnet" href="http://jsonlint.com/">valid JSON</a>, including fields labelled:  
+
+```JSON
+"your.ip.add.ress:port":{  
+  "publicKey":""
+  ,"password":""
+  ,"IPV6":""
+  ,"location":""
+  ,"contact":""
+}
+```
+
+Technically, only the IP, port, publicKey, and password are required. IPV6 will make it easier to keep track of who is connected, and what kind of latency they are experiencing. The location helps your peer direct possible local meshers your way. Contact should be some non-hyperborian method, in case your connection breaks. <a class="clearnet" href="http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol">Email</a>, <a class="clearnet" href="http://rows.io/">XMPP</a>, <a href="/gpg">PGP</a>, <a href="https://keybase.io/">Keybase.io</a>, <a href="/contact">etc</a>.  
+  
+## Beyond my first peer, how can I set up a more efficient network?
+  
+[Read this](http://en.wikipedia.org/wiki/Small-world_network)
+
+People are much more receptive to peering requests if you have already connected to Hyperboria.  EFNet has a much wider audience, and as such is treated with skepticism. Those with their foot already in the door will have an easier time making friends. If you think this is clique-ish or elitist, you may be right. If you want it to change, then <a class="clearnet" href="http://www.elephantjournal.com/2011/08/be-the-change-you-wish-to-see-in-the-world-not-gandhi/">be the change you want to see in the world</a>, and get on EFNet and start helping!  
+
+It's  a bit circular, but it's a not a rule we have, more of an emergent behaviour. Many of us have spent a lot of time on EFNet helping newcomers to connect, only to have them leave after connecting for fifteen minutes.  Once we've seen that you are competent enough to connect, and that you have some lasting interest, there is far more incentive to spend time getting to know you.
+
+As to how the technical specifications of the network architecture...  
+  
+## How many peers should I have?
+
+The number of peers you should have depends on a number of factors  
+
+if you're on a laptop that you travel with, you probably don't want to route for people. For instance, if you occasionally tether your phone, you might accidentally run up your data bill if you aren't mindful of the traffic you are routing. In such a case, keep only one peer, and you will never be a path, only a leaf node.  
+
+If, however, you are trying to peer with, say, a home connection with a decent data cap and throughput, you may want to add a few more connections. These ought to be limited to fairly local peers, as latency can add up fairly quickly with each successive hop. Home connections are primarily where the wireless aspect of the meshnet comes into play, since neither your laptop or VPS will likely be able to connect to a mid-range wireless antenna. If you have a clear line of sight to your peer (you live on a hill, or have really cool neighbours), all data travelling over this connection is free! Make use of that! Put each other on IP whitelists with access to higher bandwidth services. A meshlocal is capable of a lot of things that become difficult at the scale of a global meshnet.  
+
+If you're peering up a VPS with high throughput and unlimited data, you have the capacity to do things most residential connections can not. You are capable of acting as a highway for the meshnet. Keep in mind that it can be a bad idea for highway traffic to have direct exits into residential areas (metaphorically speaking). It's a good idea to use your connection to establish long range links between your meshLocal and others in far off places. Trans-Oceanic links help link together a greater number of node operators across the globe, and allow us all to communicate what kinds of issues we are each experiencing.  
+
+It would be unrealistic to expect any network to be completely uniform. The optimal configuration changes over time according to the habits of its many users. Healthy configurations look less like a <a class="clearnet" href="http://en.wikipedia.org/wiki/Spoke-hub_distribution_paradigm">spoke-hub distribution</a> and more alike a river, or tree. It is possible to have an efficient hierarchy without being centralized, just avoid <a class="clearnet" href="http://en.wikipedia.org/wiki/Single_point_of_failure">SPOF</a>s.  
+  
+This may sound a lot like urban planning to you. It is! Consider <a class="clearnet" href="http://en.wikipedia.org/wiki/The_100-Mile_Diet">The 100-Mile Diet</a>. You don't want to have to 'drive halfway across town to get to the grocery store'. We are simply trying to mitigate the unpleasant side effects of urban sprawl. We are planning for <a class="clearnet" href="http://en.wikipedia.org/wiki/Walkability">walkable neigbourhoods</a>.  
+
+If there is only one grocery store in a 400-mile radius, then everyone needs a car. Prime real estate (that which is close to the store) becomes quite expensive, while it is cheaper, yet <a class="clearnet" href="http://en.wikipedia.org/wiki/End-to-end_principle">inefficient</a>, to live on the fringe. Following this metaphor, ISPs are basically a grocery delivery service. If they decide not to deliver your groceries (remember <a class="clearnet" href="http://beattheblockade.org/">the wikileaks blockade</a>?) you starve. We want to help you plant a community garden, where everyone can benefit - as long as they contribute their fair share. I may have no reason to just give away vegetables that I worked hard for, but I'd be happy to trade for a different crop simply because I enjoy variety.  
+  
+## How can I generate passwords for new peers?
+
+Easy, just run the following command:  
+
+<code>cat /dev/urandom | strings | head -n 20 | tr -d '\n"`\\ \t'  | head -c 40 && echo</code>  
+  
+## Can I use UPNP to bypass NAT?  
+
+cjdns does not interact at all with your NAT setup. Use some other upnp client to control your router.  
+
+## Can I substitute a domain for an IP in my connectTo?
+
+cjd originally had no intention of implementing this, but someone<a href="/contrib">(?)</a> implemented it and submitted a pull request. Now you can.  
+
+## Is there a meshlocal in my vicinity?
+
+Check <a href="/locals">this page</a> for a basic list of some general areas. It is not an exhaustive list. If you'd like to get listed, check <a href="/contrib">my contributions page</a> for an idea on how to do that.  
+
+## Can someone give me peering info?
+
+```text
+01:53 -!- newguy [webchat@198.20.69.234] has joined #cjdns
+01:54 < newguy> can someone point me toward a public peer?
+01:55 -!- newguy [webchat@198.20.69.234] has quit [Client Quit]
+```
+
+We see this **a lot**. You should read [ircerr's peers.txt](/peers), [the peering section of my old faq](/faq#peering), and [my page about meshlocals](/locals).
+
+TL;DR :: this isn't a public network, and we're under no obligation to give credentials to everyone who asks. We aren't a non-profit, or a corporation, or even a cohesive group. Everyone here has their own motivations and ideas of what the network should be, and you need to find someone who wants to connect to you. Don't be shy, introduce yourself.
+
+## My peer's connection details aren't working, what's wrong?
+
+I don't know, maybe start by asking your peer? If you don't know how to contact your peer, then you may have just learned a valuable lesson. Take down your next peer's info so that you can tell them when something is wrong. If somebody gave you credentials to connect, then you are officially **their problem**.
+
+## How can a figure out which peers I am directly connected to?
+
+```JSON
+{
+    "addr": "127.0.0.1"
+    ,"port": 11234
+    ,"password": "notAnActualPass.UseYourOwnFoundInYourConf"
+}
+```
+
+Make a file called `~/.cjdnsadmin`, containing valid JSON with the properties above. These credentials will be used by any scripts which need to connect to the admin interface to gather data. 
+
+To find your peers, run `cjdns/contrib/nodejs/tools/peerStats.js`
+
+Alternatively, you can use [this tool which does a few other things as well](https://github.com/ehmry/cjdcmd-ng).

doc/index.md

@@ -0,0 +1,38 @@
+# Project Meshnet Documentation
+
+Here's some documentation we've been working on. Feel free to fork us and [add some pages!](notes/wanted.md)
+
+* [Intro](intro.md)
+ * [General FAQ](faq/general.md)
+ * [Peering FAQ](faq/peering.md)
+ * [Glossay](faq/glossary.md)
+ * [Changelog for cjdns](cjdns/changelog.md)
+ * [Anatomy of a running cjdns](cjdns/anatomy.md)
+ * [Node Operator Guidelines](cjdns/Operator_Guidelines.md)
+ * [nodeinfo.json](cjdns/nodeinfo-json.md)
+* [Commodity routers and OpenWrt](openwrt.md)
+* [Mesh Local Intro](meshlocals/intro.md)
+ * [Existing Meshlocals](meshlocals/existing/index.md)
+ * [Starting Your Own](meshlocals/diy.md)
+* Known Bugs
+ * [Black Hole](bugs/black-hole.md)
+ * [Secret Santa](bugs/santa.md)
+ * ~~Hidden Peers~~
+
+## These notes are unstructured and possibly outdated:
+
+* [Interesting links](notes/links.md)
+* [ansuz' Q&A with Arceliar](notes/arc-workings.md)
+* [cjdns-core](notes/cjdns-core.md)
+* [cryptography](notes/cryptography.md)
+* [cjdroute.conf](notes/cjdroute.md)
+* [cjdns/do](notes/do.md)
+* [DNS ideas](notes/dns.md)
+
+## Cjdns ships with a fair amount of documentation
+
+...Though you may not think to look in all the places it's stored.
+
+[This document](https://github.com/lgierth/cjdns/blob/docs/docs/index.md) includes an index of those files.
+
+See also [tips and tricks](tipsAndTricks.md)

doc/intro.md

@@ -0,0 +1,86 @@
+# What the fc00::/8
+## a brief introduction to cjdns
+
+author: [kpcyrd](http://github.com/kpcyrd)
+
+original location: https://github/ansuz/cjdns-pr
+
+```quote
+We have the means and we have the technology to end mass surveillance without any legislative action at all, without any policy changes. By basically adopting changes like making encryption a universal standard - where all communications are encrypted by default - we can end mass surveillance not just in the United States but around the world.
+- Edward Snowden
+```
+
+## The current internet
+
+ - Addresses get spoofed
+ - Services get censored
+ - Networks get hijacked
+ - Controlled by evil corps
+ - **Everybody can read yo packets**
+
+## Where we're going
+
+- Encrypts all your packets
+- Almost zeroconf
+- No authorities like IANA
+- Clean IPv6 networking interface
+- Enough addresses for everybody
+
+## Sounds complicated
+
+1. Install cjdns
+2. Find a friend to connect to
+
+## Friend to Friend
+
+- Nobody knows who's behind an address since there's no registry
+- Your friends know, though
+- In case of abuse your friends may stop peering with you
+
+## Peering (The simple way)
+
+1. Get a friend who's connected
+2. Get a cable
+3. Connect the cable to each computer
+4. Enable autopeering
+5. Connection established
+
+## Peering (Over the internet)
+
+1. Configure an IP address on both sides
+2. Ensure one is able to connect to the other
+3. Exchange peering credentials over a secure channel
+4. Encrypted traffic will be encapsulated in UDP packets
+
+## How is it secure?
+
+There's no central trust authority.
+
+**fc42:18f1:763b:9b70:0059:9896:ef20:6de7**
+
+All those random letters are used to verify your identity.
+
+The address is the cryptographical fingerprint.
+
+## ICANN hax it
+
+- Don't use DNS to distribute your IPv6
+- DNS can be hijacked
+- Thus, cjdns addresses can get spoofed
+
+If we use the current domain name system it's not very secure
+
+## Namecoin to the rescue
+
+- Fully decentralized
+- Stores all addresses in an uncensorable blockchain
+- Cryptographically ensures authenticity
+
+## Next steps
+
+- Android devs - Help going mobile
+- Peers - Help the networks health
+- Services - Help providing more useful stuff
+- Windows devs - Help the lost souls
+
+All skill levels wanted

doc/meshlocals/diy.md

@@ -0,0 +1,13 @@
+# Starting your own Mesh Local
+
+One of the first things to come to terms with is that a mesh network is **peer to peer** and **non-heirarchical**. A mesh local should reflect this, and not depend entirely upon one individual to coordinate its actions.
+
+When you find someone else who is interested, divide "duties" according to your respective skill sets, and don't worry about getting everything right to begin with. Responsibility has a way of motivating people.
+
+You'll want to create at least a minimal web presence so that those interested in getting involved can do so. This often includes, but need not be limited to:
+
+* A website
+* At least one designated individual who can speak for the project
+* An irc channel where new users can be directed
+* A link to a mailing list, if you have one (also very handy). If you'd like a solid mailing list instead of hosting your own, contact [finn](mailto:finn@seattlemesh.net).
+* A short description of your local's particular goals

doc/meshlocals/existing/freifunk.md

@@ -0,0 +1,11 @@
+# Freifunk
+
+There are individuals running cjdns nodes on the Freifunk networks in Leipzig,
+Berlin, and Hamburg.
+
+- kpcyrd
+- larsg
+
+You can find both of us in #cjdns on EFnet and HypeIRC.
+
+More information about Freifunk: https://freifunk.net

doc/meshlocals/existing/index.md

@@ -0,0 +1,16 @@
+# List of Known Meshlocals
+
+These are some physical mesh networks that use cjdns in The Real World. Add
+yours by submitting a pull request.
+
+ * **Europe**
+  * [Freifunk: Leipzig, Berlin, Hamburg](freifunk.md)
+ * **United States**
+  * California
+    * [San Diego](sandiego.md)
+  * [Virginia](virginia.md)
+  * Washington
+    * [Seattle](seattle.md)
+ * **Canada**
+  * Ontario
+    * [Toronto](toronto.md)

doc/meshlocals/existing/sandiego.md

@@ -0,0 +1,6 @@
+San Diego Meshnet
+============
+
+**[Website](http://sdmesh.net/)**
+
+**[Mailing List](http://lists.projectmesh.net/cgi-bin/mailman/listinfo/sandiego)**

doc/meshlocals/existing/seattle.md

@@ -0,0 +1,8 @@
+Seattle Meshnet
+============
+
+**Subreddit**: [/r/SeattleMeshnet](https://www.reddit.com/r/SeattleMeshnet)
+
+**IRC Channel:** [#SeattleMeshnet on EFNet](irc://irc.efnet.org/#seattlemeshnet)
+
+**Mailing List:** [click me](https://lists.projectmesh.net/seattle)

doc/meshlocals/existing/toronto.md

@@ -0,0 +1,4 @@
+Toronto Meshnet
+====
+
+**Website** : [TransitionTech](http://transitiontech.ca/toronto)

doc/meshlocals/existing/virginia.md

@@ -0,0 +1,23 @@
+VirginiaMesh
+============
+
+**Our Goals:**
+
+* Create smaller meshes in Virginia when we reach a larger amount of members
+
+* Connect Virginians up to Hyperboria
+
+* Increase public awareness about CJDNS, Hyperboria, and Project Meshnet
+
+* Foster a community of knowing and helping others, in whatever way possible
+
+* Foster trust in our community, because without trust, we are nothing.
+
+
+**Subreddit**: [/r/VirginiaMesh](https://reddit.com/r/VirginiaMesh)
+
+**Main Contact:** [Caleb Smith](mailto:caleb@calebsmith.net)
+
+**IRC Channel:** [#VirginiaMesh on EFNet](irc://irc.choopa.net/virginiamesh)
+
+**Mailing List:** http://lists.projectmesh.net/virginia

doc/meshlocals/intro.md

@@ -0,0 +1,33 @@
+# Mesh Local Intro
+
+## What is a Mesh Local?
+
+A 'Mesh Local' is a mesh network situated in a particular geographic locale, focused on providing a community-centric alternative (or complement) to the internet.
+
+## How local is local?
+
+Project Meshnet's mesh networking protocol (cjdns) was designed to be agnostic of the medium over which it communicates. That means that even if the closest node is beyond the functional range of radio signals, you can still peer with it over the internet.
+
+While this is useful for connecting with others who are interested, and for forming a seed from which a local network can grow, it relies on another network to exist. The ultimate goal is to create a net which will not fail if the internet does.
+
+<div class="mermaid">
+    graph LR;
+        A(Local node)--\>|wireless lan cable|B(Other local node);
+        B--\>A;
+</div>
+
+**NOTE**: If you're viewing this on a web page which does not include [mermaid.js](https://github.com/knsv/mermaid), you'll just see some weird text. For an example of how it **should** look, see it in [its original context](https://docs.meshwith.me/en/meshlocals/intro.html).
+
+## What if physical peering is out of the question?
+
+If you're located somewhere extremely remote, you don't have to count yourself out of the picture. Try to gather some resources for a meshlocal anyway, as you might be pleasantly surprised to find someone nearby despite what you may have thought. That means letting people know that you're working on it (at least for yourself).
+
+Read as much documentation as you can, and familiarize yourself with the software so that if someone does contact you, you have some knowledge to share. If you find any documentation that's unclear or misleading, get in touch with us and help to [write the fine manual](http://roaming-initiative.com/blog/posts/wtfm).
+
+Finally, ask around for someone willing to peer with you despite the distance, but be patient. As time goes by and you find closer peers, disable the connections to those who are further away.
+
+## About Wifi tuning
+
+Antenna directionality, Signal to Noise ratio, beamforming: http://apenwarr.ca/log/?m=201408#01
+
+A guide to tuning your wifi for adverse conditions: http://kmkeen.com/linux-wifi/

doc/notes/arc-workings.md

@@ -0,0 +1,137 @@
+# Random details of cjdns' inner workings
+
+ansuz' notes of a Q&A with Arceliar
+
+## Probability of IPv6 address collisions
+
+Or the math behind the birthday problem RE: cjdns
+
+*Ansuz:* I remember that it was something like 1/10^18, and I remember the basic expression to derive that, but you had some fancy trick that got around the combinatorial explosion
+
+*Arc:* Do you want the number of nodes before there's a >50% probability of a match? 1%? 0.1%?... I know there's a general formula for this, or at least a damn good approximation of it. Give me a min...
+
+*Ansuz:* awesome, yea, maybe the method of how you calculate it efficiently. Maybe I could put it into javascript on a webpage so people can play with those values?
+
+*Arc:* Found it: (looks like it's also on wikipedia!)
+
+- n = number of nodes needed for this set of probability and keyspace size. Note that this is the - nodes needed for there to be *any* match *anywhere*... *your* node is almost always afe-
+- p = probability of a match-
+- d = number of possible add- resses (keyspace size)-
+- ~= = approximately equal to (for sufficiently large values of d, which is definitely not a - problem)
+- n ~= sqrt(2d * ln(1/(1-p)))
+
+And some specific numbers for cjdns: (d = 2^120, because 8 bits are taken up by the leading fc. Note that the range of a sha512sum might not cover the full keyspace for all we know, though I would be very surprised if that were the case... but it's technically an open problem AFAIK)
+
+- n(0.1%) = 5.15731 * 10^16
+- n(1%)   = 1.63458 * 10^17
+- n(50%) = 1.35746 * 10^18 ('birthday problem' answer)
+
+If you want to see a plot of number of guesses needed (y-axis) to have a probability (x-axis) of there being at least one collission in the network, then punch this into wolfram alpha:
+
+- y = sqrt(2*(2^120)*ln(1/(1-x))) from 0,1
+- *Ansuz:* I'm assuming 1 == 100%, right? (On the x-axis)
+- *Arc:* Yes, it does
+
+> \<ansuz> +lotto
+> \<mg2bot> 1 in 1,329,227,995,784,915,872,903,807,060,280,344,576 chance of generating the same IPv6. Feeling Lucky?
+
+*Arc:* And that gets you the chances of anyone guessing a key that gets them *your* IP. Even if they do, that doesn't mean its your key, so your traffic is still safe... it just means they can impersonate you (which would probably cause crazy things to happen to the routing logic, we should give two peers the same key just to test that...)
+
+Ansuz: A common problem I've noticed is that we store our information on IRC  bots that sometimes die. and a snippet like +lotto doesn't really  explain anything.
+It's just a huge issue that these things get figured out, and then forgotten. and people are supposed to just trust some irc bot that everything is secure.
+I'm trying to gather up all this info and put it in a better format, and mirror it all over the place (sync'ed with rsync/git atm)
+
+## About XOR distance and finding nodes
+
+Ansuz: I've heard that cjdroute remembers nodes with similar xor values. randati is using this for fc00.org - generating new nodes to help expand his routing table.
+
+Arc: At least on crashey, it's probably easier to make the size of the node store larger in dht/dhtcore/NodeStore.h -- just add a 0 to the nodestore and linkstore sizes at the top. I have done both to find as many nodes as possible
+
+there's a patch set that will probably be pulled in a few days, which changes the way crashey decides which nodes to search for. in theory, giving it a nodestore size larger than the network should eventually find every node...
+
+Ansuz: so I'm curious if this is true, and maybe if we're making a meshlocal people will be able to route better if they have a closer address?
+
+Arc: I'm not sure how this affects (if it does at all) who we should be peering with...
+Speaking about crashey, as things have changed quite a bit from how they were done in the old pathfinder... (old pathfinder found routes at random, stored ~all of them. in theory it had to discard them somehow if it was full but i don't know how, as i never got close to full...)
+Nodes make it into our routing table one of two ways. Both are steered from dht/dhtcore/Janitor.c for the most part.
+
+1. When we discover a new node (direct peer, mentioned in a search result, etc) we add the path to them to a list of possible nodes called the RumorMill. Once per second, we send a getPeers request to a node from the RumorMill. If the mill is full, we discard the 'worst' one, where badness is defined mostly in terms of how far they are from us in physical space (that is, how long their path is), so this method gives us a picture of the part of the network physically close to us (starting with our direct peers and branching outward).
+2. Every 30 seconds, we perform maintenance actions in the janitor that deal with the xor keyspace stuff. We identify the furthest possible address from us (in terms of keyspace distance) to which we do not know of a valid next hop, and search for it. Read up on the Kademlia DHT if you want to know more (there's some implementation details in this document, but it's probably the most approachable beginners guide to kademlia that i've ever seen: https://github.com/telehash/telehash.org/blob/master/dht.md ). We don't do exactly the same thing (no k-buckets, slightly different implementation details) but the basic idea of an xor-based distance metric and identifying holes by organizing things bitwise is basically the same.
+
+Finally, about the nodestore in the crashey branch. It now has a size that's small enough that we don't just keep the entire network in memory (it's 128 nodes by default now, and we have ~500-ish on hype last time I heard). So if the nodestore is full and we discover someone new, we evict the worst node. The details of how "worst" is defined are kind of complicated. It first looks at the set of nodes that are unreachable, and selects the one furthest from us in keyspace (by the xor metric). If no nodes are unreachable, it looks at the nodes that have no children (that's a nodestore thing, basically... nodes that aren't an intermediate hop on the best path to any other known nodes) and it evicts whichever one is furthest in keyspace.
+
+Somewhat related... in theory, people in the same meshlocal could deliberately brute force addresses where the most significant bits in keyspace are a match (that is, that are close together). If somene outside the meshlocal doesn't know a route their destination inside it, but does happen to know of another node somewhere in the meshlocal, then they'd generally forward it to the right meshlocal at least. But I wouldn't advise actually doing this--it *shouldn't* be needed, so doing it now could actually hide any bugs in the current DHT logic and make things worse in the long run. (Also, for reference, addresses are rotated 64 bits before being xored. I have no idea why cjd decided to do this, as it makes distance calculations kind of annoying, but there you go. If ever we make a backwards incompatible change, I'm going to lobby that we take the opportunity to drop the 64 bit rotation. If the problem is the leading fc, then we should just do a bitwise reversal of the whole thing, to put the fc at the last position where it will never show up in a... ~thousand years of use)
+
+Ansuz: lol, oh so every address would end in cf? or that's a hash.. so maybe not?
+
+Arceliar: Addresses would still start with fc. right now, before we xor, we basically swap positions of the first and second half of the address, to keep the fc away from the first few bits because the DHT would hate that. My point is, if that's what we're worried about, we could keep the same addresses but flip them (so it would look like it ends in... not cf but whatever the bitwise reverse of fc is) (its.. 03) right before we xor. Nobody outside the cjdns code base would have any idea that this happens. It would just be slightly less confusing to work around than a 64 bit rotation... that or we chop the leading fc off of things before calculating anything. Implementation details, don't worry about it.
+
+Ansuz: I was going to say we could make a script based off of:
+
+~~http://ansuz.syrinxist.org/share/ArceliarAMA/vanitygen.sh.txt~~
+
+https://wiki.projectmeshnet.org/Tips_and_Tricks#Picking_a_memorable_IPv6_address 
+
+but if it's gonna mask bugs I won't bother
+
+## Best number of peers to have?
+
+So far I wrote this: 
+
+~~http://ansuz.syrinxist.org/faq#architecture~~
+
+http://ansuz.transitiontech.ca/faq#how-many-peers-should-i-have- 
+
+but I'd love to have some facts to back it up
+
+"if you're on a laptop that you travel with, you probably don't want to  route for people. For instance, if you occasionally tether your phone,  you might accidentally run up your data bill if you aren't mindful of  the traffic you are routing. In such a case, keep only one peer, and you  will never be a path, only a leaf node. "
+
+Arceliar: That's not entirely true... your switch won't have to forward packets, but your router might. For example, if I'm trying to DoS reptoidz, but don't know a route to his IP, I'll forward the packets to whoever is the closest node I do know. If that's your tethered laptop, then you'll be asked to forward the packets. (This is how kademlia, and DHTs in general, usually work). One of the things on the to-do list is to come up with a *good* way to do a router lookup instead of blindly forwarding. So instead of forwarding the packet to you, I'd ask you if you know a route to reptoidz. I'd use this to produce a switch route that goes through you, but I'd notice the loop and splice it out. So you wouldn't end up forwarding any traffic, just answering DHT lookup requests. (Actually, that lookup would probably happen in parallel, in the background, while I blindly throw packets in your direction to be forwarded. I'd just stop asking you to forward them if/when I get a useful response from the DHT lookup. Note that crashey briefly *was* doing this, but it was using a CPU-and-bandwidth expensive search request. I can think of better ways to do this, but the "right" one would require addressing other problems first...)
+
+The rest of the peering advice looks in general good. My only real comment is that leaf nodes (above) can't do useful routing at the switch level, and forwarding traffic at the router level is slower so we'd like to avoid it when possible. Having 2 peers lets you do things at the switch level but it's not especially useful (those guys could just directly peer instead, unless they're physically out of range in a meshlocal of course, in which case you're doing good). So 3 is the minimum number of peers before your switch actually gets to make non-trivial decisions about where to route packets. So if you're someone who wants to help the network, I'd say 3 peers (preferably ones that are not already peered with eachother) is the minimum I would shoot for.
+
+<3 peer review
+
+## Also:
+
+Randati: I want to start doing analytics on the network based on
+### what is the optimal ratio of nearby nodes to far off nodes? http://en.wikipedia.org/wiki/Small-world_network
+depending on what type of node you have (mobile/home/VPS)
+Having some kind of API to pull information of the network might be useful.
+
+also: I've been playing with sigmajs, but d3js.org looks like it has some really useful stuff
+http://christophermanning.org/projects/building-cubic-hamiltonian-graphs-from-lcf-notation/
+
+## Are there any other types of nodes I haven't addressed?
+
+```IRC
+damn, u the best Arceliar <3
+
+I'm reading through the whitepaper now,
+
+<ansuz> ping for fixing routing: probably not magic
+<ansuz> probably not placebo
+<ansuz> Arceliar, what's your opinion on the matter ^^
+* Arceliar reads scrollback
+<ansuz> Alice can't find bob by browsing, Bob blasts pings at Alice, helps Alice find Bob
+<ansuz> -> starts working
+<Arceliar> ah
+<ansuz> as in, generic network traffic to encourage peer discovery
+<Arceliar> yeah. when alice receives a ping, she sees it's to a node that she doesn't have on her routing table yet. so she adds that node and the return route for the packet to the routing table.
+<Arceliar> i think something approximating that happens. may have changed during crashey.
+<ansuz> http://couch.syrinxist.org/share/fuck-yeah-l.png
+<Arceliar> right now the network depends a lot on forwarding. if neither alice nor bob have the other on their routing tables, then never find eachother (unless it's by accident) and just depend on the DHT to handle routing
+<Arceliar> if the DHT has problems (e.g. all the old nodes that haven't updated yet) then forwarded packets may vanish into a routing blackhole
+<frozen> ansuz: that image is as large as it is to troll, isn't it.
+<ansuz> lol
+<ansuz> maaaaybe
+<ansuz> umadbro?
+...
+<Arceliar> ideally, when we forward traffic, we'd keep the switch label from previous hops. so Alice->Eve->Bob would arrive at bob with Alice<-Eve and Eve<-Bob return labels attached, and Bob could splice a full route to Alice.
+<Arceliar> but to do that, we first need to be able to stack switch labels (which we need to do anyway because 64 bits won't be enough if there's 10 billion nodes in the network)
+
+<Arceliar> if Bob knows the Bob->Eve and Eve->Alice routes, he can splice Bob->Alice. but he's currently too stupid to ask for Eve->Alice.
+<Arceliar> and Eve is too stupid to include it in case he'd find it useful
+<Arceliar> at one point I had it set up so if Alice didn't know a route to Bob but tried to send a packet to him, she'd also trigger a search for him. which would get her a route. but it killed performance.
+<Arceliar> i mean... Alice would find a great route, but tons of spammed searches everywhere, so it wasn't worth the cost
+```

doc/notes/cjdns-core.md

@@ -0,0 +1,70 @@
+# Cjdns Core Notes
+
+## Introduction
+
+A number of us have begun the task of documenting and reverse engineering the cjdns core. The "core" refers to the core functionality required to implement a cjdns-compatible router.
+
+To speak with those involved, join **HypeIRC/#documentation**
+
+## Status
+
+ansuz has re-implemented the [xor metric](https://github.com/ansuz/cjdnsjs/tree/master/scripts/xor) and [key generation process](https://github.com/ansuz/cjdnsjs/tree/master/scripts/keys), along with the support functions involved, notably the implementation of Base32 used by cjdns.
+
+[jph](https://hackworth.be/) is experimenting with writing a minimal, linux first implementation in golang, along with deconstructing everything involved in making that happen. He is also investigating TUN support in other languages (notably Python and ocaml).
+
+**Note to contributors**: 
+
+* If you think of additional core functions to document, please add them below  
+* Please provide either pseudo-code or working code examples inline. Longer code examples should be linked to, and preferably hosted on gitboria
+
+# TUN device support
+
+## Overview
+
+Cjdns uses [TUN devices](https://www.kernel.org/doc/Documentation/networking/tuntap.txt) to create a virtual network interface and enable routable peer to peer connections. Therefore, TUN support is a critical requirement for implement a cjdns router. 
+
+At this time, the following languages have built-in or third-party TUN support:
+
+* C
+* Golang
+* Python
+* Ruby
+* Ocaml
+
+Please note that "TUN support" may not have the full functionality required by a cjdns router. As this section is expanded, we will describe what that functionality is.
+
+In addition, be aware that TUN implementation varies across operating system implementations. Multiplatform router implementations need to keep this in mind.
+
+## Creating a TUN device
+
+TBC
+
+## Configuring a TUN device
+
+TBC
+
+# Cryptography
+
+Cryptography provides core functionality within cjdns. [Here](cryptography.md) we will describe some of the cryptographic functions performed within cjdns and implementation details.
+
+## Public Keys
+
+* Cryptographic algorithms required
+* Creating a private/public key pair
+* Encoding private/public keys into a string
+* Decoding private/public keys from a string
+* Format for sharing public keys (peering credentials)
+
+# Utility Functions
+
+Instead of relying on external libraries, some utility functions have been re-implemented within cjdns. We will describe those functions that differ from standard implementations to ensure compatibility with existing cjdns routers.
+
+## JSON
+
+cjdns config files are typically stored as what the community often refers to as [cjdson](https://github.com/cjdson). As [finn](https://github.com/thefinn93) has pointed out, [comments](https://commentjson.readthedocs.org/en/latest/) [in json](https://www.npmjs.com/package/strip-json-comments) are [not unheard of](https://www.npmjs.com/package/json-comments).
+
+In any case, we're going to try to add some functionality to that repo that the others lack, such as _inserting fields without deleting comments_.
+
+## Base32
+
+[This Javascript library](https://github.com/ansuz/cjdnsjs/blob/master/scripts/keys/cjdb32.js) is a direct translation of [the cjdns base32 encoder written in C](https://github.com/cjdelisle/cjdns/blob/master/util/Base32.h#L109)

doc/notes/cjdroute-conf.md

@@ -0,0 +1,71 @@
+# What does everything in your configuration file do?
+
+If you've never worked with [JSON](http://en.wikipedia.org/wiki/JSON) before, you might feel a little overwhelmed editing your  **cjdroute.conf** for the first time.
+
+One thing that makes matters more difficult is that your cjdroute.conf is **not** actually valid JSON.
+
+This document will:
+
+1. Indicate the exact purpose of each attribute of your configuration file.
+2. Document the permitted and recommended syntax you can use, and the difference between the two.
+3. Indicate which attributes are required, and which are optional.
+4. Refer to related documentation about specific attributes, and the surrounding recomended practices.
+
+## Structure
+
+* privateKey
+* publicKey
+* ipv6
+* authorizedPasswords
+  + password
+  + ipv6
+  + user
+* admin
+  + bind
+  + password
+* interfaces
+  + UDPInterface
+    + bind
+    + connectTo
+  + ETHInterface
+    + bind
+    + beacon
+    + connectTo
+* router
+  + interface
+    * type
+  + ipTunnel
+    * allowedConnections
+      + publicKey
+      + ip4Address
+      + ip6Address
+    * outgoingConnections
+* resetAfterInactivitySeconds
+* security
+  + setuser
+  + exemptAngel
+* logging
+  + logTo
+* noBackground
+* dns
+  + keys
+  + servers
+  + minSignatures
+
+## Functionality
+
+### privateKey, publicKey, ipv6
+
+As indicated in [this article on cjdns' cryptographic functions](cryptography.md), your ipv6 is derived from your publicKey, which is in turn derived from your privateKey.
+
+**cjdroute --genconf** produces a sample configuration file which includes all three, but they are not all actually required to launch your router.
+
+Instead, cjdns only uses your privateKey, then derives the rest. As such, the publicKey and ipv6 are only there for your benefit.
+
+### authorizedPasswords
+
+This is an array of objects. Each object can contain a number of keys that specify how that password is to be used:
+
+1. "password" specificies a password that your node will accept as valid. It's recommended that each peer be given a unique password. Without a valid password, a peer will not be able to connect.
+2. "ipv6" specifies which ipv6 can be used in conjunction with a particular password. Additional nodes attempting to connect using the same password and a different ipv6 will be rejected.
+3. "user" is an optional label which must be unique among passwords in your configuration file. It has no effect on peering, otherwise, but is used to label connections when using the peerStats API call. This human readable format makes it easier to determine how each of your peers is behaving, and whether they need to update.

doc/notes/cryptography.md

@@ -0,0 +1,45 @@
+## Private Keys
+
+* Private Keys are represented internally as 32 element Uint8 Arrays.
+* Represented in text form as 64 digits of hexadecimal.
+* cjdns does not currently require anything more than the private key at launch time. It derives the public key and ipv6 after loading the private key to avoid errors.
+
+## Public Keys
+
+* The public key is entirely dependent on the privateKey.
+* Represented internally as another 32 element Uint8 Array.
+* Represented in text form as a 52 character string of [cjdns' base32 encoding](https://github.com/ansuz/cjdnsjs/blob/master/scripts/keys/cjdb32.js).
+* cjdns base32 consists of the following characters:
+  + 0123456789bcdfghjklmnpqrstuvwxyz
+* Any string matching the following regex is **invalid** cjdns base32
+  + /[^0-9b-df-hj-np-z]/
+
+## IPV6 Addresses
+
+* An ipv6 is the hash of the hash of the public key, encoded in hexadecimal, and trimmed to the first 32 characters, with colons inserted between every two byte section.
+
+## Passwords
+
+* Password are (nearly) arbitrary text strings.
+* Their length is variable.
+* There are only a few banned characters:
+  + newlines (\n)
+  + quotation marks (")
+  + backticks (`)
+  + backslashes (\)
+  + spaces ( )
+  + tabs (\t)
+  + curly braces ({,})
+  + `<@cjd> be careful of non a-zA-Z0-9_`
+* There may be more invalid characters, please let us know if you find any!
+* They can be generated in bash with the following one-liner:
+
+```Bash
+cat /dev/urandom | strings | head -n 50 | tr -d '\n"`\\ \t'  | head -c 50 && echo OR tr -cd '[:alnum:]' < /dev/urandom | fold -w32 | head -n20`
+```
+
+* On OpenWrt, the following shorter one-liner is used:
+
+```Bash
+tr -cd 'A-Za-z0-9' 2> /dev/null < /dev/urandom | head -n 20
+```

doc/notes/dns.md

@@ -0,0 +1,513 @@
+# Random notes about cjdns and DNS
+
+by the incredible ansuz
+
+THIS IS AN ETHERPAD Meaning you can just write stuff in if you want. Try not to delete stuff, feel free to add try to respect the overall structure, but it's backed up anyway if you go ruining shit, you aren't really doing any damage, just being immature. KTHXBAI
+
+PS: IF YOU WANT TO GET CREDIT FOR ANY INFO YOU ADD, PUT YOUR NAME BESIDE IT. EVENTUALLY I WILL CLEAR AUTHORSHIP COLOURS FROM THIS DOC, AND ATTRIBUTION WILL BE IMPOSSIBRU
+
+IMHO hype is in need of 3 things
+
+- Docs  http://couch.syrinxist.org:9001/p/docs && http://couch.syrinxist.org:9001/p/howCjdnsWorks && http://couch.syrinxist.org/faq
+- easily deployable email, since there are obvious problems with having it centralized, it needs to be easier for the user to host (specifically on hyperboria) I am hopeful about http://haraka.github.io/ and https://github.com/andris9/simplesmtp .. though again, a clear guide to setting up dovecot/postfix/whatever on hype would also be satisfactory. Eventually I plan to make something out of simplesmtp for myself (probably over the summer), and I'll be releasing it. Unless someone else does it first... HINT. oh and by easy I mean like run a script and log in. srsly.
+- DNS.. see below
+
+## DNS on hyperboria/parabolic/any cjdns network
+
+### What is this about??
+
+the curator of hyperboria's "hypeDNS" has gracefully retired from Hyperboria, leaving DNS in a state of transition.
+
+Now might be a good time to actually figure out how we're going to move forward.
+
+### Existing/competing services
+
+(what do people think of pros/cons?)
+
+- ICANN (by the NSA) # The DNS you already use, provided by clearnet
+  - h.example.net for hyperboria, example.net for clearnet
+  - doesn't work well with CNAME records, since they get used for AAAA resolution too
+    - `pad.meshwith.me.  227  IN  CNAME  dax.meshwith.me.`
+    - `dax.meshwith.me.  227  IN  AAAA  fcc6:700e:1577:b2df:20cc:3ece:24ff:3fa7`
+    - `<larsg> should remove those CNAMES`
+    - `<larsg> they apparantly get used for AAAA lookups too`
+    - `<larsg> that's how pad. resolves to 3fa7`
+    - `<larsg> finn: i mean CNAME records for domains which also have a h. variant, in general`
+    - `<larsg> because due to the CNAME with an AAAA record on the other end, the clearnet variant is not clearnet anymore`
+- hypeDNS (formerly by Mikey, now by finn) # conventional dns, centralized, only on hype
+- paraDNS (by sdamashek/wolfmitchell) # central to the parabolic [sub]network, also conventional DNS, also only on hype
+  - http://couch.syrinxist.org/dns
+- rainflyDNS (ironically, by cjd) # built off of namecoin? integrated into cjdns. development (seemingly) halted # correct me if I'm wrong.
+  - https://pad.meshwith.me/p/rainflydns #thx
+  - http://gitboria.com/cjd/rainflydns/
+  - http://rfdns.cjdns.ca/
+  - https://ezcrypt.it/ck5n#gYdfOeREHwzD92H0WDry4Z5e
+  - https://ezcrypt.it/9Q6n#ejSF9d762REt7hmJ8pl46yp7
+- DJDNS   (ironically, by rainfly) # maybe a good idea? idk. not widely adopted, written in Go, so I'm not fond of it.# just trolling.. kinda..
+  - https://github.com/campadrenalin/djdns
+  - There's also https://github.com/campadrenalin/python-djdns
+- raw ipv6 webring? (by anyone who wants to get involved) # just post links to things that people ought to be able to find. doesn't really scale well, basically just word of mouth.
+  - advertised services using DHT? Hypertary? (by Igel? Frozen? idk) # My understanding of this is shallow at best
+- GNUNet Name System
+  - https://gnunet.org/taxonomy/term/34
+  - https://www.youtube.com/watch?v=uhIybhAQ8lY (30c3 lecture)
+  - https://gnunet.org/sites/default/files/schanzen2012msc.pdf (masters thesis proposing GADS) (read this if you need to kill an afternoon)
+- .p2p (from TPB people) - http://p2pfoundation.net/Dot-P2P http://dot-p2p.org
+- http://couch.syrinxist.org/share/dns-idea.txt #ircerr's idea
+
+### proposed/extant TLDs...
+
+- .h # nice and short
+  - confusing when we consider that cjdns is heavily related to C
+- .hype # very descriptive, has some history, but isn't widely adopted
+- .para # has been adopted by 100% of parabolic, which isn't many people, but that's something, seems to be run with pride.
+- .mesh # also descriptive, makes for nice vanity urls... seattle.mesh, toronto.mesh, etc.
+  - is potentially bad because we are not the only mesh network # fuck da police, also, if it's internal to hyperboria it shouldn't affect anyone (assuming the links posted are also internal) # if other meshes are using ICANN, they are ostensibly doing it wrong. but then.. so are we.. soooo yea
+  - .net # because why not go full troll mode (this is not a serious suggestion) <3
+- ????  # idk, propose something yourself
+- should/could be descriptive of what the site is for, such as .mail, .forum, .blog, .wiki  // there's the issue of 'poisoning' the namespace. eventually when clearnet increases the number of TLDs hype users might not be able to access clearnet sites. If they have to migrate a hype domain they've had for some time to something new because of an ICANN conflict, they'll be pissed. Hardlinkes are hard to get rid of. I'm in favour of having fewer hype TLDs (until we need more) to avoid this complication.
+
+
+## What is our future dns solution going to look like?
+
+seriously, if we keep waiting for something perfect, we will have too many competing services to get people to adopt 'the perfect option'
+
+I'd like to start with anything now, get it adopted, then improve it. Premature optimization kills lots of great ideas. DNS is very important, and I want it to work.. as in, NOW.
+
+### missing:
+
+Why exactly DNS is important (people don't really care about it even on clearnet, see google).
+
+- we don't have a search engine, and it's not possible to crawl blindly // we have http://[fcd6:e9a6:a7be:b875:edd7:dc39:abac:a1c7]/ <- Oscar, and jph might be working on something based off of elastic search, also, derp might have something on the way Also you can run YaCy and crawl things locally, and we could probably set it up to share over a hype-only YaCy DHT (that's how it works), but it's kind of a bitch to get it to crawl only IPv6/Hype addresses because of how it parses regex (badly) # Last I heard YaCy wasn't working on IPV6...  NVM http://ipv6-yacy.blogspot.ca/ .. even mentions hyperboria, is this from Vadipp?
+
+Why a number of competing services ("healthy ecosystem"?) is bad. // bad like freedom, not beer
+
+- user has to run too many servies and configure too many things; it's hard to see what's going on
+
+These qualities listed below would all be nice things to have however, some of them might not be compatible with others. we need to prioritize them, and possibly decide which should be abandoned
+
+- it should be memorable ( if it's going to be a big string of crap, we might as well just use raw ipv6s)
+- it should be distributed  ( at least to the point that no one party can abuse their position, mutually assured destruction is a similar option, unless all parties have a common enemy to abuse (not good), all governments hate anarchists)
+- it should be internal to the network (to whatever extent possible), not much point in having our own network if our browsing history gets sent to clearnet (and if clearnet fails, hype should keep going, hype is all about RESILIENCY)
+- it should be simple for the user ( or else no one will use it, this means having a clear set of specs, so devs can work with different languages without dividing users)
+  - it should somehow provide cryptographic proof of identity ( because if we don't have CAs, we need to somehow do it for ourselves)
+  - maybe we should look into existing CA-alternative systems that have been proposed?
+- it should integrate trust and allow the user to decide, again, NOT relying on a CA or other authority
+- if possible, it should be based upon existing technologies to speed/ease adoption
+
+I'd like to see a proposed flow of how the user would...
+
+- install it ( this shouldn't take more than 5 commands, or even better, it should have a graphical installer or clickable script)
+    - excluding compile times, of course
+- use it in their browser ( it should NOT require any plugins, and should work identically in every browser, or from the command line (wget/curl))
+    - so it needs system integration in some fashion
+- sign up for/generate domains ( if signups are required, we should have a simple API or web interface ( hopefully in a language we all agree on (OR Language agnostic)))
+
+Would it be possible to have it be a part of cjdns? eg one less step to use? // it kind of is, RAINFLYDNS, but the servers aren't running yet. We have 4 people running them, the system requires the cooperation of 13. If 8 others want to volunteer, I am willing to be the fifth. cjd gave his 'seal of approval'.
+
+- That being said, conventional DNS (A LA hypeDNS and paraDNS) is not difficult to set up. I've detailed the way to do it http://couch.syrinxist.org/dns <- here for paraDNS
+- When HypeDNS comes back online (supposedly on the weekend when finn isn't in school), I will add instructions for that.
+- It's literally 3 commands (at least on Debian/ubuntu/mint/arch).
+- I am willing to list instructions for OSX or other linux distros, but I am only able to test instructions on distros I run.
+- If you figure out how to do it on anything else, let me know and I'll list it.
+
+it was proposed (by prurigro) that an address be somehow based upon the owner's cjdns IPV6
+
+- a 7 (or N) character string would be a part of your domain, and could not be spoofed.
+- it would provide proof (perhaps optionally, like https) that a person is who they say they are (provided you know their IP, and actually bother to check)
+- The issue with this is that if it is your TLD, then we don't have a memorable ending..
+- in fact, no matter where it is, it probably isn't memorable, but it would be fairly secure, and would not depend on a certificate authority AT ALL.
+- thusly, an address might look like: ansuz.lkj3ijg or kljdf23.ansuz
+- might just be me, but these aren't memorable AT ALL
+- I don't think it's just you. I'd only be interested if the crypto-hash were optional like https
+
+this method could be offered IN ADDITION to the others. MAYBE:
+
+If you lose your conf, though, you lose your domain, which kind of defeats the purpose of a domain as an abstraction from your raw address.
+
+- cryptoProof.Owner.local.mesh
+- ijdsgl2.ansuz.toronto.mesh ??
+- ansuz.toronto.mesh # assuming you're confident you don't need the crypto-sign, like https (but without the heartbleed)
+
+To what extent should it be linked to cjdns?
+
+- having a dns module be an inherent part of cjdns means it should (in theory) be faster than alternatives.
+- it would also be nice for it to come ready to run, having to install ANYTHING hinders adoption
+- on the other hand, if the included dns is crap, everyone might use it just because it's there, then we'd all be using crap. that would suck.
+- I'm in favour of modularity, but we need to consider all of our options IMHO
+
+## jackv's DNS ideas
+
+(just dumped here for lack of a better way of communicating them)
+
+- The problem is not how we do DNS, it's how we know who to trust. Once we know that a node can be trusted, we can trust any traffic coming from it to be authentic, thanks to cjdns
+  - Thus, we don't need to reinvent the wheel when it comes to DNS protocols, we just need to make cjdns smart enough to find trustworthy DNS servers
+- In a global mesh, it's obviously hard for one host to serve all of the domains in the world
+  - The idea about each meshlocal having a second level domain is good, thus "toronto.mesh" or "sandiego.mesh"
+- Not everyone needs to run a DNS server, but it needs to be easy enough that anyone *could*, given the resources neeeded
+  - Many (or at least a good number, proportional to size of meshlocal) DNS servers per meshlocal, but all serving the same records (ostensibly)
+- The basic principle is that all DNS server nodes should be able to communicate and share records with each other fairly frequently, thus allowing DNS to propagate in a decent amount of time (nobody likes waiting for things like DNS propagation)
+- All normal cjdns nodes should be able to communicate and share a list of active DNS servers to query
+- A DNS server is set up for a single second level domain (eg sandiego.mesh), many DNS servers are set up for that same domain throughout the meshlocal
+- A person can register a third level domain for an active cjdns address (eg jack.sandiego.mesh)
+  - The relationship between domains and addresses should be one-to-one
+  - The address should be queried on a regular basis. If it fails a certain number of times in a row, it should be labeled as defunct, and made available for open registration. This is done to accomodate small amounts of downtime, while making sure that every address is being maintained, preventing abuse
+- A cjdns node should attempt to resolve a random sampling of domains for every name server that it knows about (obviously only .sandiego.mesh domains for a sandiego.mesh nameserver)
+  - Each DNS server should probably serve a dump of all the domains in its database, maybe at the meta-domain "sandiego.mdns"
+- Both the records that each nameserver serves and the nameservers that each node queries are based on whether a particular DNS node seems trustworthy
+  - If the records it's serving are similar enough to the records of other DNS servers for the same "sandiego.mesh" range, then a node can be considerd trustworthy
+- One of the biggest problems comes with the updating of domains, because this creates apparent inconsistencies (also, we don't want people hijacking a domain easily)
+
+Possible Attacks
+
+- Assuming that a majority is defined as 51%, then a 51% attack is a good way of attacking this structure, however, the term "majority" could also be defined as a higher numbe
+In the bitcoin/cryptocurrency world, a pool with even around 40% could still do some damage
+  - A minority attack would essentially just serve to impede the flow of accurate records, however the protocol should be smart enough to not get poisoned
+- A node with very few peers could be fed a false list of nameservers, thus causing it to serve a bad list as well
+  - This could be fixed by making name server information shared by more than just your peers
+  - Also, if you're peering with bad nodes, DNS poison is only one of the problems you'll have
+- One nameserver getting hacked isn't a huge deal, assuming there are a decent number of name servers for the same domain
+
+Improvements
+
+- Figure out how to update records
+- Figure out how to use the crypto-proof idea (f4jl34m.jack.sandiego.mesh)
+
+
+
+## discussion from hypeIRC/#webdev (edited and organized) // Kinda
+
+```irc
+
+<ansuz> finn and I were talking about setting up dns for every meshlocal
+<ansuz> maybe changing .hype to .mesh
+<ansuz> so like, pad.toronto.mesh
+<ansuz> pad.seattle.mesh
+<lukevers> pad.internet.mesh
+<ansuz> rainflydns never happened
+<lukevers> dns is hard
+
+<ansuz> [parabolic] have 100% adoption of paraDNS
+<ansuz> if we merge that with hype records, we might have something useful, I see no reason not to
+<ansuz> and then eventually if we make something else, we can migrate all those records to it in one go (or just mirror them)
+<ansuz> something distributed, maybe?
+<qmx> lukevers: dns isn't hard, as long as you're fine with status quo
+<qmx> (centralized)
+<qmx> hypedns isn't viable
+<lukevers> yeah centralized is kind of an easy concept
+
+<qmx> rainfly won't fly
+
+<lukevers> decentralized is more what I meant
+
+<Igel> hey thats a kick in the nuts
+<Igel> if its a 2 year+ think , but the way i saw it and it was described to me
+<Igel> the docs distributed arent just quad records, they are arbitrary in his own words
+<Igel> think of some examples, eg; bitcoin addy, gpg prints
+
+<qmx> I still think we need to just have nodes advertising services over a dht discovery mesh
+<Igel> #Hypertary
+<Igel> workin on it
+<Igel> (soon)
+<qmx> and let gpg WOT assure I am qmx # WOT == web of trust
+
+<ansuz> I'd really like it if we could just all use something, whatever it is
+<ansuz> so that there's progress, instead of competition
+<ansuz> not to say that they're mutually exclusive, but..
+<ansuz> we shouldn't have to use 3 dns services to access all the records
+<ansuz> I have more servers than I have things to host
+<ansuz> I'll install whatever people think is best and help mirror it
+
+<derp> we need open protocols, decentralizing everything only works if people actually use it. go lower, decentralize the procotol and let a user decide to self host or use a hosted service
+<derp> ironically, its the chicken and egg problem. We want users, but users expect services. How do we attract and retain users? Making them host everything themselves?
+<derp> the real beauty of cjdns is it solves network neutrality
+<derp> assuming we don't impose some crazy HOCNET shit
+
+<ansuz> I don't think everyone should have to serve dns records
+<ansuz> we don't have to go 100% distributed
+<prurigro> ansuz: so disapora-decentralized
+<qmx> ansuz: if you use a dht you can have a lite dns client and some nodes host the full dns
+<ansuz> but like, such that no one is in charge, I think that's what cjd was getting at with the nmc thing
+<qmx> ansuz: akin to multibit-bitcoin and bitcoind
+<ansuz> qmx, prurigro, yea
+
+<ansuz> we should have a hype tld, .mesh, .hype or something
+<derp> ansuz, cjd's nmc thing is way to hopeful. Its like he read Richard Stallmans dreams, but yeah, we need something *realistically better than the status quo*
+<prurigro> qmx: when did he propose that? his earlier ideas were more like bitcoin, with power in numbers
+<prurigro> (in terms of signage)
+<prurigro> oh hm, yeah, that doesn't sound open
+<qmx> prurigro: distributed but not that much
+<prurigro> one person getting hit by a bus should not be the end of domain names
+<qmx> prurigro: you would register via nmc
+<qmx> prurigro: then his rainflydns signs the record
+<ansuz> yea, that's silly
+<ansuz> there's issues with nmc anyway
+<ansuz> like changing records
+<ansuz> centralization means you don't wait so long for things to propogate
+
+<ansuz> local meshes should have something else
+<ansuz> toronto.mesh
+<ansuz> then toronto.mesh should issue ansuz.toronto.mesh
+<ansuz> and host all the toronto records..
+
+<derp> what about for the clearnet?
+<derp> do you also plan to have a clearnet site for the meshlocal?
+<ansuz> well, to attract new folks, you need a front porch
+<ansuz> I use clearnet.syrinxist.org for that
+<ansuz> but I'm gonna get something more obviously mesh related in the near future
+<ansuz> starting to get toronto people somewhat involved this summer
+
+<ansuz> I think this would be our best option, though
+<ansuz> let local meshes deal with their own local users
+<ansuz> if toronto.mesh goes offline, those people lose their records, unless they've made backups and are prepared to make the new service
+<ansuz> (which should have a git or something)
+
+<ansuz> centralization with redundancy is okay
+<ansuz> I think
+<ansuz> blockchains bring a lot of overhead
+
+<qmx> ansuz: not for this thing
+<qmx> if we can't have something fully decentralized, then just use standard DNS
+<prurigro> I always thought a subscription model would make sense
+<ansuz> that's what I'm saying
+<ansuz> you want to use the toronto namespace? subscribe to torontoDNS
+
+     ## my thought here is that ultimately we don't REALLY want to create services on hype for the whole planet to use..
+     ## our primary concern should be our meshlocal users, since that's what project meshnet is really about.
+     ## latency adds up over many hops, there's still black-holes..even if that goes away, there's bandwidth overhead to not browsing locally
+
+<prurigro> people register with proejctmeshnet, projectmeshnet provides one gateway
+<prurigro> they abuse it? drop them
+<ansuz> torontoDNS feeds mirrors its toronto records to the global .mesh/.para/.hype
+<prurigro> and everyone would register with a bunch of places to make sure one going currupt won't screw them over
+
+<qmx> ansuz: I still strongly believe we should model for each node being able to issue his own namespace
+<prurigro> kinda like drug dealers do on tor
+<ansuz> qmx, I agree, but until we have that, I think this is our best option
+<qmx> ansuz: we won't have that if we don't start building it
+<ansuz> we could build it while we have this in the meantime
+<ansuz> instead of competing over namespace
+<qmx> ansuz: just the mention of .mesh/.para/.hype/.diarrhea sounds like a dirty hack
+<ansuz> it's a better option than ICANN
+<ansuz> which gets used more than anything else on hype
+<ansuz> because there isn't a clear contender
+
+<prurigro> another idea I had, was a tld of 4 utf8 characters that are cryptographically tied to a combination of the name they're attached to and the ipv6
+<qmx> prurigro: make this 8 ascii chars
+<qmx> utf8 for names are a pita generally
+<prurigro> actually, what about 7
+<qmx> whatever
+<qmx> I like this idea a lot
+<prurigro> the average number of items the brain can store in one go
+<ansuz> I'm down
+<prurigro> (people vary from 5-9)
+
+<qmx> prurigro: tell me more about your idea
+<ansuz> is there any way we could easily tie that into regular dns?
+<ansuz> so we could roll it out without having to start from scratch?
+<ansuz> premature optimization blows
+
+<qmx> ansuz: I like cjd's idea of using .h as root
+<ansuz> maybe we can start with some clear specs, and then it doesn't have to be tied to one language's implementation?
+<ansuz> .h is fine by me
+<ansuz> anything is fine, imho
+<qmx> ansuz: gathering a set of reqs
+<qmx> into a document
+
+<qmx> then figuring out what can we build
+<prurigro> qmx: well, if the ipv6 is 0:0:0:0:0 and the domain is prurigro, the tld will be 7 numbers generated cryptographically based on both of those values, which an extremely small number of other ipv6 addresses would be able to combine with the domain to form
+<prurigro> kinda like how the ipv6 is cryptographically generated a much longer, but single source in cjdns
+<prurigro> (the pubkey)
+<prurigro> and a word + 7 characters is infinitely more remembreable than an ipv6
+<qmx> so I could technically have blog.fcea93
+<ansuz> don't you then have to change your domain if you change your cjdns conf?
+<ansuz> change/lose
+<qmx> ansuz: but then this is your problem, amirite
+<ansuz> yea
+<qmx> "don't be stupid"
+<prurigro> and it'd be the number of ipv6 addresses dividided by 36^7 of all ipv6 addresses that would be able to spoof
+<qmx> "friends don't let friends lose their private keys"
+<ansuz> I've been good about it, but it would be nice if, say, all my nodes had one tld
+<ansuz> easy to tell that *.ansuz all belongs to me
+<qmx> I still think a blockchain with proof of work would be nice
+<qmx> being the proof-of-work something that gives back to the network
+<ansuz> harder to tell that it's me if anyone can make ansuz.235gdj
+<qmx> ansuz: I agree
+
+<qmx> prurigro: I think it's a must for one to be able to secure a domain
+<qmx> and this is what makes everything harder
+<ansuz> so what about meeting in the middle?
+<ansuz> if we have tlds, but you have a crypto proof (optionally) in the subdomain?
+<ansuz> lkjdsgj32.ansuz.toronto.mesh
+<ansuz> or just ansuz.toronto.mesh
+<ansuz> mesh is for all of hype, toronto is dependent on torontoDNS, I completely administrate *.ansuz.*
+<qmx> ansuz: I still don't want a 3rd party controlling my domain names
+<ansuz> I don't see how we can get around it unless you want all of your users to point to your own nameserver
+<prurigro> qmx: yeah, the whole angle I was trying to think from when I came up with the idea I just suggested was in the hopes that dns could be almost as freeform as ipv6
+
+<ansuz> but I agree, I'd prefer not to
+<prurigro> there might be a better way to go about doing that, but this is the optimal solution imo
+<prurigro> (someone can imagine up an domain and it simply belongs to them, because noone else could have it)
+<ansuz> that's not too different from raw ipv6s, though
+<prurigro> then, your packet bounces around until someone says they know "ansuz.285w92" + has the correct ip6
+<ansuz> except they're shorter
+<qmx> what about crossing gpg wot and names?
+
+<prurigro> ansuz: it'd be verified against the ip6, and considered less secure but more convenient
+<prurigro> as an option
+
+<ansuz> i'm in favour of gpg
+<qmx> which incidentally means if enough people sign I'm qmx I'm qmx
+
+<ansuz> I'll sign ;)
+
+<qmx> that's the thing
+<qmx> you can have more than one entry for a record
+
+<ansuz> signing is better than blockchain
+<ansuz> for overhead, I would think
+
+<qmx> I advertise I provide the qmx namespace, you can check all the signatures
+<qmx> if a spoofer tries to provide qmx too, it's up to you to trust his
+<qmx> since cjdns is built upon "know thy peers"
+
+<ansuz> gets people to think more about gpg
+<ansuz> and trust
+<ansuz> which is good
+<qmx> we start growing the web of trust
+
+<ansuz> can we do this on top of an existing protocol?
+<ansuz> since I think most people will agree that NIH is problematic
+<qmx> I'm way more likely to trust something derp signed than something that (what was the name of the crazy one we trolled at #hyperboria?)
+<qmx> ansuz: the client allows you to decide, and sign the records you trust
+
+<qmx<unicode node glyph>
+<qmx> note*
+<ansuz> hehe, like my /whoami ?
+<qmx> ♫
+<ansuz> did you see that, qmx?
+<ansuz> so, requirements..
+<ansuz> it should be short
+<qmx> example
+
+<qmx> dig blog.qmx
+<qmx> returns blog.qmx.chooser.h
+<qmx> if you visit this it'll present you the records that match this tld and the sigs
+<qmx> this page is provided by your dns client daemon
+<qmx> which runs almost "inside" cjdns
+
+<jackv> but the key is that you need to trust someone, once you have that, cjdns makes it possible to trust all the traffic coming from him as his own
+<jackv> thus the problem here is finding someone (or multiple nodes) that you personally trust
+<jackv> and "trust" could be defined as, their records agree with all 10 of the servers in my area
+<jackv> a random sample of domains resolves the same with them as with a majority of the rest
+<jackv> not everyone has to run one
+<jackv> just make setting one up easy enough
+<jackv> just like mail servers :)
+```
+
+## DNS, with trust based on peering-like agreements
+
+Codename *lgdns*
+
+```
+<larsg> jercos: do you have any spontaneous thought re: web-of-trust-based dns on top of cjdns peers?
+<jercos> larsg: cryptographic identities float right near the top of course, a response coming from an address is enough to trust that address as the source of the information contained therin
+<jercos> uh
+<larsg> it just seems so simple
+<larsg> a mere ui problem
+<jercos> yeah... seperating levels of trust is a thing though
+<jercos> in an all-or-nothing trust system, the node with the highest trust level "wins" any conflicts, so your friend bob can send you a fake version of google.hype
+<jercos> which means your friend bob is now a central point of failure for you, and you now trust that his machine is completely malware free
+<jercos> ditto for *every* person you place at a higher level of trust than the original source for the google.hype that you expect to travel to
+<larsg> just realize that what i'm thinking of is basically 1) a bit of glue around rainflyclient, and 2) rainflyserver on $every node
+<larsg> yeah i get what you mean, you don't wanna roam into a rogue network and suddenly get fake answers
+<larsg> if peers would be able to delegate the trust placed in them to other nodes, we could even do something similar to geoip-based dns
+<larsg> not with coordinates as metric, obsly
+<jercos> yup. possibly using DHT coordinates.
+<larsg> yeah the server you're asking would delegate to another server (which it trusts) which is close to you
+<larsg> instead of just blindly trusting every current peer, there could be a simple trust list of a few nodes
+<larsg> and a means of seeding that list
+<larsg> "You can't resolve domain names yet. Which of your peers or other nodes do you want to trust with resolution? [list of peers] [ipv6 address] [search]
+<jercos> I'm headed homeward, I'll think on this on the drive :)
+<larsg> safe ride!
+
+<cjd> I've thought about some ideas like that
+<larsg> i should spec that out a bit more, so that someone looking for work can understand it
+<larsg> did you come with possible problems?
+<cjd> I killed a few ideas off
+<cjd> what if we just make a rule that we'll pull any changes to the db as long as they match the requirements and come from someone you trust
+<cjd> requirements: can't hijack a domain which is already regged
+<cjd> that's arguably a tragedy of the commons though since everyone will race to create new domains as fast as those connected to them will allow
+<larsg> that description is a lot more concise, thnx
+<cjd> in this context, trust is binary
+<cjd> I add your node to the list -> I trust you absolutely
+<cjd> I'll pull anything you offer
+<cjd> like bgp
+<larsg> or just for .com domains, or just for names matching /f.*ck/
+<cjd> what's wrong with  firetruck.hype ?
+<larsg> :]
+<cjd> and why not match against flappingcuntlips ?
+<cjd> or  throw-the-jew-down-the-well.hype
+<cjd> if you're going to censor, you have a duty to do it right ;)
+<larsg> de-peer
+<larsg> err, untrust
+<cjd> hmm
+<cjd> the way I imagined it, there's no clear way to drop a domain once it's registered
+<cjd> except for blocking it from being regged again and waiting for it to expire
+<larsg> yeah but "registered" is relative to whom you trust
+<cjd> meh that won't work
+<cjd> you have to reach consensus
+<larsg> y?
+<cjd> b/c all (working) dns does
+<cjd> if you rely on trust to determine what is the truth, you're going to have problems
+<larsg> you only need your own local truth
+<larsg> which you can make up of others' truths
+<larsg> local communities could offer trust lists to their members
+<larsg> and mutual trust could be established similar to how peering is established
+<larsg> in terms of the social process
+<larsg> mutual trust between communities, i mean.
+<larsg> don't like what your community thinks about how .com should be resolved?
+<larsg> tweak the community's default trust list
+<cjd> ok so you're actually thinking of doing the whole internet
+<larsg> cacert for dns i guess, with different tech underneath
+<larsg> useless without the community around it
+<larsg> just like cjdns
+<cjd> well you could write some sort of a rules engine for defining the domains
+<cjd> keep in mind though that it goes against how domains are normally registered
+<cjd> err
+<cjd> looked up
+<larsg> most communities and individuals will want to resolve icann domains the icann way
+<cjd> well you could write a rule like   .com -> 4.2.2.1
+<cjd> .net -> 8.8.8.8
+<cjd> penis.com -> 123.45.67.8   (if you reject how icann is handling it)
+<cjd> or you could just say . -> fc00:.....friend
+<cjd> hmm
+<cjd> when a node spins up, if it has no dns config it could just pull from it's nearest peer
+<larsg> or it'd "ask what do to do"
+<cjd> asking is a sin
+<larsg> yep indeed
+<cjd> just search for the nearest node which is offering dns results
+<larsg> FBI_Surveillance_Van_3
+<larsg> or do you mean search in the dht?
+<cjd> search the dht
+<cjd> surveillence van will still fuck you, it just needs to be running cjdns
+<larsg> that'd be a sensible default i guess
+<cjd> but that's kind of the rule
+<cjd> the van always wins
+<cjd> unless you do a big public key signing shitfest
+<larsg> if you're peering with someone over bluetooth (e.g. an android app that shares the .apk via bt), you'd likely also wanna take their dns
+<larsg> so having multiple options there would useful
+<larsg> AnotherInterface
+<cjd> tor uses a list of 8 directory servers
+<cjd> search the DHT for a directory server
+<cjd> kind of rainfly method
+<cjd> but directory servers die and stuff
+<cjd> not so resilient
+<larsg> on the peer level it's resilient though
+<cjd> ehh zzz
+<cjd> tomorrow
+<larsg> k :)
+<larsg> good night!
+<larsg> thanks for the thoughts
+<larsg> ... and so lgdns was born
+```

doc/notes/do.md

@@ -0,0 +1,32 @@
+## What happens when you call './do'
+
+**do** is a bash script, and is therefore at least somewhat readable by humans.
+
+The script starts off by initializing some variables:
+
+* The output of **uname** is trimmed and assigned to the environment variable **PLATFORM**
+* The output of **uname** is then piped through **sed** to replace 'i' and another character with 'x', such that i686 becomes x86. The returned value is assigned to the environment variable MARCH. Architectures like **x86_64** are unaffected
+* The environment variable BUILDDIR is initialized to equal "build_${PLATFORM}
+* The environment variable NODE_MIN_VER is initialized to equal "v0.8.15"
+
+## Function Definitions
+
+* **hasOkNode** Checks to see if your version of nodejs (if any) is sufficient for the build tasks. If it does, then it should (as a side effect) initialize the environment variable **NODE** to equal the path to your nodejs executable.
+* **getNode** Fetches an up to date version of nodejs.
+* **die** prints an error and kills the script.
+* **getsha256sum** finds a working sha256sum program. It tries a number of options, and returns 0 if none are successful.
+* **main** The main function, which I'll describe below.
+
+## Call main
+
+The main function starts by changing into the directory with a name equivalent to the output of `"$(dirname $0)". If that fails, then the process dies with the argument "failed to set directory".
+
+Next, we create the build directory (if it does not exist). If this fails, the process dies with the error "failed to create build dir ...".
+
+Next, we call getsha256sum. If its output is falsey, then the script dies with the error "couldn't find working sha256 hasher"
+
+Next, we call **hasOkNode**. If this returns 0, then we call **getNode**, if this is unsuccessful, then the script dies with the error "could not get working nodejs impl".
+
+Finally, we use the environment variable **$NODE** to call **cjdns/node_build/make.js** with the arguments "${@}".
+
+

doc/notes/docs.md

@@ -0,0 +1,62 @@
+Everything ought to be translated at some point (hopefully when it's somewhat finished)
+
+- Russian (mungell volunteered)
+- Portuguese (fiatjaf volunteered)
+- Spanish
+- French?
+- German?
+- ???
+
+
+what needs docs?
+
+- contrib/
+
+
+especially useful stuff
+
+- contrib/python/peerStats - shows a list of your peers and their connection status as well as byte counts
+- contrib/python/cjdnsadminmaker.py - generates .cjdnsadmin for use with other scripts
+
+
+Tutorials specifically for newbs
+
+- using IRC
+- community guidelines
+
+
+stuff on OSX
+
+- http://couch.syrinxist.org:9001/p/osx
+
+
+General Math and stuff behind cjdns security and network architecture
+
+- http://couch.syrinxist.org:9001/p/howCjdnsWorks
+
+
+"best practices for web development on hyperboria"
+
+- not including google APIs
+- ssl (certificate authority data leak)  CAs are bad. NSA probably has most of the CA keys.
+- assuming everyone is going to try to hack you.. because they would on clearnet anyway
+- listing a server's ipv6 in a conspicuous location (opt out of ICANN)
+- listing of available services on any given node (even a simple webserver saying who you are is kinda nice, there exists no way to tell who's who by IP)
+
+Good Ideas(tm)
+
+- Turn off password auth if you are running sshd on hype. Especially if you have crap passwords. http://couch.syrinxist.org/security ah
+
+CJDNS related resources:  http://couch.syrinxist.org/links
+
+links to....
+- buildbots?
+- blogs?
+- hype services?
+- related clearnet services?
+
+Proxying into your machine
+
+- socks? <- mungell
+- squid?
+- etc...

doc/notes/future.md

@@ -0,0 +1,17 @@
+## What can we do to make everything work better?
+
+
+```
+19:42 < ansuz> I'm thinking I'm gonna make an official "welcome to hyperboria package"
+19:43 < ansuz> and get everyone on efnet to point to that instead of peers.txt or my faq
+19:44 < ansuz> detail my findings from these interviews, tools that are commonly used, where you can find public peers, how to debug
+19:44 < ansuz> where to look for documentation, how to explore the network
+19:44 < ansuz> how to format bug reports, where to report them
+
+19:47 <@larsg> what can we do to make things better? -- invent a new name for cjdns
+
+19:50 <@larsg> what can we do to make things better? -- develop apps which fit the p2p character of the network
+
+```
+
+

doc/notes/links.md

@@ -0,0 +1,25 @@
+# Interesting links
+
+## Community Networks
+
+- [Freifunk (Germany)](https://freifunk.net)
+- [Guifi (Catalonia)](https://guifi.net)
+- [Altermundi (Argentinia)](https://altermundi.net/)
+  - [50 km link using Ubiquiti Rocket](http://blog.altermundi.net/article/completamos-el-enlace-de-50km/)
+- [Ninux (Italy)](https://ninux.org)
+- [AWMN (Greece)](https://awmn.net)
+- [Red Hook Wifi (NY, USA)](http://redhookwifi.org)
+  - [Case Study: Red Hook Initiative WiFi & Tidepools](http://oti.newamerica.net/blogposts/2013/case_study_red_hook_initiative_wifi_tidepools-78575)
+- [wlan slovenija (Slovenia)](https://wlan-si.net)
+- [Wireless Leiden (Netherlands)](https://wirelessleiden.nl)
+
+## Other Community Stuff
+
+- [Open Networks Interoperability](http://interop.wlan-si.net)
+  - An international effort to make community networks collaborate with one another.
+- [Wireless Commons](https://guifi.net/en/WCL_EN)
+
+## Appliances
+
+- [Commotion Wireless](https://commotionwireless.net)
+- [Serval Project](http://servalproject.org)

doc/notes/messy/WIP-nodejson-extended-json.md

@@ -0,0 +1,17 @@
+# Proposal for small daemon, nodeinfo-ng
+
++ small daemon
+  - serves:
+    + nodeinfo.json
+      + list of services
+      + hostname
+      + owner contact information
+      + "open to peering" option?
+      + other nodes operated by same owner
+      + robots.txt
+  - dumpTable (reuse the remnants of HDB?)
+  - Direct Peers
+  - cjdns log/debug info
+  - system info
+
+Note that some could be optional, and that **THIS IS A WORK IN PROGRESS**

doc/notes/messy/discussion about ISPs and whatnot.txt

@@ -0,0 +1,312 @@
+12:00 < ansuz> nat3r, for graphs https://docs.meshwith.me/en/meshlocals/intro.html
+12:00 < ansuz> ^ this page uses mermaid.js
+12:00 < nat3r> http://www.nytimes.com/2014/11/18/nyregion/pay-phones-in-new-york-city-will-become-free-wi-fi-hot-spots.html?_r=0
+12:01 < jercos> and if you can take the info in that paste and turn it into a pretty wiki page, you've earned yourself $35 paypal from me if you'd like.
+12:01 < nat3r> which wiki
+12:01 < ansuz> unfortunately, wifi does not a meshnet make
+12:01 < jercos> Eh, markdown for the documentation project would be ideal.
+12:01 < nat3r> a fast meshnet 
+12:02 < ansuz> and the extra radio in the air can actually choke out other signals
+12:02 < jercos> translating a good wiki page from a different format to markdown is easier than formatting and copyediting a brand new wiki page in any format though imo
+12:02 < ansuz> for instance, Toronto has open wifi, but it's crap, and it blocks anything else that might run in that frequency range
+12:02 < nat3r> https://wiki.projectmeshnet.org/Main_Page that wiki
+12:03 < ansuz> rather, it was meant to be free, then the city sold it, and now it's paid
+12:03 < ansuz> nat3r: nonononon
+12:03 < ansuz> that wiki sucks
+12:03 < ansuz> submit a Pull Request on the github
+12:03 < nat3r> haha ok, well which wiki is the most used 
+12:03 < ansuz> the github is the authoritative source, it's all vetted by community members
+12:03 < jercos> if you make a github gist I'd happily integrate that into https://github.com/ProjectMeshnet/documentation/
+12:04 < jercos> or if you clone that and integrate it into that, you can submit a pull request
+12:04 < nat3r> jercos: one more question, the major price wouldnt be to run riber to a town, it would be to run fiber to every home too 
+12:04 < nat3r> right? 
+12:04 < ansuz> the wiki is just that, a wiki that anyone can edit, so it's full of junk info
+12:04 < jercos> nat3r: the price scale for metro fiber is entirely different. It could wind up being vastly cheaper, it could wind up being far more expensive...
+12:04 < nat3r> ive never used github at all, i am a web marketer not a coder so its something i've never really tapped into
+12:05 < ansuz> you can edit github repo source in the browser
+12:05 < jercos> But metro fiber scales near-linearly with each added house, so using at least *some* wireless in the local area will save money on that quite a bit
+12:05 < jercos> ansuz: TIL. is *that* why there's a pencil icon now? :p
+12:05 < nat3r> so basiaclly for a town far outside the metropolitan zone, something like the nano would make more sense
+12:05 < ansuz> hehe
+12:06 < jercos> the thing with metro fiber is that the cheap way to do metro fiber is to centralize on a single company.
+12:06 < ansuz> I'd rather use vim, but apparently vim is kinda hard
+12:06 < nat3r> so crowdfunding a big project
+12:06 < jercos> Getting comcast to run metro fiber to 20 households will be cheaper than putting 5 households on comcast, 5 households on time-warner, 5 households on verizon, and 5 households on centurylink
+12:07 < jercos> which is also bad in a sense, because now a large number of people are reliant on one company to stay connected
+12:07 < nat3r> i thought we were talking about level 3 running the fiber 
+12:07 < nat3r> and not ISP's 
+12:07 < jercos> so you would probably want to mix chunks of metro fiber, wireless links, etc, and let cjdns sort out the best path to take through the whole mess
+12:07 < jercos> level3's fiber would be for a single huge buy to run between cities
+12:08 < jercos> metro fiber is typically provisions from existing infrastructure within a city that's been placed by a local ISP
+12:08 < jercos> privisioned*
+12:08 < jercos> provisioned*
+12:08 < jercos> dammit can't type :p
+12:08 < jercos> on the small scale, local ISPs will almost always win out, because they already have infrastructure in place
+12:09 < nat3r> so wireless is the only way around that at the moment 
+12:09 < jercos> you could even buy your own fiber, and contract a company to dig trenches and lay it, and get all the right permits from the city... at which point the costs are now calling in a contractor to find a break in the line and splice it when it happens, rather 
+                than a flat monthly fee
+12:09 < jercos> wireless and metro fiber are the *cheap* local options though
+12:10 < nat3r> yeah 
+12:10 < jercos> heck in a rural area it might be affordable to permit+contract and run fiber on telephone poles
+12:10 < nat3r> so thats more like 100k we're talking 
+12:10 < nat3r> if we are going to break ground 
+12:10 < nat3r> hell even more than that
+12:10 < jercos> that sort of infrastructure though needs to run back to a central location typically.
+12:10 < jercos> yeah that gets up out into the millions most likely
+12:11 < jercos> so at the point of stringing or burying fiber either way you're now talking about renting commercial space, or running your fiber all back to a local datacenter, either of which mean more length to the fiber
+12:12 < jercos> a metro fiber provider has already done this, and has the central office set up, so they just need to run more fiber out from a splicing point on an existing run, and then turn on their equipment to link two points
+12:12 < nat3r> but isnt the point to avoid the commercial space and have it purely as a peer-to-peer network?
+12:12 < jercos> not exactly. sorta.
+12:12 < ansuz> umm
+12:12 < ansuz> the cake problem
+12:13 < nat3r> do tell :P
+12:13 < jercos> when you rent infrastructure like this you really do own the network. there isn't a difference between paying comcast for your metro fiber and paying someone else for your metro fiber, it's just cable
+12:13 < ansuz> I think you could apply this to figure out where to run fiber
+12:13 < ansuz> http://www.npr.org/blogs/thesalt/2014/06/19/323656819/cut-your-cake-and-keep-it-fresh-too
+12:13 < jercos> the *ideal* would be the multi-million dollar option, but this sort of thing is a reasonable compromise
+12:14 < nat3r> well at least the national and international systems are in place already 
+12:14 < nat3r> thats pretty much the hard part 
+12:14 < jercos> when you're using radio, you're still effectively relying on a central organization... like the FCC, regulating your spectrum use in the US
+12:14 < nat3r> well, one of the hard parts 
+12:15 < jercos> there's always going to be some hitch like that, but in this model the meshlocals own their part of the network, and are just renting connections around the city, and paying part of the connectivity back to the world
+12:16 < jercos> this really is just like how the internet does it
+12:16 < jercos> if you pay ARIN for some IP space and a BGP ASN, and lay fiber, and make peering arrangements with someone already on the internet, you can get on the internet without paying an ISP at all
+12:17 < jercos> same cabling, same concepts, just without cjdns and wireless networks as a core part of the system
+12:17 < jercos> cjdns removes the need for ASNs and assigned IP space, and replaces BGP as a routing protocol
+12:17 < nat3r> i havent looked to far into cjdns just yet 
+12:17 < jercos> BATMAN-adv makes a local set of wireless links into a homogenous mesh over which a wider routing protocol can carry traffic
+12:18 < nat3r> so who would be the ones to roll out the city-to-town fiber 
+12:18 < jercos> that's just it, it can be *anyone*
+12:18 < nat3r> assuming we wanted to go the cheap residential wireless option 
+12:18 < jercos> different meshlocals can have different political structures
+12:18 < nat3r> ok so that part can be anyone 
+12:19 < nat3r> so Level 3 would take care of Chicago to NYC, but Chicago to Elburn, for example, would be up to somebody deciding to actually lay the fiber down
+12:19 < nat3r> elburn is a suburb
+12:19 < jercos> you could have a bunch of homeless guys run cable through gutters, you could run free-space optical, you could use something like ubiquiti airfiber, you could cover a huge area with satellites
+12:20 < jercos> and yes.
+12:20 < jercos> a metro fiber provider is just a cheap option because they already have Chicago to Elburn run, and would just need to run from their Elburn office to an individual Elburn neighborhood
+12:20 < nat3r> airfiber is faster than traditional wireless i would guess
+12:20 < jercos> or possibly might already have a run going near the neighborhood in question
+12:21 < jercos> eh, it's faster sure, but the point is that it's highly directional and very long range
+12:21 < jercos> set up two towers, point the airfiber dishes at each other, and you can go for miles and still have fairly good speed
+12:22 < jercos> it might cost 1k or more for each airfiber node, but then two nodes can be very far apart
+12:22 < nat3r> yeah 
+12:22 < nat3r> how much traffic do you think a pair of airfiber dishes could handle?
+12:22 < jercos> around 1gbps
+12:23 < jercos> that'll vary with weather conditions and such
+12:23 < nat3r> and the airfiber would be wired to the Nanostations which would serve the area 
+12:23 < jercos> and different brands of directional wireless link might handle more or less
+12:23 < jercos> right
+12:23 < nat3r> so people wouldnt be getting 1gbps speeds 
+12:23 < nat3r> they'd be getting a portion of that, depending on how many other people are using it 
+12:24 < jercos> you might set up a tower in Elburn and put a mast on a building roof in Chicago, the mast in Chicago could be wired directly to the metro fiber that building is connected to, which goes back to a datacenter where it links up with the NYC to Chicago link
+12:24 < nat3r> good i was thinking the same thing 
+12:24 < jercos> the Elburn tower would have nanostations on it too, convering the whole Elburn area maybe
+12:24 < nat3r> yep 
+12:24 < jercos> and then the nanostations can probably only handle gigabit at most each
+12:25 < jercos> so yes, one individual would get gigabit, or two individuals could use half a gigabit each, but all of Elburn gets a gigabit out to the wider world
+12:25 < jercos> with fiber you can always add more strands, and turn 1 gigabit into 2, or 10 gigabit into 20
+12:26 < jercos> with wireless, what you get is typically what you get, unless you have a wide spacial spread and directional links
+12:26 < jercos> so you might be able to put a tower on each edge of Elburn, and two seperate masts say 40 ft apart on the same building in Chicago
+12:26 < nat3r> yeah so you're limited by the airfiber, straight out
+12:26 < jercos> yep
+12:27 < jercos> but 2k for a pair of airfiber units is then possibly cheaper than $200/mo for the rest of forever for a gigabit metro fiber link
+12:27 -!- jackv [~jackv@108.247.152.124] has joined #projectmeshnet
+12:27 < jercos> (again, prices aren't up to date, heck it might be $2k/mo for the metro fiber alone at that range)
+12:28 < jercos> (or metro fiber might not be available at that range, requiring a contracted dig to get that run)
+12:28 < nat3r> so in a nutshell
+12:28 < nat3r> move to the city 
+12:28 < nat3r> and stay there 
+12:28 < jercos> hey, gigabit shared over a suburb isn't nearly as bad as you might think
+12:28 < nat3r> yeah thats true 
+12:28 < nat3r> i imagine everybody is like me 
+12:29 < nat3r> which is wrong
+12:29 < jercos> a good fair router in the Elburn tower could give 50/50 access to 20 people, sure, but you can "oversell" just like a consumer ISP would
+12:29 < nat3r> yeah but then you just become an isp 
+12:29 < nat3r> lol
+12:30 < jercos> not in the same lying way, but "1 gbps *shared over your area*, guarunteed 5mbit" isn't as bad as getting sold a 50mbit connection and only getting 5mbit when the neighborhood is busy
+12:30 < nat3r> yeah 
+12:30 < jercos> the peak traffic for any one user likely won't align with other users exactly, and e.g., watching netflix doesn't use 1 gigabit/s, it uses whatever the bandwidth of that video stream is
+12:31 < jercos> plus the cost for an individual user is going to be incredibly small again
+12:31 < jercos> brb, lunch
+12:31 < nat3r> yeah 
+12:33 < nat3r> how expensive is the CHI to NYC connection? 
+12:47 -!- jackkv [~jackv@107.194.21.5] has joined #projectmeshnet
+12:49 -!- jackv [~jackv@108.247.152.124] has quit [Read error: Operation timed out]
+13:06 -!- voltid [~volt@173-170-189-41.res.bhn.net] has quit [Read error: Operation timed out]
+13:16 -!- mildred [~mildred@128.140.133.68] has joined #projectmeshnet
+13:17 < jercos> nat3r: that's one I've never had the opportunity to get a price tag on exactly.
+13:18 < jercos> The hope would be that whatever company you buy from already has fiber run not being used (which is a very common scenario, probably even more common than you would think after reading that statement)
+13:18 < jercos> the company will still charge a fair amount for it naturally, but it will be much lower than the cost of burying fiber over many miles
+13:18 < nat3r> buy what from
+13:19 < jercos> the connection from Chicago to NYC?
+13:19 < nat3r> sorry, a lot in that sentence
+13:19 < nat3r> so
+13:20 < nat3r> whatever company you buy [connection from nyc to chi] from has fiber run not being used 
+13:20 < jercos> and naturally the same sort of bandwidth sharing scenarios can work in your favor... find a hackerspace each in chicago and NYC maybe and talk them into sharing some of the cost of the line, and in exchange, give them a dedicated link to each other? :)
+13:20 < nat3r> and by fiber run you mean already laid fiber?
+13:20 < jercos> yeah. any major company that would do fiber runs would already have that particular run (Chicago to NYC in particular, rather than any two cities) already full of fiber
+13:20 < jercos> yep.
+13:21 < nat3r> oh my bad 
+13:21 < nat3r> so you're just saying it would be cheaper 
+13:21 < nat3r> because you're only buying access 
+13:21 < nat3r> as opposed to buying a new run
+13:21 < nat3r> there would be a little bit of work, laying the hackerspace lines 
+13:21 -!- mildred [~mildred@128.140.133.68] has quit [Remote host closed the connection]
+13:22 < jercos> there's sort of a diamond between Austin, TX; San Jose, CA; Chicago, IL; and NYC, NY; where you'd be able to buy existing dark fiber from many major companies
+13:22 < jercos> yeah
+13:22 < nat3r> what about seattle
+13:22 < nat3r> seems to be the hotspot
+13:22 < jercos> hopefully the hackerspace in question though would then also be interested in the meshnet, and want to participate, so their building might be the site of one of the wireless mesh nodes :)
+13:22 < jercos> seattle is pretty hot tech-wise, but they aren't in a position to be a major national meeting point.
+13:23 < nat3r> yeah, it just seems that, from browing the web, they have a ton of mesh nodes
+13:23 < jercos> iirc they are an *international* meeting point for lines over the pacific to Asia...
+13:23 < jercos> Yeah, part of that is just the density of tech people. Seattle is full of smart folks who want to do something interesting.
+13:23 < nat3r> yeah
+13:24 < nat3r> so how do i get access to Hyperboria right now
+13:24 < jercos> right now the easiest way is to peer over the internet
+13:24 < nat3r> which i have no problem doing 
+13:25 < jercos> you might have a meshlocal near you, you might want to start a meshlocal if there isn't one, but the way to get from the meshlocal to hyperboria will be the currently cheapest option, a consume-grade internet connection.
+13:25 < jercos> consumer*
+13:25 < nat3r> i saw that crowdfunding page, has cjdns been ported to windows yet?
+13:25 < jercos> a meshlocal might wind up with more than one consumer grade internet connection linking them, and might have internet links dense enough to make it more efficient to duck through the internet to avoid two or three wireless hops
+13:25 < jercos> it has.
+13:26 < jercos> interfect put together an installer even
+13:26 < jercos> I'm still using the version from that installer on my windows machine at home :)
+13:26 < nat3r> http://www.reddit.com/r/darknetplan/comments/2hvjbe/installer_for_cjdns_on_windows/
+13:26 < nat3r> yess
+13:26 < nat3r> one sec
+13:28 < nat3r> ok back
+13:28 < jercos> coolio
+13:28 < jercos> as noted in that thread, that version will be updated... someday :p
+13:29 < jercos> since cjdns is very much still in flux as a project, that means you might be left with a non-working version and no path to update for a long while if the protocol changes majorly
+13:29 < nat3r> it happens
+13:29 < jercos> so the current recommended path is still to use the most targetted platform, which is Linux, and treat any other platforms (mac, *BSD, windows, etc.) as secondary
+13:29 < nat3r> so how do you switch back and forth on windows
+13:29 < jercos> How do you mean? Switch between what and what?
+13:30 < nat3r> well its tor-esque right?
+13:30 -!- larsg_ [~larsg@p4FCDF29D.dip0.t-ipconnect.de] has joined #projectmeshnet
+13:31 < jercos> There is a slight resemblance in some areas, but for the most part, no.
+13:31 < jercos> one of the biggest differences obviously is that there's no onion routing.
+13:31 < nat3r> so to switch from normal web browsing to hyperboria web browsing theres changes that youd make 
+13:31 < jercos> cjdns is not, and should not be treates as, anonymous.
+13:31 < jercos> treated*
+13:32 < jercos> it encrypts all your data, sure, but each node along the way knows the source and destination of the packet by examining the switching label and their own routing table
+13:32 < nat3r> ah ok 
+13:32 < jercos> cjdns also passes real IP packets.
+13:32 < nat3r> hence the manual invitation 
+13:32 < jercos> Tor and i2p are similar in that they implement *A* stream socket layer, and then have a translator between TCP and their own stream sockets
+13:33 < jercos> yes. cjdns also doesn't have any kind of internet autopeering. there is local autopeering with physically close machines over ethernet, but the manual process exists because it's potentially unsafe (in a privacy sense) to connect to random people
+13:34 < jercos> cjdns acts like a corporate VPN rather than a proxy. it handles IP packets as I said, but it handles them in a special manner, and doesn't expect to receive traffic destined for the internet normally
+13:34 -!- larsg [~larsg@p57A059FA.dip0.t-ipconnect.de] has quit [Read error: Operation timed out]
+13:34 < jercos> the "iptunnel" mechanism can be used to pass internet traffic to a node that you control, and specifically configured to allow that between two particular nodes...
+13:34 < nat3r> so there are sites that can be accessed exclusively through the cjdns protocol
+13:34 < jercos> but it's not designed to have "exit nodes"
+13:35 < jercos> yeah. it might do to think of every cjdns site as being a .onion site in one sense, because endpoints are always identified by cryptographic key
+13:36 < jercos> Except as a full IP address, you have potentially 65535 TCP ports and 65535 UDP ports to do stuff with, instead of having a mapping to a single port for each key
+13:36 < nat3r> so whats the preferred method of connecting to others
+13:36 < jercos> there are hyperboria-only sites, that usually work by binding specifically to the cjdns TUN/TAP device
+13:36 < nat3r> is there a wiki within the network that informs users of various services?
+13:36 < jercos> but the "default" setup for most webservers will work with cjdns without changing anything as long as it accepts IPv6 traffic
+13:37 < jercos> uh, there are a couple of sites keeping track of open services on the network, but there's no a single authoritative one
+13:37 < jercos> the hyperboria intelligence agency catalouges services by scanning every node they find with a port scanner for example ;)
+13:38 < jercos> the most preferred method of connecting to others is the same process used for freenet... peer with your friends. with people you know in the real world. people who, if their nodes started behaving poorly, you could knock on their front door and ask them 
+                what was up
+13:39 < jercos> (or call them on the phone, etc. point being, people who are real people for certain, not internet bots, and not secret agents :p )
+13:39 < nat3r> i did see my city in a list somewhere
+13:39 < nat3r> with an IRC channel and other things 
+13:39 < jercos> It's like the difference between searching a key website for someone's name and using the first result, and actually having them hand you their key.
+13:40 < nat3r> but the IRC channel isnt used, and the google group set up no longer exists so it looks like its a dead group
+13:40 < jercos> knowing that a person is real gives you confidence that they won't try to feed all your traffic into a honeybot, or randomly mangle packets, or exploit a flaw in the protocol, and in turn gives *them* the same security, that you're not a misbehaving node 
+                who'll try to spam any email servers they find or something
+13:41 < jercos> yeah, it's a shame when groups die like that :| do you live in a university sort of area?
+13:41 < nat3r> yeah there are a whole bunch around me 
+13:41 < nat3r> but 
+13:41 < nat3r> i dont live in a major city 
+13:42 < nat3r> hell i dont live in a major state 
+13:42 < jercos> When there are students coming into an area for a year or 4 of school they often start things (with the usuall aplomb of college kids), and then the whole project fades away when that group graduates, or when exams start, or something
+13:43 < nat3r> yeah i got that 
+13:43 < jercos> sadly those type of folks are the sort most likely to actually be willing to put in the effort of starting a group in the first place...
+13:44 < nat3r> well we do have very popular labs in the area 
+13:44 < jercos> so there have been a lot of those sort of groups even over the short history of meshlocals as they exist now
+13:44 < nat3r> any documentation on node building?
+13:44 < jercos> um, there's various documentation in places that I don't remember now, but it's extremely flexible.
+13:45 < jercos> If a machine/gateway/router/AP/media center/streaming dongle/whatever will run Linux (which includes OpenWrt on home gateway products) it'll usually passably run cjdns
+13:45 < nat3r> ended up on some weird notepad installation with a bit about installing an Omnitik on a seattle rooftop
+13:45 < jercos> sometimes there's bandwidth restrictions from the CPU being too slow
+13:45 < jercos> and naturally picking a good wireless card and a good antenna are important
+13:46 < jercos> but the hardware requirements beyond those can flex very far
+13:46 < jercos> cheap hardware is a good reason to use BATMAN-adv as a first player instead of running cjdns directly on a wireless link for example
+13:46 < jercos> you can use very cheap home gateway devices to make the local meshing parts, and then run cjdns nodes on computers attached to those gateways
+13:47 < jercos> BATMAN-adv doesn't need slow crypto to work, so it can cost very little (probably under 1k to mesh a metropolitan area if you're careful with the budget and don't mind ordering lots of things from china)
+13:47 < jercos> and then that fabric can carry a cjdns link from a computer on one side of the area to th other, without needing a node at each hope
+13:48 < jercos> that same sort of design is used by a lot of commercial ISPs with MPLS
+13:48 < nat3r> is there a current benefit for creating a mesh though?
+13:48 < jercos> the ISP has a meshy sort of network all over the city, they attach your company offices to that mesh, and any traffic you send gets tagged with a lebl saying where it's going
+13:48 < jercos> uh, most of the same benefits you'd have from having all your local friends on a LAN apply
+13:49 < nat3r> ah 
+13:49 < nat3r> so the peer-to-pear connection is certainly a focus 
+13:49 < jercos> assuming you can keep the number of hops down, that sort of thing is great for bandwidth-intensive games that wouldn't work well over a slow internet connection. minecraft for example, works great over cjdns :)
+13:49 -!- voltid [~volt@173-170-189-41.res.bhn.net] has joined #projectmeshnet
+13:49 < jercos> yeah, that's really the level at which we're keeping corporations out
+13:50 < nat3r> how fast is hyperborea? 
+13:50 < jercos> the mesh equallizes *people*, so anyone can run a service or participate in the larger internet with futzing with "port forwarding" or needing to pay for an expensive high-end internet connection
+13:50 -!- orthogona [~orthogona@151.moo0102.moo.iprimus.net.au] has joined #projectmeshnet
+13:51 < jercos> it depends. right now cjdns has some outstanding routing bugs, so the first time you try to reach a node, it might take a while to find a good route through the network...
+13:51 < jercos> in some cases you might never find a working route even if the path should be good. you'll see that discussed as a "blackholing bug"
+13:51 < jercos> obviously eventually that'll be fixed, but that's the main slowdown currently
+13:52 < jercos> I don't have good figures for uncapped connections other than the nodes in my LAN, on gigabit ethernet...
+13:52 < nat3r> when you say it equallizes people, i dont really see how thats possible when we are all mostly constraigned by our consumer connections
+13:52 < jercos> yeah, as long as we're going through consumer connections those will be the bottleneck for speed... but as I mentioned, port forwarding is a thing.
+13:53 < jercos> port forwarding is needed because of NAT, which in turn is needed because ISPs typically only hand out one IP address
+13:53 < jercos> without NAT, you'd need to rent an IP address for each of your devices
+13:53 < jercos> which in the time before NAT was common, was a heavily charged premium service
+13:54 < jercos> now I have dedicated static IPs on my devices at home in the $100/mo range... most people don't.
+13:54 < jercos> with cjdns in the picture, you have one IP address for each device running cjdns, no matter how many you have.
+13:54 < jercos> There's no cost to add a device and peer it with one of your own computers
+13:55 < nat3r> yeah but i do that internally for free
+13:55 < jercos> which means in turn anyone can run a webserver, or an IRC server, or whatever they want, and have those addresses also work for everyone *else*
+13:55 < nat3r> yes
+13:55 < nat3r> which is awesome
+13:57 < jercos> naturally you can use private IPs and port forwarding to simulate that ability, but often games or services like ftp will use extra ports... IRC DCC is a great example of that. if you want to send someone a file, you have to have an IP address that they can 
+                connect back to.
+13:57 < jercos> in a nromal situation your firewall allows your IRC client to listen on a port, and then you use that port for the file transfer
+13:57 < nat3r> like thats simple to me though..
+13:57 < nat3r> i have no issue port forwarding or DMZing or w/e 
+13:57 < jercos> in a NAT scenario the user has to forward a port specifically for that application, and that port is not shared
+13:58 < jercos> sure. it's not difficult for any technical user, but that doesn't make it right.
+13:58 < jercos> it's something you're forced to do because you only pay for one IP address on the public internet
+13:59 < jercos> and it's almost *universally* accepted, to the point that modems these days often ship with a built-in gateway device
+13:59 < jercos> it's like, "look, you're only going to get one address, here's a device to share that address with your computers."
+13:59 < jercos> it's not how the internet was meant to work
+14:00 < jercos> plus consumer ISPs often block certain ports, or have a service agreement against doing certain things.
+14:00 < jercos> port 25 is a common one. want to point a domain at your home IP address and get email there? nah, that's blocked.
+14:01 < jercos> usually the service agreements include not serving web pages of any kind on any port. FiOS for one, has that.
+14:03 < jercos> but even right now we don't need to constrain a meshlocal to consumer connections. commercial connections with no restrictions on them (and usually enough bandwidth to share with its users) are fairly affordable, and many metro fiber providers offer that as 
+                an addon to that service as well
+14:04 < jercos> so a meshlocal might pool their users' money and share a larger connection that doesn't have any restrictions on sharing... and at that level of connection a whole block of IP addresses on the public internet is often thrown in at little or no charge.
+14:04 < jercos> I uh, recall getting a rate-billed capless connection for a couple hundred bucks on average and getting a /24 out of it
+14:05 < ansuz> my isp has restrictions on launching servers, but they can't tell that I'm serving something based on my cjdns traffic
+14:05 < jercos> that could be 254 users getting sold internet-over-the-mesh by a meshlocal in addition to that pipe being used for an internet link to hyperboria
+14:05 < jercos> yeah. that circumvention ability is partially why I think ISPs will be against cjdns traffic, and might even eventually actually block it
+14:06 < ansuz> there's also the matter of not needing to set up SSL over cjdns
+14:06 < ansuz> which is nice
+14:06 < jercos> why you could be doing *anything* over that connection, streaming pirated movies, downloading child porn, won't someone please think of the children, etc. etc.
+14:06 < nat3r> back sorry
+14:06 < ansuz> net neutrality is the devil's plaything
+14:06 < ansuz> or something
+14:06 < jercos> and then just like that there's no question over an ISP's right to pull the plug on you if they see you using cjdns
+14:06  * jercos shrugs
+14:10 < nat3r> yeah 
+14:10 < nat3r> i mean thats the beauty of a hackerspace
+14:10 < nat3r> in regards to pooling money
+14:11 < nat3r> you can pitch in for a business line 
+14:11 < nat3r> and use that to serve the network
+14:30 -!- mathemanc [~mathemanc@67-6-161-185.hlrn.qwest.net] has joined #projectmeshnet
+14:32 < nat3r> how does routing work again?
+14:34 < nat3r> jercos: can you send me the chatlog again, we obviously covered a lot more
+14:35 < ansuz> https://github.com/ProjectMeshnet/documentation/blob/master/en/notes/arc-workings.md#about-xor-distance-and-finding-nodes
+14:35 < jercos> och
+14:35 < jercos> lots to copy and paste
+14:35 < ansuz> ^ this is from an old chat I had with one of the guys who knows about routing
+14:35 < ansuz> since then I've looked into it more, but I haven't yet written it all down

doc/notes/wanted.md

@@ -0,0 +1,42 @@
+# Ideas for new docs
+
+* cjdns
+  + breakdown of 3 parts of cjdns as explained in the [whitepaper](https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md)
+  + how to [cjdroute.conf](https://wiki.projectmeshnet.org/Cjdroute.conf)
+  + Admin API
+* Peering
+  + generating and transferring credentials
+  + ~~over UDP/IP~~
+  + over Ethernet
+  + over Wireless
+    - [batman-adv](http://www.open-mesh.org/projects/open-mesh/wiki)
+    - [oslr/commotion](https://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol)
+    - [802.11s](http://lars.meshnet.berlin/view/welcome-visitors/view/80211s-instead-of-adhoc)
+    - [Adhoc](https://wiki.projectmeshnet.org/Wireless_Autopeering_Tutorial)
+  + over TCP/IP
+    - allows obfsproxy deployment
+  + in datacenters (private networking)
+  + over iodine
+* Security mechanisms (seccomp, angel/core, etc.)
+* WiFi Recommendations
+* cjdns/contrib/ scripts
+  + dumpTable
+  + systemd/upstart
+  + peerStats
+  + python/cjdnsadminmaker
+* the build system :(
+  + cjdns/node_build/make.js
+* in the media
+* FAQ
+  + My service doesn't like ipv6. how can I get it to run on hype? [6tunnel?](http://toxygen.net/6tunnel/)
+    * inet6 with tcp6 and netcat
+  + How can I help?
+    * documentation!
+    * coding
+      - C - help build cjdroute!
+      - [Android](https://github.com/berlinmeshnet/cjdns-android)
+      - Go - help jph build zlarkd!
+      - Windows/CrossPlatform devs - Help us make cjdns portable to *all* the devices!
+  + Jargon file
+* Known bugs && their circumstances
+  + Failure to reestablish connection after disconnect/ipv4 change

doc/openwrt.md

@@ -0,0 +1,16 @@
+# Running cjdns on commodity routers w/ OpenWrt
+
+From: http://www.reddit.com/r/darknetplan/comments/2lmpqg/running_cjdns_on_commodity_routers_w_openwrt/
+
+Since the assumption pops up every other day that cjdns wouldn't run on commodity routers:
+
+Yes, it does run fine on OpenWrt and is used in production by the Seattle and New York City meshnet communities, as well as Freifunk Hamburg and many individuals.
+
+- The source code, GPL licensed: https://github.com/SeattleMeshnet/meshbox#readme
+- If you already have a router, check how well it is supported by OpenWrt. Look for anything supported by OpenWrt 14.07 a.k.a. Barrier Breaker a.k.a. BB: http://wiki.openwrt.org/toh/start
+- If you plan to buy something, look for Ubiquiti and TP-Link routers/antennas.
+- Follow the installation instructions in the Readme file mentioned above, to compile an OpenWrt firmware image including cjdns and the LuCI web interface.
+
+We will soon be offering prebuilt firmware images for a few selected devices, including TP-Link TL-WDR3600/4300/4900, Netgear WNR2000v3, Raspberry Pi, and BeagleBone Black. There will also be Docker containers of the firmware image, for easy local development and spinning up of virtual test topologies.
+
+You will find help in #cjdns on EFnet if you run into problems trying out cjdns with OpenWrt.

doc/tipsAndTricks.md

@@ -0,0 +1,17 @@
+## Things nobody seems to know about cjdns
+### (even those who have been using it for a very long time)
+
+#### cjdns has an option to stay in the foreground
+
+```Bash
+./cjdroute --nobg < /path/to/cjdroute.conf
+```
+
+#### You don't need to run cjdroute as root
+
+Uncomment the _TUN SECTION_ <!-- elaboration required --> of the conf and launch it like that. Your node will switch traffic, and peer effectively, though you will not be able to run services.
+
+You have the option of configuring your TUN device manually. It will require root, but once established, cjdroute can otherwise run as an unprivileged user.
+
+
+