I released a major DJDNS feature today, and while it’s still a bit rough, it should be serviceable as a base for the next steps of decentralization. In case you haven’t heard the news already, it’s the ability to store EJTP Identities in the DJDNS registry, and retrieve them over a simple HTTP API.

Normally this would feel like a big deal on its own (which it is) rather than just a stepping stone to the “real stuff”, but that’s crunch time for ya.

What is it?

When DJDNS is decentralized, it will use the EJTP Identity Format to store the cryptographic key information of the participants, and verify that a user’s actions are their own. Authentication is extremely important. The question is, where do you store this information, so that everyone can retrieve Identity objects as they need?

The answer is - in the DJDNS registry itself! It’s a perfect place to store arbitrary data associated with domains. And when you have an Identity name in email format, such as “this@that.com” (which is the Identity name convention)… well, hard to get more “associated with domains” than that. DJDNS can look up cryptographic identities in the same data (and mostly the same way) as it does IP addresses.

When will this be working?

It’s working now! I’ve had this up most of the day, I’ve just been holding off on announcing it until it was a bit more documented, and the tooling was a bit smoothed out.


How do I use it?

Retrieving identities

The API server will run on port 16232 on any DJDNS installation (port number will eventually be configurable). Since this is a very primitive API, with no transport security of its own, it is recommended to either run your own local DJDNS server to make your requests over localhost, or connect to a server over Hyperboria.

Eventually we will have native support for key signatures and/or transport security. For now, this is still kind of a hack to bootstrap the decentralized registry.

Storing identities

There are 2 main steps to this. First you have to make an identity, then you have to store it in the registry.

Making an identity

After installing the latest version of EJTP via git, run ejtp-identity new-interactive to create a new identity. It walks you through every step, trying to explain the purpose of each part. It’s still a rough tool - trust me on this, you want a 1024bit RSA key - but at the end, you should have a cache file with your Identity in it.

Now, you don’t want to publish your private key, so you need to make a public version to work with, as follows:

ejtp-identity details -ep yourname@domain.com \
    --cache-source="/path/to/cache" > public.cache

…filling in your Identity name and cache file location accordingly.

Adding it to the registry

Now that you have something to add to the registry, it’s time to do so. Mostly, this is the same as any change to the registry - you edit your private page, submit the changes as a pull request to Github, and I pull the changes. The only potentially complicated bit is, what changes am I making to my private page?

Look at my page or the documentation for reference. You’re adding the contents of your public cache file, to the branch with the matching domain, under the key “users”. IF YOUR IDENTITY NAME’S DOMAIN DOES NOT MATCH THE BRANCH, YOUR IDENTITY WILL NOT BE ACCESSIBLE.

While I refuse to make any adjustments on your behalf for this kind of thing (I don’t want any question about whether I’ve tampered with the crypto data), I’ll definitely help you make sure your page is set up right, verify that your identities are accessible, etc.

When it’s merged, I’ll give you a link in the github comments, to the API URL where people can download your public identity data. It’s pretty easy for you to figure out on your own, but why not get straight to the celebrating and the reassurance of “oh god it works”?

What did it take to make this work?

  • Add my own identity as a demo
  • Traversal support in DJDNS
  • HTTP API server in DJDNS
  • EJTP new-interactive wizard
  • What feels like lots of documentation, but probably still isn’t enough.

What’s next?

Next, I have to clean up the DEJE protocol into some sort of working state again. I kind of made a mess with a halfway-done protocol refactor, which I’ll have to cut short by either aborting the refactor for now entirely, or hurrying to finish it. I’m not totally decided which yet.

Then, it’s a matter of setting up HTTP bootstrap to download initial, verifiable copies of DJDNS pages, which we can then sync-to-current-version over the DEJE protocol thanks to easy access to EJTP identities.