@mro @evan @julian @fedify

P.P.S. My latest blog post about #ActivityPub fediverse contains a "Back to (potentially radical) simplicity" call-to-reflection (among other subject matters) .. https://social.coop/@smallcircles/116368803389082089

Solution is.. difficult, but simple, yet not easy.

#SX #SocialCoding #ParadoxOfEmergence

@smallcircles @mro @julian @fedify I'm glad you enjoy thinking through these issues. Good luck with your blog post!

@gabboman I decided to hack on this the past few nights, and came up with an experimental, backwards-compatible implementation that I created a draft pull request for @peertube/http-signature. I tried to follow the library’s coding style of the original as much as possible.

The idea of backwards-compatibility is that you can drop this into an existing application and nothing will break. There are deprecation messages that may surface in logs to guide changing from using the function exports to the cavage12Draft export (and the rfc9421 export).

I think the next step for anyone would be:

• manual...

@gabboman I decided to hack on this the past few nights, and came up with an experimental, backwards-compatible implementation that I created a draft pull request for @peertube/http-signature. I tried to follow the library’s coding style of the original as much as possible.

The idea of backwards-compatibility is that you can drop this into an existing application and nothing will break. There are deprecation messages that may surface in logs to guide changing from using the function exports to the cavage12Draft export (and the rfc9421 export).

I think the next step for anyone would be:

• manual...

When last I left off, I made a pull request to peertube/http-signature library try to help the JavaScript ecosystem reach RFC 9421 parity while being backwards-compatible with cavage-12 draft implementations. There has not been any traction on this yet. Maybe because PeerTube has abandoned its own use of the library.

So our current ecosystem state is the following:

• PeerTube uses misskey-dev/node-http-message-signatures library and owns the defacto unmaintained peertube/http-signature library.
• Misskey and the rest of the ‘keyverse use peertube/http-signature library and Misskey owns the defacto...

I did a quick experiment, and I think there are too many differences to make this an easy swap out library. It would take a lot of refactoring in wafrn to make use of fedify’s library, for instance.

Hi @julian, you mean my pull request into peertube/http-signature? Have at it. Working with the test framework that the original library is annoying.

Recently I found that I made a mistake requiring alg signature parameter in my RFC 9421 implementation, which I carried over there, but that node library also requires it.

@julian No, TritonDataCenter/node-http-signature, the original http-signature npm lib, that PeerTube forked doesn’t support RFC 9421.

When last I left off, I made a pull request to peertube/http-signature library try to help the JavaScript ecosystem reach RFC 9421 parity while being backwards-compatible with cavage-12 draft implementations. There has not been any traction on this yet. Maybe because PeerTube has abandoned its own use of the library.

So our current ecosystem state is the following:

• PeerTube uses misskey-dev/node-http-message-signatures library and owns the defacto unmaintained peertube/http-signature library.
• Misskey and the rest of the ‘keyverse use peertube/http-signature library and Misskey owns the defacto...

@mradcliffe Does your instance support RFC-9421 verification?

@silverpill It should, but it isn’t node.js based.

I wanted to help the node.js ecosystem by making peertube/http-signature backwards-compatible for both draft and RFC-9421.

Although I apologize that I am requiring alg.