Discussion
Loading...

#Tag

Log in
  • About
  • Code of conduct
  • Privacy
  • About Bonfire
@reiver ⊼ (Charles) :batman: and 4 others boosted
洪 民憙 (Hong Minhee) :nonbinary:
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social  ·  activity timestamp 3 days 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
洪 民憙 (Hong Minhee) :nonbinary:
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social  ·  activity timestamp 3 days 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
Ben Pate 🤘🏻
Ben Pate 🤘🏻
@benpate@mastodon.social  ·  activity timestamp 3 days ago

@hollo

Very cool, guys! Kudos!

#Bonfire is also working on encrypted DMs similar to Hollo. They’re using MLS, which is similar, but slightly different from the Signal protocol you’re using.

I know it’s a big request, but what are the chances of getting your #E2EE messages to work with Bonfire (and #Emissary) too?

It would be great for the Fediverse to have a unified E2EE standard in 2026.

Let me know if it’s a possibility. I’m happy to tour you through our work so far!

Hollo :hollo:
Hollo :hollo:
@hollo@hollo.social  ·  activity timestamp 3 days ago

@benpate Yes, of course we're interested in #E2EE too! (For reference, Hollo doesn't have E2EE for DMs yet.) We're completely open to collaborating with the #Bonfire team.

  • Copy link
  • Flag this comment
  • Block
fedicat and 1 other boosted
Hollo :hollo:
Hollo :hollo:
@hollo@hollo.social  ·  activity timestamp 3 days ago

The recent Hollo 0.7.3 and 0.7.4 updates have improved interoperability with #Bonfire. The issue where sending/receiving DMs or mutual following with Bonfire wasn't working properly has been resolved.

GitHub

Release Hollo 0.7.4 · fedify-dev/hollo

Released on February 24, 2026. Fixed a federation interoperability bug where follow requests to some Bonfire instances could remain pending even after receiving Accept or Reject activities. Inbo...
GitHub

Release Hollo 0.7.3 · fedify-dev/hollo

Released on February 23, 2026. Temporarily changed Fedify's firstKnock setting to draft-cavage-http-signatures-12 for outbound inbox deliveries as a compatibility workaround for Bonfire's current ...
  • Copy link
  • Flag this post
  • Block
Hollo :hollo:
Hollo :hollo:
@hollo@hollo.social  ·  activity timestamp 3 days ago

The recent Hollo 0.7.3 and 0.7.4 updates have improved interoperability with #Bonfire. The issue where sending/receiving DMs or mutual following with Bonfire wasn't working properly has been resolved.

GitHub

Release Hollo 0.7.4 · fedify-dev/hollo

Released on February 24, 2026. Fixed a federation interoperability bug where follow requests to some Bonfire instances could remain pending even after receiving Accept or Reject activities. Inbo...
1 more link(s)
Ben Pate 🤘🏻
Ben Pate 🤘🏻
@benpate@mastodon.social  ·  activity timestamp 3 days ago

@hollo

Very cool, guys! Kudos!

#Bonfire is also working on encrypted DMs similar to Hollo. They’re using MLS, which is similar, but slightly different from the Signal protocol you’re using.

I know it’s a big request, but what are the chances of getting your #E2EE messages to work with Bonfire (and #Emissary) too?

It would be great for the Fediverse to have a unified E2EE standard in 2026.

Let me know if it’s a possibility. I’m happy to tour you through our work so far!

  • Copy link
  • Flag this comment
  • Block
Hollo :hollo:
Hollo :hollo:
@hollo@hollo.social  ·  activity timestamp 3 days ago

The recent Hollo 0.7.3 and 0.7.4 updates have improved interoperability with #Bonfire. The issue where sending/receiving DMs or mutual following with Bonfire wasn't working properly has been resolved.

GitHub

Release Hollo 0.7.4 · fedify-dev/hollo

Released on February 24, 2026. Fixed a federation interoperability bug where follow requests to some Bonfire instances could remain pending even after receiving Accept or Reject activities. Inbo...
GitHub

Release Hollo 0.7.3 · fedify-dev/hollo

Released on February 23, 2026. Temporarily changed Fedify's firstKnock setting to draft-cavage-http-signatures-12 for outbound inbox deliveries as a compatibility workaround for Bonfire's current ...
  • Copy link
  • Flag this post
  • Block
Nelfaneor 🇪🇺 🇧🇪 🫏​✒️​♏​〽️​🟤​ and 8 others boosted
洪 民憙 (Hong Minhee) :nonbinary:
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social  ·  activity timestamp 5 days ago

Hi #fediverse and #ActivityPub developers!

I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.

Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!

#fedidev #BonfireNetworks

  • Copy link
  • Flag this post
  • Block

BT Free Social

BT Free is a non-profit organization founded by @ozoned@btfree.social . It's goal is for digital privacy rights, advocacy and consulting. This goal will be attained by hosting open platforms to allow others to seamlessly join the Fediverse on moderated instances or by helping others join the Fediverse.

BT Free Social: About · Code of conduct · Privacy ·
Bonfire social · 1.0.2-alpha.34 no JS en
Automatic federation enabled
Log in
Instance logo
  • Explore
  • About
  • Code of Conduct