What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

0
0
0
1
0

Fedify 2.0.0 is here!

This is the biggest release in Fedify's history. Here are the highlights:

  • Modular architecture — The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
  • Real-time debug dashboard — The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
  • ActivityPub relay support — First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
  • Ordered message delivery — The new orderingKey option solves the “zombie post” problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
  • Permanent failure handlingsetOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.

Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.

This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!

This is a major release with breaking changes—please check the migration guide before upgrading.

Full release notes: https://github.com/fedify-dev/fedify/discussions/580

4
6
0

Wir werden immer wieder gefragt, ob wir unsere Server eigentlich auch selber nur mieten. Die Antwort ist ein klares Nein. Wir machen das tatsächlich alles selbst.

Das heißt auch, dass wir dann doch mal umziehen müssen. Mehr dazu und wie es in unseren Racks so aussieht erfahrt ihr in der aktuellen Folge Uberspace: Lower Decks:

podcast.uberspace.de/folge-8-d

0
2
0
0
0
0
0
0
0
0
0
0

A couple days ago, I got a DM from a 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, had no reason to send a second one.

I filed two issues on the Bonfire 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.

0
3
0
0
0
0
0
0
0
0
0
1
0

A couple days ago, I got a DM from a 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, had no reason to send a second one.

I filed two issues on the Bonfire 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.

0
3
0

A couple days ago, I got a DM from a 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, had no reason to send a second one.

I filed two issues on the Bonfire 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.

0
3
0
0
3
0
0
3
0
0

So features on Hacker News, having 245 comments rn. Many fedizens revile HN, for reasons I well understand.

It's still interesting to look into this thread and distill some product feedback for Loops' improvement.

news.ycombinator.com/item?id=4

HN is often blamed for having only techbro's with growth-hack mentality, with no moral compass or ethics.

Yet in the comments most concerns *are* about the of creating an federated TikTok, even without the addictive algorithm. Worried that short-form vids as snacks for the brain are already detrimental to people's mental health.

Some good feedback to ponder on..

Though I also observe a general misunderstanding how loops differs from TikTok, and the website doesn't explain that well enough. I'd make general public ("users") the prime audience served on the frontpage, who are hardly addressed atm. Then have a separate Creators header menu section. Then a Values section that also gives background to tech benefits.

0

The Chinese party-state's campaign to erase "minority languages" continues

"A years-long trend of replacing Mongolian-, Tibetan-, and Uyghur-medium instruction with Mandarin Chinese-medium instruction is now codified in law. Students in these communities will now only be taught their mother tongue as a single, standalone class; all other classes will be taught in Chinese."

nchrd.org/2026/02/chinas-erasu

0
1
0

In Steglitz steppt der Bär - Wir sagen Werbemonitoren den Kampf an!

Du willst mit uns Werbung gegen Werbung machen?

Komm in deine Berlin Werbefrei - Kiezgruppe und mach mit bei unseren Plakat-Aktionen!
Oder lass eine Unterschrift da.

👉 Unterstütze das Volksbegehren „Berlin Werbefrei“ für weniger Werbung im öffentlichen Raum Berlins.
➡️ Alle Infos & Unterschriften: berlin-werbefrei.de/

0
0
0
0
0

동생이 베트남 선교 다녀오면서 사온 [족제비] 커피.. 이제 함 마셔보네요 ㅋㅋㅋㅋ 내리는 커피일줄 알았는데 인스턴트 스틱 커피였구.. 가루일땐 향이 정말 진하고 좋은데, 물에 타니 다 휘발되었는지 거의 향이 안 나..🥲

0

블루스카이 v1.117 업데이트 - Bandcamp 임베드 지원으로 게시물 내에서 음악을 재생할 수 있습니다 - 스타터 팩을 목록으로 변환할 수 있는 기능을 추가했습니다 - 뮤트한 단어가 만료되었을 때 “갱신” 버튼으로 기간을 조정할 수 있습니다 - 수많은 버그 수정 및 성능을 개선했습니다 caribouband.bandcamp.com/album/butter...

RE: https://bsky.app/profile/did:plc:z72i7hdynmk6r22z27h6tvur/post/3mfkhetnvdk2p


Butterfly, by Daphni

0
1
1
0

The Chinese party-state's campaign to erase "minority languages" continues

"A years-long trend of replacing Mongolian-, Tibetan-, and Uyghur-medium instruction with Mandarin Chinese-medium instruction is now codified in law. Students in these communities will now only be taught their mother tongue as a single, standalone class; all other classes will be taught in Chinese."

nchrd.org/2026/02/chinas-erasu

0
0

FreeBSD에는 내 오래된 MacBook용 Wi-Fi 드라이버가 없었다, 그래서 AI가 만들어줬다
------------------------------
- 2016년형 MacBook Pro의 *Broadcom BCM4350 칩* 은 FreeBSD에서 기본 지원되지 않아, 기존에는 Linux VM을 통한 *wifibox 우회 방식* 이 일반적이었음
- 작성자는
Claude Code 를 이용해 Linux의 brcmfmac 드라이버를 FreeBSD로 포팅하려 했으나, 커널 패닉과 *LinuxKPI 호환성 문제* 로 실패함
- 이후 *Pi c…
------------------------------
https://news.hada.io/topic?id=26957&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
1