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.
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.