An R&D project I’m involved with has forked freeDiameter. Since forks should be a last resort, I feel the need for some public justification. The fork isn’t driven by delusions of grandeur, but mostly down-to-earth practical considerations and has as explicit goal to upstream all work and dissolve the fork as soon as possible.

The R&D project was spawned by a vision of a future-proofed Internet, described at InternetWide.org. To some extent that can be read as “break the big tech companies and allow everyone to be effectively self-hosting”. It is a tall task, and I poke and prod at tiny bits of it.

One of the bits that you need for self-hosting is authentication and authorization, and some of the protocols for that are RADIUS and its successor / twin protocol DIAMETER. freeDiameter is an Open Source implementation of that protocol. That is the thing which we have forked, for the following practical reasons:

  • The freeDiameter infrastructure is Trac and Mercurial and mailman. Those are lovely and venerable bits of Open Source development – I know I have patches in Trac, and I’ve written Mercurial plugins – but they are not modern collaboration platforms where outside contribution can happen (easily, or at all).
  • The mailing list is down and has been for over half a year.
  • The Trac instance seems to be hosted somewhere small, and regularly times out.
  • Communications with upstream about “we would like to work on this” end up bogged down either with issues with the mailing list, or that upstream doesn’t have immediate interest in the feature this.

So, in order to “get shit done” we have forked onto GitLab, so that we have a modern collaboration mechanism, drive-by-branches, quick response times, etc. Still no mailing list, though, but then we’re not aiming to take over the project, we’re aiming to do some development and then upstream it – when we get to that point we can wrestle with Mercurial again.

There’s some basic infrastructural things we want to do – which may or may not fit with upstream’s plans.

  • Update installation instructions – for instance the FreeBSD ones mention FreeBSD 8.0, released in 2009 and EOL’ed in 2015, as the most recently tested version. Since freeDiameter is packaged and used on FreeBSD, it certainly works on more recent versions. For instance the openSUSE instructions refer to 11.2, which is similarly ancient.
  • Update Debian packaging – Debian ships freeDiameter 1.2.1, which is a few years old. I think there was some really slow development cycles, and Debian has forgotten about this package.
  • Update to modern CMake. Anything that starts with CMake 2.8 compatibility is just asking for a bad time.
  • Integrate packaging fixes that already exist (e.g. in FreeBSD).

There’s one big thing for functionality that we intend to add: multi-domain support. Or put a different way: virtual hosting. freeDiameter ought to be able to support more than one domain at a time, so we’ll be doing the necessary DNS wrestling (the problem is always DNS, right?) to allow deploying one freeDiameter for a drove of domains.

There’s a handful of other things languishing – either in our heads, or in trac – that we intend to implement and then submit upstream, such as:

  • DTLS over SCTP (note: I’m not a networky-person yet, so don’t at me about the acryonyms).
  • Unordered delivery rather than just streams rotation.
  • Peer lookup in DNS.
  • SCTP support in FreeBSD (there’s a kernel module, but then things still don’t work).

Overall the code is good (I do not say this lightly, as a die-hard C++ programmer now reading C code) and the project upstream is fine, only the collaboration parts are letting us (downstream) down. I’ll give a shout when things start landing upstream again.