You can't follow me
so.nwalsh.com
so.nwalsh.com
It feels like the author has their own preconceived notions about how systems ought to be "isolated"[1], regardless of the use case, keeps fighting with their half-baked networking implementation and then denounces everything, ranging from HTTPS[2] to now ActivityPub as "broken".
It triggers me a little when folks complain about HTTPS. Nowadays you have a wealth of tools to trivialize TLS certificate tasks.
Public TLS cert? LetsEncrypt + certbot (or any of the other zillion great ACME clients/libraries out there).
Self-hosted PKI for private/test use? Smallstep CLI (https://smallstep.com/docs/step-cli/) is good. And honestly, the raw `openssl` commands to barf out a root selfsigned cert aren't that difficult and number as less than 5 shell invocations that you could have in your history or a bash function or something.
Self-hosted PKI with extra steps that you already did because you have a Kubernetes cluster for some other reason? cert-manager will take care of pretty much everything.
These days the "hardest" part is sneaking your CA chain into the appropriate browsers / services you're using/testing, but even that is a few moments of inconvenience at best.
For browsers, importing certificates comes down to just searching "certificate" in the settings. It's everything else that's broken, in my experience.
The default solution doesn't work on a shared host where you don't have control over running your own services and opening your own ports, only serving static pages instead using a shared web server.
Trivialize what? You have to learn the tools. When you're paid for it or actually believe that signing everything is useful, you're willing to spend the time.
In the original article it looks like the poster already went over their time budget by a lot without even getting to researching if these tools exist.
As you say, Docker would be great for that, as they say they use in your linked [1]. Did you read it?
I wouldn't read too much into these posts. These are days apart and read more like inner-monologue from setting up systems. My process for implementing someone would probably fare the same. You wade through the cruft, complain about some things, but it gets done in the end and it's always nice to solve the pain points later.
As you say, the inner monologue writing style of "I have this server and this thing and tried this and also I don't like this" may have led me astray as it didn't feel particularly focused, so it wasn't super clear what the complaint actually was.
Makes me wonder if inner-monologue type stuff is even useful to post to the internet (something ive wanted to post more off because it sucks less energy from writing motivation). Takes more effort to parse as a reader though...
It does feel like this sometimes.
In the past, we would then throw up our hands and say "Well boo on them for making their system hackable; sounds like their problem." But when you factor in the damage that can be done on the internet with things like botnets, it becomes everyone's problem. So sometimes people refrain from adding the escape hatches because they intend to work in an ecosystem of "You must be at least this technically savvy to play."
No, he's not trying to integrate into a global distributed system without a connection to the internet. He's trying to test locally an app that will eventually integrate into a global distributed system.
It's a valid complaint. If I have a local Mastodon server, and a local static website, why can't I just make the two talk without going through the public internet, or adding a self-signed CA to a bunch of trust stores?
It seems to me like it wouldn't be hard to add a --dev flag to Mastodon that allowed you to forgo the TLS certs, and it would make testing much easier. He's not trying to
https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....
Sure you can. Getting a valid, trusted certificate from a public entity doesn't mean that your service has to be public. Just get one and assign private IPs to the domain.
I get the idea of not doing that if you want to be a purist about the isolated approach. But then you should be ready to implement something that others don't care about as much as you do.
“put everything online” here is hand-waving the hard part. Most people are used to working in development environments that are not set up to serve inbound traffic from the public internet. There are security implications. In most of my past jobs, it wouldn’t have even been an option without violating IT policies.
It almost feels as if “online” is a centralized system.
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
[2] https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
Broadly yes, except Safari which still sometimes doesn't: https://bugs.webkit.org/show_bug.cgi?id=171934
(Not relevant to this case, but eugh it's a very annoying exception)
As for the HTTPS thing: last time I messed with ActivityPub, I solved that problem with a Let's Encrypt wildcard certificate that I copy between hosts, but there are ActivityPub servers that will let you run in debug mode and federate over HTTP.
I think the problem with implementing ActivityPub is that the protocol looks deceptively simple at first glance, and people seem to expect it to be somewhat like RSS. However, when you actually start implementing it, you realise how many edge cases the protocol needs to deal with (and doesn't deal with).
The signature is a relatively small hurdle (it's an RSA public key encoded in base64, almost every language I know has a library to do the hard parts) but it's one of many. ActivityPub isn't a protocol you just tack onto your code in an afternoon, especially if you don't like using external libraries, even if it looks like it's just a bunch of JSON.
A similar level of cross-platform library support for ActivityPub would greatly ease its adoption across the universe of Internet applications.
Perhaps there's something like that now again, but last I checked, the protocol got quite a bit more complex in its requirements, so there was no ready-to-go option, everything required a lot of manual testing and adaptation.
The protocol has been wrapped a whole bunch of times in various languages, but I don't know what protocol this particular blog uses, so I can't comment on what would be appropriate.
Heh. If you look at the problem like this, I believe you have already implemented it wrong. The signature has an algorithm that you can specify, but sadly Mastodon only accepts RSA 256 keys which then rippled into the wider ecosystem and everyone is just accepting those. Sigh. A valid HTTPSignature can be built using almost any key algo, the fact that servers only accept RSA is an endless frustration of mine.
Very few ActivityPub servers are actually spec-compliant, but unless Mastodon loses its leading position, I don't think we'll see spec compliance become relevant soon.
(I would not really recommend it for general use, unfortunately, since it's a pile of C that's not really all that secure. But as a publicity stunt we run @ish@ish.app inside of iSH itself, and snac turned out to be excellent for this because iSH is slow and doesn't implement all of Linux, so picking something simple and lightweight was a must.)
Simplest solution is to use something like https://mastofeed.org/ which automatically posts your RSS feed to Mastodon.
Of course you can also do it yourself. Posting to an existing mastodon account is just a single HTTP call with an API key: https://docs.joinmastodon.org/methods/statuses/#create
One thing to consider would be to try to use Caddy [0], or a tool like localias [1], as a local https proxy. You would be able to run both the mastodon server and your blog software on the same computer, addressable via local-only urls like "https://blog.test" and "https://mastodon.test" and have everything work. These tools manage the certificates for you transparently and you don't need to worry about anything being exposed publicly.
I'd be curious to know why the author didn't try this, they seem to be quite knowledgeable of other web technologies so I have to assume there's a problem that I'm not seeing here.
I've had some success with mkcert [1,2] to easily create certificates trusted by browsers, I can suggest to look into this. You are your own root CA, I think it can work without an internet connection.
Some of these issues seem avoidable though? The author seems to be diving too far into the testing rabbit hole. For my workflows, I generally find holistic integration tests to be too time consuming and not worth it, for the level of fidelity I want (I'm not NASA/bug-free). Same with trying to avoid testing on prod. It might not be "clean" but for a site like this it seems like a reasonable tradeoff.
https://leo.fm/2022/02/isitover/
Click on the "Load comments", you can see that it does request to Mastodon server, in this case, twit.social to fetch the comments. Because most Mastodon servers have CORS allowed to all sites, it's pretty easy to do.
but yes, non-local runtime dependencies in software which you thought you set up to be local-first have a real habit of sneaking in. the wildcard cert solution only masks that non-local runtime dependency, visible by disconnecting the server from the network for 90 days at which point your cert expires and it'll fail again.
Another gripe with the technical implementation of mastodon is the CORS headers required to access the ActivityPub API [0].
Because of this issue, an activitypub-aware frontend for mastodon has to have its own mastodon server running, which adds a whole bunch of hurdles.
There are a whole bunch of technical implementation details that I disagree with when it comes to Mastodon. I wish the many MissKey forks would stabilise, because it seems a lot saner (yet every time I consider setting up a server, there has been a new fork thst everyone is switching to).
I mean, we can all have opinions about TypeScript, but converting from TS to JS is far from a hurdle.
I wish they would dedicate a modicum of attention of being a better Fediverse citizen now that they have people they employ.
Sounds like a feature, not a bug. What am I missing? You could generate self-signed certificates to make life a bit easier.
The article’s OP is wrong here:
> So to test this, I’d need both ends of the communcation [sic] to be on the public internet with proper certificates.
That is false. If you setup Tailscale (or Headscale, if you want a self-hosted endpoint), all communications are made with CGNAT address space (you hit neither the public internet nor your private network), and still get HTTPS certificates (from Tailscale’s ts.net ACME-friendly subdomain).
Basically: use a VPN service which handles both TLS certificates and NAT traversal, and you can do your secure local tests all you want.
Caddy (a webserver which, surely, the OP of this article must be using, if he’s serious about keeping things simple) comes with Tailscale support built-in, so you get your automatic HTTPS (ACME) with one line of configuration (adding `machinename.tailnet-name.ts.net` in the Caddyfile).
For fun, here’s the full configuration file for a server which serves a “what is my IP” service over HTTPS, only served when you are connected to your VPN:
server1.cat-crocodile.ts.net {
templates
respond "{{.RemoteIP}}"
}
Do you think installing software, clicking on a few links + a button (switch) on a website, and writing one line of configuration is unreasonable or complex?