ri/blog

I’m very pleased to announce that version 0.1.0 of python-libdeje is done! This is a really exciting milestone towards not only internet freedom, but some of the specific goodies we want to include in the core RILink software packages.

What is python-libdeje?

It’s a Python library that implements the DEJE protocol. Other programs can use python-libdeje to do DEJE stuff without worrying too much about the dirty details underneath.

What is DEJE?

DEJE stands for Democratically Enforced JSON Environment. As I pitch it to my parents, “it means computers can share a piece of information that follows its own rules, and nobody can cheat without everybody cheating.”

A classic example of what it’s perfect for, is a chess game between two players - me, and my friend Jake. Jake isn’t much of a hacker. He’s playing with a really fancy graphical client, with 3D animations, customizable sets, all sorts of whizbang. I’m a geek, I’m happy with a general-purpose CLI DEJE client. I don’t have to leave the terminal while playing, but my client doesn’t know anything about the rules of chess. It’s a bit simple-minded that way.

All the rules of chess are embedded within the game itself. If Jake installs some mods in his graphical client to cheat (or just encounters some strange bugs), my client - which knows nothing about chess - will say “nuh-uh, you can’t do that!” And he’ll get an error on his end, and the change won’t happen. But if everybody plays by the rules, I’ll be able to see things like “Rook to B6” when Jake click-and-drags his rook over, and I’ll be able to perform moves on my end with commands like hr chess {"source":"B3", "target":"B6"}, which Jake sees as fancy animations. It just seamlessly works, and most importantly, no one can cheat.

It doesn’t just work for chess, obviously, that’s just a really conceptually straightforward demo of what DEJE does. It’s a great solution for any distributed system where you need to enforce arbitrary rules, and trace back from the beginning of an object to confirm for yourself, cryptographically, that every change in the chain is valid, which means the current state is valid.

How does this relate to internet freedom/DNS?

In the current system, domain information is split up in ways that have several failings:

  1. Arbitrary limitations and weirdness seemingly designed to give sysadmins headaches, or at least the repeated experience of stepping squarely into the jaws of a metaphorical beartrap.
  2. Domain name resolution is split up from WHOIS information. While this grew out of a need for backwards compatibility, in the present day it’s just separate databases begging to get out of sync. Automation helps a lot with this, but it’s still a big conceptual problem.
  3. The centralized nature means that it’s got a serious problem of attack surface. You just have to hack one site, or steal one password, or get mad at your managers and run off with the account, and you can point the domain wherever you want. You basically just stole the whole site, and they’re at your mercy until you give it back.

And I’m pretty sure we can all agree that the above are bad things. Or at the very least, if we had a better alternative that solved such problems correctly, it would be worth being excited about.

DJDNS is the solution to the above problems, and probably a few more that I’ll think of later after I’ve already published this blog post.

How so? Details, dammit! Sell me!

Right, right. DJDNS is a system for using DEJE documents to store and secure domain information, including resolution to IP addresses, WHOIS data, and any other domain-specific information you could ever want, in a futureproof way. It uses a heirarchal network of regex-based resolution routing, allowing for any arbitrary configuration, and your choice of root document. Best of all, you can strengthen your domain against attacks with a community of independent participants as a line of defense against vandalism, and changes will update everwhere almost instantaneously without TTL issues.

Each DJDNS “branch” is a DEJE document containing a bunch of regex strings, pointing to other branches. For example, the root document might point to other more specialized branches for each subdomain - one for .com, one for .net, one for .hype, etc. Branches can point a regex to a leaf instead of a branch, which will have specific information about a host - address records and WHOIS are the current planned ones, but this is totally extensible in the future, since any fields that aren’t understood are quietly ignored. The regex-based system means arbitrary and fine-grained control over resolution. It also means you can set up custom roots that reuse a lot of the same downstream branches.

You need consensus to change any document in the tree, and only participants can make changes. So, for example, RI is going to need other people’s confirmation that *.ri.hype does point to the branch that we own. But we have free reign within that branch to rule it as we see fit, which for the most part is administrating the IP information for addresses we actually run sites and services on, and a user registration service so that anyone can make their RILink device accessible by domain name as part of the 15-minute setup procedure (optional, but awesome).

The more central or important a branch is, the more people will be brought in as participants, so that core changes to the internet cannot happen without the consent of the internet. The system is also specifically designed this way, so that small-time people can become part of the DNS ecosystem with no real overhead. The parts that need protecting are protected, without requiring massive verification of little stuff. If you run an important site, this is an important way to protect your site from being hijacked by vandals or bitter insiders. You bring in the people you want, and they help keep you safe. And when you do need to orchestrate a change, once it goes through, the update is pushed in a distributed fashion around the internet in real time, meaning no waiting for TTLs to expire.

And this protects the freedom of the internet?

Yes. It puts the power of DNS in the hands of the people, instead of a central few. I’m not saying the central few are necessarily bad guys, but whenever you have a small pocket of decision makers in charge of a massive amount of power, you’ll always have someone looking to threaten and/or bribe those decision makers, and it will be a feasible proposition to do so.

Importantly, it does this in a way that still allows for absolute authoritarian systems in small pockets across the system, without compromising the populist-y values at its semi-literal roots. It’s fully compatible with “I rent a space from people with the authority to rent it to me” philosophy, while that philosophy is incompatible with hosting pockets of freedom inside it. Like many cases, the free, distributed system is the clear conceptual winner, not only in a practical sense, but an ethical one.

How does RI plan to use this in special ways? I was paying attention at the beginning, and was intrigued.

Like I said somewhere in the wall of text above, one of the features of RILink setup will be establishing an FQDN for your RILink device. Thanks to DJDNS, this will be easy, free, and with clear ownership semantics. Your DJDNS leaf will have one participant with write permissions - your RILink’s EJTP identity (randomly generated earlier in setup) - and one without, our RI bot, so that the information is always consistently available. You can change the information to whatever you want. The *.ri.hype branch will be owned by an RI bot and a few admins, and will create a regex pointing to your leaf. Don’t trust us? You can point as many other domains as you want toward the same leaf node, which you own by default as the sole participant with write access.

This is perfect for setting up a casual site, then getting serious about it later, with verification through trusted friends and/or supportive community. It also means that we have moderation for which sites are available as myfoo.ri.hype domains, but in a fair way, so we can cut the spam without being bad guys.

That sounds great! So where are we at so far?

Aaannnnddd back around to the whole reason I’m writing this blog post. It only took 3 pages of introduction to get here, too. Nifty.

python-libdeje v0.1.0 is a milestone. A surprisingly important one too, considering that the software is still in a state of “so young it’s crap.” I’m not gonna sugarcoat this at all, the reference library for DEJE is still embarrassingly far from production-ready, and will be for some time. This version is basically “it works if you hold it the right way and don’t do anything weird.”

But that’s what’s cool, it actually works enough that I can start using it as the foundation for DJDNS, and get that much of a head start toward a working technical demo of the DJDNS system. So I need to move the identity code into my EJTP library, the Lua sandbox basically doesn’t exist, and there’s still a boundless quantity of edge cases lying in wait to break the application. It’s wobbly, but it’s just stable enough to play with, and a real-world usage means more testing, more stability, and prioritization of objectives across the stack. It means a driving force that makes the entire EJTP/DEJE ecosystem a friendlier and saner place to develop. And it shortens the gap considerably between “isn’t this a cool idea?” and “isn’t this a cool proof of concept?”

Summarized, it means that if I find the time for it, tomorrow can be my first day working on DJDNS, instead of the foundation underneath it.

Long live the internet.