Part 3 of "A Guide to Implementing ActivityPub in a Static Site (or Any Website)" is just out the oven!
In this blog post, I explain how to make your blog discoverable in the Fediverse as an account, and also address some of the annoying pitfalls I encountered.
Because I've been using it quite a bit lately and think it might be useful for some of you, here's a list of #HTTP status codes and descriptions in man page format:
It's not worth bemoaning that #ActivityPub is, in fact, an open protocol.
And this is because it's not worth bemoaning that #SMTP is an open protocol. Or Hypertextual Transfer Protocol (#HTTP) is an open protocol.
Or for that matter that anyone can use these protocols as they see fit.
Do I like every use of these protocols? Not at all. We can't always have good things because shady assholes insist on exploiting the open web for their own greed.
The trade off is that we get to have an open web.
Now occasionally, I get people popping by who tell me, "Screw you! I don't care about an open web! I just want to keep my community intact!"
But the only reason your community exists is because we have open protocols.
If you don't think so, find me all those thriving communities still using AppleTalk or IPX/SPX. Wait. There aren't any.
And that's because the only entities that have bothered with a closed, proprietary protocol happen to be for-profit corporations that have largely discontinued them due to -- again, wait for it -- the prevalence of open protocols.
Which brings us to a further problem.
You can't use an open protocol while simultaneously pushing for it to be closed. The #W3C already validated ActivityPub. The proverbial cat is out of the bag.
So yes, corporations will adopt ActivityPub. That's already happening. #Meta, #Automattic, #Medium, #Flipboard -- many more to come -- are developing for it.
But openness also means you can build upon it. You can create your own thriving communities. And some of these communities can be private if you so choose.
Just as it's possible for you to build your own newsletter or publish your own webpage, it's possible for you built your own #Fediverse server.
Part 6 of "A Guide to Implementing ActivityPub in a Static Site (or Any Website)" is now out.
Sorry about the delay, this is the part that not many people will like, I assume. I try to explain how to implement the inbox, which by nature is dynamic non-static.
🆕 blog! “A simple(ish) guide to verifying HTTP Message Signatures in PHP”
Mastodon makes heavy use of HTTP Message Signatures. They're a newish almost-standard which allows a server to verify that a request made to it came from the person who sent it. This is a quick example to show how to verify these signatures using P…
Maybe I'm an old grumpy #tech guy, but I really don't like massive complicated frameworks that abstract away well known protocols like #HTTP, #GRPC, etc.
I already know those, I can easily write code that does those, why do I have to learn the convoluted #framework way of doing things that would be 10 seconds work if I could just access the basic http library underneath?
Spent the past few evenings on a very different kind of performance optimization: making my website really, really fast -- with a focus on people with slower, higher-latency connections.
I had to learn some things to pull this off, and I thought they might help others, so I've written the process up in a new blog post:
Perhaps this was obvious to you, but it wasn't to me. So I'm sharing in the hope that you don't spend an evening trying to trick your webserver into doing something stupid. For years, HTTP content has been served with gzip compression (gz). It's basically the same sort of compression algorithm you get in a […]
🆕 blog! “I made a mistake in verifying HTTP Message Signatures”
It's never great to find out you're wrong, but that's how learning and personal growth happens. HTTP Message Signatures are hard1. There are lots of complex parts and getting any aspect wrong means certain death2. In a previous post, I wrote A simple(ish) guide to verifying …
Une explication détaillée de HTTP3. La principale différence est qu'il utilise UDP + QUIC + TLS au lieu de TCP + TLS.
QUIC vise à moderniser et remplacer TLS, mais pour garder une compatibilité maximale avec les équipements réseau (routeurs, firewalls, etc.) UDP est nécessaire.