Fix federation with Pleroma (take 2)

[alexgleason]

Supersedes #313, but I wanted to make a separate PR so the solutions could be easily compared. See the original for more context.

Pleroma has a bug where (created) is not an acceptable component to sign. This leads to a conundrum, because Date is a "forbidden" header name according to the fetch spec.

At the same time, Mastodon requires that Date or (created) be part of the signature. So if you choose (created), federation with Pleroma breaks. If you choose Date, you violate the fetch spec.

Trying to set (created) as an actual header throws. But setting Date and removing (created) actually works.

I am running this code in Deno, not a Cloudflare worker. There I am able to set the Date header just fine, and federation works perfectly with Mastodon, Pleroma, and Misskey. I tested all 3 this time.

[xtuc]

@alexgleason are you runing wildebeest in Deno or just some code?

[edevil]

Has the Pleroma bug been reported? It seems it would make more sense to fix that.

[alexgleason]

Has the Pleroma bug been reported? It seems it would make more sense to fix that.

The http_signatures library is hosted on Pleroma's closed GitLab. It's not possible to open an issue. Furthermore Pleroma releases come about once per year at the current rate, so it's much more likely to be fixed on the Wildebeest end. Even then hundreds of Pleroma servers won't update.

are you runing wildebeest in Deno or just some code?

I'm running the same code in a Deno custom ActivityPub server. It needs to be verified that a CF Worker can set the Date header. But if federation with Mastodon still works after this change, Pleroma should work as well.

[vpzomtrrfrt]

Yes, it would be nice if Pleroma supported the newer spec, but they're far from the only ones, and most implementations seem to send Date to maximize compatibility: https://arewehs2019yet.vpzom.click/