Some Fediverse Notes (with some cat pictures because no one likes a wall of text)

Social media, as it’s called nowadays, hasn’t been fun in a long time, and I haven’t participated in a long time because of that. I used newsnet quite a bit back in the day (you can still find lots of my old posts on comp.sys.hp48), and of course, I’ve used IRC as well. I even had myspace and facebook pages at one time, awful though those websites are.

But, with the recent apparent implosion of twitter (the eternal flames of its dumpster fire are burning ever brighter as I type), usage of the fediverse finally seems to have finally taken off. I’ve long looked at the twitter pages of lots of science fiction authors to keep up to date with their work and get recommendations, and so will naturally follow them into the fediverse.

Like most normal people, rather than just get an account with one of the many, many instances that have cropped up, I chose instead to set up my own. Here, then, are some notes about how I’ve gone about it (not exhaustive — if you want that, just send me a note and I can provide more pointers).

I’ve run our mail server for many years, first on a shared server, and later, when other users on the same server turned into spambots and my mails stopped getting delivered, I got a virtual server with RootBSD (now NetActuate). At the time, they were one of the very few offering instant provision of OpenBSD, and they’ve been an absolutely fantastic provider ever since.

Aside from mail, I also run a variety of web services, from WordPress (this blog!) to cgit and a few others besides. All of those run behind OpenBSD’s httpd.

Given that I’m not using a dedicated server for it, running Mastodon was a non-starter. It’s written in Ruby, which would mean I would need to add support for another scripting language; and I understand it can be pretty resource-intense, and I don’t want to adversely affect the other services on the machine. I chose, instead, to use GoToSocial, a still under heavy development, but much lighter-weight server. Aside from some not-yet developed functionality, the only real downside is it doesn’t have its own user interface, and that just isn’t a big deal.

The configuration I decided on was:

• Subdomain for gotosocial (magpie.rockgeeks.net)
• gotosocial listening on 127.0.0.0 port 4444
• relayd listening on 0.0.0.0 and :: port 443 (HTTPS)
• httpd listening on 0.0.0.0 and :: port 80 (HTTP) and 127.0.0.1 port 4443 (“HTTPS”)

relayd forwards HTTPS traffic either to gotosocial or to httpd, depending on the Host header. httpd itself will redirect to magpie using HTTP 302 for certain well-known paths (webfinger and nodeinfo) — this is how we can have @rockgeeks.net usernames even though our instance is on a subdomain.

relayd.conf

# Macros to make the below a little easier to read
ext_addr="0.0.0.0"
ext_addr6="::"
tls_port="443"
httpd_port="4443"
gotosocial_port="4444"

# Sets of hosts for redirecting
table <gotosocial> { 127.0.0.1 }
table <httpd>      { 127.0.0.1 }

# Protocol definition for our relays
# This has access to the HTTP headers
http protocol https {
     return error

     http websockets

     # ... various other rules

     match request header set "Connection" value "upgrade"
     pass request quick header "Host" value "magpie.rockgeeks.net" forward to <gotosocial>

     pass request quick header "Host" value        "rockgeeks.net" forward to <httpd>
     pass request quick header "Host" value    "www.rockgeeks.net" forward to <httpd>
     # ... other subdomains
}

# IPv4 relay
relay https {
      listen on $ext_addr port $tls_port tls
      protocol https
      forward to <gotosocial> port $gotosocial_port
      forward to <httpd> port $httpd_port
}

# IPv6 relay
relay https6 {
      listen on $ext_addr6 port $tls_port tls
      protocol https
      forward to <gotosocial> port $gotosocial_port
      forward to <httpd> port $httpd_port
}

httpd.conf

# Main website config (HTTP)
server "rockgeeks.net" {
       listen on * port 80

       alias "www.rockgeeks.net"

       location "/.well-known/webfinger" {
                block return 302 "https://magpie.rockgeeks.net$REQUEST_URI"
       }

       location "/.well-known/nodeinfo" {
                block return 302 "https://magpie.rockgeeks.net$REQUEST_URI"
       }

       # ... other directives

       location * {
                root "/rockgeeks.net"
       }
}

# Main website config (HTTPS)
server "rockgeeks.net" {
       listen on 127.0.0.1 port 4443 # https via relayd

       # no "well-known" paths here, relayd will have handled them already

       # ... other directives

       location * {
                root "/rockgeeks.net"
       }
}

# ActivityPub subdomain, but HTTP, so just redirects
server "magpie.rockgeeks.net" {
       listen on * port 80

       location "*" {
		block return 302 "https://$HTTP_HOST$REQUEST_URI"
       }
}

# There is no HTTPS entry for magpie.rockgeeks.net

There’s a bunch more stuff in the real httpd.conf, e.g. ACME paths for certificates, other subdomains, etc., but this is the relevant bit.

gotosocial.yaml

# The host/account-domain pair enables our usernames to just be @rockgeeks.net
# even though the server is running only on this subdomain
host: "magpie.rockgeeks.net"
account-domain: "rockgeeks.net"

# It's actually using HTTP, but this is used to generate URLs by the server
protocol: "https"

# Only listening locally, relayd handles the redirection
bind-address: "127.0.0.1"
port: 4444

There’s plenty more here as well, but the above is the most relevant.

Now that it’s up and running, you can find us on the fediverse at @jon@rockgeeks.net and @robin@rockgeeks.net