i've been trying to move primarily onto self-hosted stuff lately, getting away from discord and whatnot. i recently remembered that bluesky's atproto stuff is all federated so you can selfhost your own data server for it. i also thought it might be fun to have a .periwinkle.sh account on there anyway.
foreshadowing is a literary technique-
i went and looked around and it seemed like it was gonna be really easy to set up a bluesky pds (personal data server). there's just one script to run and it just deals with everything for you, all you need is a public ip and a wildcard dns record-
well, this is going to be complicated. i can't exactly point *.periwinkle.sh at some other server for the bluesky pds, considering how many other services are going through subdomains of that.
also, the setup scripts just end up using a docker-compose mess to start everything, which is, well, not ideal for my setup. really i need to be able to run it in an lxc on my proxmox host. what is an alpine lxc but a complicated docker container? surely this can't be that hard
and it wasn't that hard
actually getting everything set up and running was really easy! i just had to, uh, reverse engineer the installation scripts and the dockerfile. i even ended up having to read the pds source code to figure out some environment variables that weren't mentioned anywhere else. bluesky, guys, i admire the open sourciness and support for selfhosting, but can you PLEASE write some documentation that isn't targeted at people who have never seen a computer before? there's multiple places where the exact same instructions are posted, and they boil down to "click a button on digitalocean". come ON.
well, regardless, luckily i've seen a computer before and was able to dig through it and work it out. next comes the hell of getting it to actually interoperate and function properly. first i needed to be able to send email, which is neither here nor there but i got it set up in an extremely hacky fashion after figuring out that oracle cloud (my vps hosting provider) blocks smtp traffic. come on, guys. that's not very nice.
the real pain
the real pain comes from all of the domain/subdomain/verification nonsense. i put the pds itself behind pds.periwinkle.sh since it needed somewhere to be. however, this makes it so that the accounts created on it are foobar.pds.periwinkle.sh. this is ok but not very pretty, i wanted foobar.periwinkle.sh. Ok, all good, atproto lets you have either a DNS TXT record (not very scalable) or a .well-known path to verify a handle-domain.
unfortunately, the .well-known path is per-SUBDOMAIN, and is always /.well-known/atproto-did. i had to implement some nightmare hacky stuff in nginx config to extract the subdomain from the domain, and use that to look up the atproto did to return. it... works...? i'm a little worried but it could be worse.
however, this runs me into the next subdomain problem: all of these subdomains need HTTPS. i don't have a wildcard cert, I just use letsencrypt, which means manually adding certificates for myself (and other potential users on my pds). eh, not the worst, i think their ratelimits are nice enough.....
finally, i wanted to change my handle from peri.pds.periwinkle.sh to peri.periwinkle.sh..... and it refused to work. why won't it work? i had everything: well-known paths set up to return the right thing, certificates for pds.periwinkle.sh and peri.periwinkle.sh, verified email on my account (verification email sent from my pds!) and, well, why won't it let me change it?? it just said "try again later" and the logs were. unhelpful. just saying that there was an error in updateHandle. great. love you.
so... what was the problem? it turns out i ALSO needed a certificate for peri.pds.periwinkle.sh or else it couldn't verify the previous handle on my pds!
i know it makes sense but it's a bit ridiculous if i need to create two separate ssl certs to create a single, nice looking account. and then i need to delete one of them, since the account peri.pds.periwinkle.sh no longer exists.
ALSO, to get it to behave correctly when changing the handle, the /.well-known/atproto-did path needs to be able to go to BOTH the original PDS and my custom backend for .periwinkle.sh. i implemented this with some acls in haproxy. dude, i'm starting to have quite a lot of haproxy acls for stupid edge cases in running lots of services from the same domain. i'm sure it's fine.
the end
also if you're my friend you can have a .periwinkle.sh bluesky handle if you want