Discussion
Loading...

Post

Log in
  • About
  • Code of conduct
  • Privacy
  • Users
  • Instances
  • About Bonfire
洪 民憙 (Hong Minhee) :nonbinary:
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social  ·  activity timestamp 22 hours ago

A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent a follow request—but the Accept never came back, even though they hadn't enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.

I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.

This matters because Fedify implements a double-knocking mechanism—if a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.

I filed two issues on the Bonfire #ActivityPub repo—one requesting RFC 9421 support, and one about returning 401 on invalid signatures. For the latter, I also sent a PR, which got merged pretty quickly: bonfire-networks/activity_pub#9.

That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.

One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as “supports RFC 9421”—because they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.

After all that, the mutual follow went through and my DM reply landed. Worth it.

#fedidev #fediverse #Hollo #HackersPub

  • Copy link
  • Flag this post
  • Block
julian
julian
@julian@activitypub.space  ·  activity timestamp 18 hours ago

@hongminhee@hollo.social interesting... but if you send cavage-12 as the first knock, and it is accepted, then how will you know if the server supports the 9421?

  • Copy link
  • Flag this comment
  • Block
洪 民憙 (Hong Minhee) :nonbinary:
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social  ·  activity timestamp 17 hours ago

@julian That's a fair point; honestly, right now there's no reliable way to know. If a server supports both RFC 9421 and draft cavage, and you lead with cavage, you can't infer anything about its RFC 9421 support from a successful response.

The workaround I applied is intentionally temporary, just to keep things working while Bonfire instances catch up with the fix. Once they do, I'll revert firstKnock back to RFC 9421.

The longer-term answer to your question might be FEP-844e, which proposes a capability discovery mechanism—servers could explicitly advertise which specifications they implement (including RFC 9421) via an Application object. That would make the guesswork unnecessary. It's still a draft, but worth keeping an eye on.

  • Copy link
  • Flag this comment
  • Block
silverpill
silverpill
@silverpill@mitra.social  ·  activity timestamp 11 hours ago

@hongminhee @julian

>you can't infer anything about its RFC 9421 support from a successful response

In theory, a server that implements RFC-9421 may add Accept-Signature header to the response

RFC 9421: HTTP Message Signatures

This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.
  • Copy link
  • Flag this comment
  • Block
julian
julian
@julian@activitypub.space  ·  activity timestamp 17 hours ago

@hongminhee@hollo.social ah yes, implements would be a good thing to support. It would allow you to cache the value temporarily (maybe a quick recheck every 7 days or so) so as to avoid needing a double knock at all.

Caching based on first knock success also works.

I wonder if sending HTTP 426 is doable too... 🤔

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/426

426 Upgrade Required - HTTP | MDNMDN

The HTTP 426 Upgrade Required client error response status code indicates that the server refused to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.
  • Copy link
  • Flag this comment
  • Block
Elena Rossini on GoToSocial ⁂
Elena Rossini on GoToSocial ⁂
@elena@aseachange.com  ·  activity timestamp 22 hours ago

@hongminhee not all heroes wear capes... thank you for your phenomenal work!!!

  • Copy link
  • Flag this comment
  • Block
洪 民憙 (Hong Minhee) :nonbinary:
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social  ·  activity timestamp 22 hours ago

@elena Thanks! 🥰

  • Copy link
  • Flag this comment
  • Block
🫧 socialcoding..
🫧 socialcoding..
@smallcircles@social.coop  ·  activity timestamp 22 hours ago

@hongminhee tangential..

> Classic interop bug.

Classic protocol decay bug.

  • Copy link
  • Flag this comment
  • Block

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances
Bonfire social · 1.0.2-alpha.34 no JS en
Automatic federation enabled
Log in
Instance logo
  • Explore
  • About
  • Members
  • Code of Conduct