I’m very happy to announce that, if you are seeing this post, then this blog has been successfully migrated from Hyde to Hugo! This will be a big deal for making it easier to write blog posts, and hopefully I’ll write more often.

There’s still a few more things to do here and there:

  • Use media queries to improve the way the site looks at low widths.
  • Add hover menus for ‘posts’ and ‘tags’ nav items.
  • Watch the logs to make sure that my redirects are working, because the URL scheme has changed.

But in general I’m quite proud of this. It looks better, the entire site structure and theme was built from scratch, and it makes more sense.

That’s cool, I guess. Are you working on anything that’s actually useful?

I’m glad you asked!

I’ve been basically neglecting my email for days, so I’m sure I’ve got plenty of work queued up there, but I’ve been making a bit of progress on various projects.

The ones that are relevant to this audience would probably be:


I’ve done a bit of work to stand up the new server. When it’s ready, it will be a standalone domain. I have already set up DNS, so anyone who wants to find it probably can, but I’d prefer people don’t play with it for awhile. I’m trying to work out all the kinks before opening it up to the public. Migration seems to be not as tricky as I expected, but there are still some login complications, and I want everything to just work properly when people start to use the new site.

All your data and accounts will still exist on the new hosting, it’ll just be less buggy, more up-to-date, and support more codecs. Some features may be turned off for stability, like OpenID. Also, if it does kill the VM with its tremendous peak memory demands, it will fall over in isolation - it won’t take my primary site down with it to the wait-for-reboot limbo world.

Once the site is properly migrated, I plan to do a blog post laying out how I did the migration, things learned, etc. I might do the same for this blog conversion at some point, but I think so much of those experiences were specific to my situation, that there wouldn’t be much generally useful content to write :/


Still working on this. I’m very close to being able to host the root page with DEJE. The trick is that there isn’t currently a mechanism to sync the DEJE document to the latest update, and that needs to be written, at least in some security-broken placeholder way.

  • Observing and recording events from the network: WORKS
  • Navigating document to a specific event: WORKS
  • Choosing an event to navigate to during init: NOT IMPLEMENTED
  • Automatically detecting tip event as new events come in: NOT IMPLEMENTED, BUT COULD EASILY PLACEHOLDER
  • Serving DNS off of a single non-recursive page: WORKS
  • Using static JSON for page data: WORKS

So I’ve got this internal conflict about which side I should be pursuing next - the DJDNS side (Yay, pages from DEJE data! Except they’d all be blank and useless!) or the DEJE side (docs actually sync as events come in).

I’m also pondering some architectural inspirations from git, for modelling the way that syncing works, but I think that would just be rambling in the context of this blog post.

Sounds like you’re going to be busy.

Yes I am!

Can other people help?

Not with the GMG or blog stuff, as far as I’m aware. But hopefully I’ll be able to find some ways to delegate the work on DJDNS and its component parts. I’m going to add a CONTRIBUTORS.md file to list all the people who have ever contributed to the project, which I think I should have done with previous projects, and wish that I had.

Anyways, enough words. Time to publish. Hopefully will not break my entire site. See y’all on the other side!