XiNiHa

@xiniha@hackers.pub · 87 following · 105 followers

GitHub
@XiNiHa
Bluesky
@xiniha.dev
Twitter
@xiniha_1e88df
Fedify: an ActivityPub server framework @fedify@hollo.social
Public

Got an interesting question today about 's outgoing design!

Some users noticed we create separate queue messages for each recipient inbox rather than queuing a single message and handling the splitting later. There's a good reason for this approach.

In the , server response times vary dramatically—some respond quickly, others slowly, and some might be temporarily down. If we processed deliveries in a single task, the entire batch would be held up by the slowest server in the group.

By creating individual queue items for each recipient:

  • Fast servers get messages delivered promptly
  • Slow servers don't delay delivery to others
  • Failed deliveries can be retried independently
  • Your UI remains responsive while deliveries happen in the background

It's a classic trade-off: we generate more queue messages, but gain better resilience and user experience in return.

This is particularly important in federated networks where server behavior is unpredictable and outside our control. We'd rather optimize for making sure your posts reach their destinations as quickly as possible!

What other aspects of Fedify's design would you like to hear about? Let us know!

A flowchart comparing two approaches to message queue design. The top half shows “Fedify's Current Approach” where a single sendActivity call creates separate messages for each recipient, which are individually queued and processed independently. This results in fast delivery to working recipients while slow servers only affect their own delivery. The bottom half shows an “Alternative Approach” where sendActivity creates a single message with multiple recipients, queued as one item, and processed sequentially. This results in all recipients waiting for each delivery to complete, with slow servers blocking everyone in the queue.
Fedify: an ActivityPub server framework @fedify@hollo.social
Public
Shared by XiNiHa

Coming soon in 1.5.0: Smart fan-out for efficient activity delivery!

After getting feedback about our queue design, we're excited to introduce a significant improvement for accounts with large follower counts.

As we discussed in our previous post, Fedify currently creates separate queue messages for each recipient. While this approach offers excellent reliability and individual retry capabilities, it causes performance issues when sending activities to thousands of followers.

Our solution? A new two-stage “fan-out” approach:

  1. When you call Context.sendActivity(), we'll now enqueue just one consolidated message containing your activity payload and recipient list
  2. A background worker then processes this message and re-enqueues individual delivery tasks

The benefits are substantial:

  • Context.sendActivity() returns almost instantly, even for massive follower counts
  • Memory usage is dramatically reduced by avoiding payload duplication
  • UI responsiveness improves since web requests complete quickly
  • The same reliability for individual deliveries is maintained

For developers with specific needs, we're adding a fanout option with three settings:

  • "auto" (default): Uses fanout for large recipient lists, direct delivery for small ones
  • "skip": Bypasses fanout when you need different payload per recipient
  • "force": Always uses fanout even with few recipients
// Example with custom fanout setting
await ctx.sendActivity(
  { identifier: "alice" },
  recipients,
  activity,
  { fanout: "skip" }  // Directly enqueues individual messages
);

This change represents months of performance testing and should make Fedify work beautifully even for extremely popular accounts!

For more details, check out our docs.

What other optimizations would you like to see in future Fedify releases?

Flowchart comparing Fedify's current approach versus the new fan-out approach for activity delivery. The current approach shows: 1. sendActivity calls create separate messages for each recipient (marked as a response time bottleneck) 2. These individual messages are queued in outbox 3. Messages are processed independently 4. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server) The fan-out approach shows: 1. sendActivity creates a single message with multiple recipients 2. This single message is queued in fan-out queue (marked as providing quick response) 3. A background worker processes the fan-out message 4. The worker re-enqueues individual messages in outbox 5. These are then processed independently 6. Three delivery outcomes: Recipient 1 (fast delivery), Recipient 2 (fast delivery), and Recipient 3 (slow server) The diagram highlights how the fan-out approach moves the heavy processing out of the response path, providing faster API response times while maintaining the same delivery characteristics.
0
0
1
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by XiNiHa

Mastodon이나 Misskey 등에서 민감한 내용으로 지정한 단문의 내용이나 첨부 이미지는 이제 Hackers' Pub에서 뿌옇게 보이게 됩니다. 마우스 커서를 가져다 대면 또렷하게 보이게 됩니다. 다만, Hackers' Pub에서 쓰는 단문을 민감한 내용으로 지정하는 기능은 없습니다. (아마도 앞으로도 없을 것 같습니다.)

Hackers' Pub 타임라인에 뜬 민감한 내용으로 지정된 단문. 내용이 뿌옇게 나와서 보이지 않는다.Hackers' Pub 타임라인에 뜬 민감한 내용으로 지정된 단문. 마우스 커서를 가져다 대면 뿌옇던 내용이 또렷하게 보인다.
0
0
0

XiNiHa shared the below article:

rel="me" 메모

Lee Dogeon @moreal@hackers.pub

Hackers' Pub의 프로필 링크 인증 기능이 제대로 작동하지 않아, GitHub 링크를 추가했음에도 체크 표시가 나타나지 않는 문제를 해결하기 위한 여정을 담고 있습니다. `rel="me"` 속성이 HTML 링크 요소에서 어떤 역할을 하는지 MDN 문서를 통해 알아보고, GitHub 프로필 설정에서 Hackers' Pub 링크를 추가할 때 `rel="me"` 속성이 자동으로 추가되는 것을 확인합니다. Hackers' Pub의 오픈 소스 코드를 분석하여 인증 마크가 표시되는 과정을 파악하고, GitHub에 Hackers' Pub 링크를 추가한 후 프로필 설정을 다시 저장하면 인증 체크 표시가 나타나는 것을 확인합니다. 이 글은 `rel="me"` 속성의 역할과 Hackers' Pub의 링크 인증 과정을 이해하고, 문제 해결 방법을 제시하여 독자들이 유사한 문제를 겪을 때 도움을 받을 수 있도록 합니다.

Read more →
1
0
0
0
1
0
0
0
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Quiet public

고등학교 졸업할 무렵부터 Vim을 썼으니까 한 20년 가까이 썼나? 중간에 Neovim으로 바꾸긴 했지만… 그런데 이제는 VS Code를 메인으로 쓴다. (물론 VSCodeVim을 쓰긴 함.) 뭔가를 끊임 없이 기름칠하고 조이고 하는 게 좀 귀찮아졌달까?

그런 의미에서 생각해 보면 셸을 바꾼다면 fish 정도가 괜찮을지도…

0
1
0
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public
Shared by XiNiHa

사람들이 잘 모르는 Markdown 명세 하나. CommonMark, 즉 표준 Markdown에서 URL은 자동으로 링크되지 않는다. 대부분의 Markdown 구현체들이 이를 옵션으로 지원하고, Markdown을 지원하는 웹사이트들이 이 옵션을 켜놓고 있기 때문에 모르는 사람들이 많다. CommonMark에서 URL이나 메일 주소를 링크하려면 <와 >로 주소를 감싸야 한다.

이를 잘 이용하면 URL의 앞 뒤에 띄어쓰기를 하지 않고도 링크를 걸 수 있다는 장점도 된다.

0
0
0
유루메 Yurume @yurume@hackers.pub
Public
Shared by XiNiHa

최근에 오랫동안 쓰던 키보드가 망가져서 큰 맘 먹고 프리플로우 Archon M1 PRO MAX를 질렀는데, 요즘 키보드는 다 WebHID 가지고 웹 드라이버로 설정하는 것 같다. 자바스크립트니까 뜯기 쉽겠거니 싶어서 살펴 봤는데 커스텀 HID 레포트를 보낼 수 있는 기능을 사용해서 명령들을 나열해 놓았고, 개중에는 롬을 통으로 날리는 것도 가감없이 노출되어 있길래 음 역시 WebHID 같은 건 웹에 넣을 기능이 못된다는 결론을 내렸다. 가볍게 함수 목록만 요약해서 https://gist.github.com/lifthrasiir/c79c90ecf697b1e6dc73e83f32984499에 올렸다.

0
2
0
geeknews_bot @geeknews_bot@sns.lemondouble.com
Public
Shared by XiNiHa

애플리케이션 개발 측면에서 본 Drizzle ORM 대 Kysely 비교
------------------------------
# Drizzle ORM vs Kysely 비교 요약

## Drizzle ORM의 장점

- *스키마 정의의 직관성* : 선언적 방식의 스키마 정의가 가능하며, 이로부터 자동으로 CREATE TABLE SQL 생성이 가능.
- *자동화된 마이그레이션* : 스키마 변경사항을 자동으로 감지하여 SQL 마이그레이션 파일 생성이 가능.
- 직관…
------------------------------
https://news.hada.io/topic?id=19805&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0