ri/blog

The last few days have been pretty tough. I’ve been pushing myself hard, trying to make up for the lack of focus I’ve had over the last couple months. My worth in the community is under attack and I am struggling to maintain a place in it, which means fighting back and hoping that things work out.

That said, it’s not all bad - the problems are mostly timing, and having to hold my own in a hostile environment (which I’m not good at, but practice makes perfect, so whatever). The advantages are that I’ve made a lot of significant strides in the DJDNS stack in the last few days, faster than I thought I could do. And I am confident that my solutions have better models than the competitors, so I don’t have any obligation to win the race to completion, as long as the gap isn’t too serious.

Anyways, enough complaining. I’m sure you all want to see the product of my manic upswing.

New documentation

Most of the following overlaps in one way or another with the new DJDNS Reference Documentation, which attempts to illustrate DJDNS’s workings, features, and planned future extensions. If you’re at all interested in DJDNS, you gotta read these.

Identity hosting

I was planning to wait on this until after decentralizing the DJDNS registry, but I realized it made more sense to do this now, and use it to bootstrap the decentralization work, even if it temporarily makes the current repo-registry an even more awkward security problem. Basically, we will be able to store EJTP identities in the DJDNS registry, including encryptor information and bitcoin addresses.

Once this feature is a bit more mature and standardized, it will be exposed via the UNIX Finger protocol, or perhaps WebFinger, depending on What The People Want ™.

See the extensibility DRD for more information.

Paxos-based protocol redesign for DEJE

DEJE, the distributed document system that will be used for DJDNS’s decentralized registry hosting, is adopting a more formal version of Byzantine Fast Multi-Paxos as its consensus platform. I say more formal because I’d happened to reinvent BFMP in an informal, awkward way based on the needs of my application. It was already Paxos, it just didn’t know it.

That said, I do have an as-yet unanswered security concern about traditional Paxos in highly Byzantine environments. It’s on StackOverflow. About the biggest thing you can do to help DJDNS development, right now, is help me find an answer to this question.

EJTP Signatures

Work on the theoretical design of Amino has spurred me to develop a new feature for EJTP - portable signatures. These will come in two flavors - JSON, and binary, where the latter is more compact but less readable.

JSON example

{
    "signer": ["udp4", ["162.18.24.19", 9999], "joey"],
    "hash_algo": "SHA1",
    "contents": "c$\u8805?..."
}

Signer is already associated with a key by more reliable means - there would be no point including the public key here, since what would make it trustworthy?

Binary equivalent

0123456789ABCDEF01234567     ...       0123456789ABCDEF   ...
[ hash ][ signer len   ][ signer json ][ content len  ][ contents ]
  • 1 byte (8 bits) to indicate which hash algorithm, from a published table
  • 2 bytes signer length
  • (signer length) bytes of JSON ASCII (unicode is handled via \u00b0-style escapes).
  • 2 bytes content length
  • (content length) bytes of raw cryptographic signature data.

Like DNS records, binary portable signatures have a length that is variable, but self-describing, so you can have a bunch of them end-to-end without delimiters, and parse them reliably.

Proven DJDNS with Amino

cjd has been hounding me for months about client/server provability, which he believes is a cornerstone of properly implemented DNS. I don’t place the same importance on it, since it’s an easy problem to work around, but I did eventually figure out how to do it.

Provability is not a high priority compared to decentralizing the registry, and it looks like cjd won’t have much use for Amino since he’s using his own specialized/compact wire format in his DNS solution. Which he calls RainflyDNS, as a way of trolling me - thanks cjd. But anyways, the design is there, and it shouldn’t be too hard to implement either side of the API, so it should go fairly fast whenever I get around to it.

Overall progress

The above milestones are listed in the order that I’m working on them. Right now I’ve got the documentation “done”, in the sense that “it’s released and I’m open to pull requests/questions.” The next big step is getting DEJE running. Once DJDNS is decentralized, I’ll have time to care about niceties like Amino.