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
1
0
0
0
0
New_ Public @wearenew_public@mastodon.social
Public

This week, a special crossover newsletter with Elle Griffin and her newsletter, The Elysian. We wrestle with a complicated topic: government control of social media.

What’s best, and what might actually work? Check our back and forth, debate-style essay and then weigh in with your own opinion!

newpublic.substack.com/p/who-s

🤔 Who should control social media?

Should it be a public good, a private product, or something else?

newpublic.substack.com

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
julian @julian@community.nodebb.org
Public

@hamishcampbell@mastodon.social recently made a statement that got me thinking about our place in the open social web, and the direction it's going.

He says to @deadsuperhero@social.wedistribute.org and @evan@cosocial.ca re: SXSW

#FediverseHouse this feels like an irrelevant echo chamber, I really miss the grassroots #DIY that built this space in the first place. This #maistreaming is too much noise vs signal... currently the grassroots #DIY space is a hollow shell

(two posts combined)

That immediately got me on edge as someone new to ActivityPub in 2024. Does this mean I'm "mainstream", and somehow "bad"?

Mainstream adoption is good and a step in the right direction. I personally think ActivityPub isn't ready for general mainstream consumption, but we as a group are rapidly closing the gap and I'd much rather continue building momentum instead of waiting for the opportune moment.

Here's the hot take that I was going to originally write, but thought came off as too combative:

It sounds like you feel like ActivityPub development only counts when you're toiling away in obscurity.

As someone who's hacking away on a platform that hasn't been "mainstream" for over a decade (forum/BBS software), I bristle at the notion that what I do doesn't count as grassroots or DIY. You don't have to be the perpetual underdog to do good in the world.

I might be wrong, but it sounds like Hamish feels like big players are coming in and taking the ball away... that big players' clout and presence takes away from the attention that smaller DIY projects receive.

Maybe... but if the fediverse is 100x larger with a big player, and they take 99% of the eyeballs, have they really taken anything away from you?

0
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
九九想用更放松的态度生活 @UnaZ@m.cmx.im
Public

Claude说，你以为当下的快乐健康和未来的保障是二元对立的，其实不是。当你为了未来牺牲当下，以为以后可以获得一些东西，但你牺牲掉的快乐和健康会逐渐累积，在未来让你付出更大的代价。

当下的健康和快乐其实是未来成功和保障的基石。否则当你真的到达那个「有保障」的未来的时候，可能已经不再觉得是有保障的了，长期的痛苦会改变一个人。想要长久可持续的发展，就必须尊重自己的需求，保护自己的闪光和爱。毕竟还远远不到生死攸关需要不顾一切牺牲的时候。

知易行难啊，感觉又吐出了一口毒奶，妈蛋改掉有毒思想的每一步都是无数个辗转反侧的晚上。

0
0
0
0
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
arkhi @arkhi@mamot.fr
Public
Shared by Andy Piper

“Big Tech Wants You Trapped. The Open Web Sets You Free”, by @DaojoanJA Westenberg.

joanwestenberg.com/big-tech-wa

> It's about whether we build systems that distribute power or concentrate it. Big Tech's dominance wasn't inevitable, and it's not unbreakable. But it's reinforced by the choices we make every damn day. Because over and over again, we choose easy. We choose platforms with less friction.

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Linear @linear@hackers.pub
Public

오늘의 일기

  • hackers.pub 첫 포스트!
  • 첫 수영 수업을 다녀왔다. 전날 밤에 악몽 꿀 정도로 긴장했는데 다행히 가서 음파음파 잘 하고 왔다. (..)
  • SNS 여러 개는 도저히 못 쓰겠다는 결론을 내리고 블루스카이 탈퇴.
  • 스마트폰 사용 시간을 줄이기 위해 디스플레이를 흑백으로 바꿨다.
  • 과연 올해야말로 블로그 대통합을 이룰 수 있을 것인가? 네이버 블로그에 쌓여 있는 글을 모두 나만의 정적 웹사이트로 옮기고 애매하게 둥둥 떠 있는 github pages 는 없애는 게 목표.
0
0
0
Linear @linear@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee) :nonbinary:

오늘의 일기

  • hackers.pub 첫 포스트!
  • 첫 수영 수업을 다녀왔다. 전날 밤에 악몽 꿀 정도로 긴장했는데 다행히 가서 음파음파 잘 하고 왔다. (..)
  • SNS 여러 개는 도저히 못 쓰겠다는 결론을 내리고 블루스카이 탈퇴.
  • 스마트폰 사용 시간을 줄이기 위해 디스플레이를 흑백으로 바꿨다.
  • 과연 올해야말로 블로그 대통합을 이룰 수 있을 것인가? 네이버 블로그에 쌓여 있는 글을 모두 나만의 정적 웹사이트로 옮기고 애매하게 둥둥 떠 있는 github pages 는 없애는 게 목표.
0
0
0
Linear @linear@hackers.pub
Public

오늘의 일기

  • hackers.pub 첫 포스트!
  • 첫 수영 수업을 다녀왔다. 전날 밤에 악몽 꿀 정도로 긴장했는데 다행히 가서 음파음파 잘 하고 왔다. (..)
  • SNS 여러 개는 도저히 못 쓰겠다는 결론을 내리고 블루스카이 탈퇴.
  • 스마트폰 사용 시간을 줄이기 위해 디스플레이를 흑백으로 바꿨다.
  • 과연 올해야말로 블로그 대통합을 이룰 수 있을 것인가? 네이버 블로그에 쌓여 있는 글을 모두 나만의 정적 웹사이트로 옮기고 애매하게 둥둥 떠 있는 github pages 는 없애는 게 목표.
0
0
0
0
0
0
Linear @linear@hackers.pub
Public
Shared by 洪 民憙 (Hong Minhee)

오늘의 일기

  • hackers.pub 첫 포스트!
  • 첫 수영 수업을 다녀왔다. 전날 밤에 악몽 꿀 정도로 긴장했는데 다행히 가서 음파음파 잘 하고 왔다. (..)
  • SNS 여러 개는 도저히 못 쓰겠다는 결론을 내리고 블루스카이 탈퇴.
  • 스마트폰 사용 시간을 줄이기 위해 디스플레이를 흑백으로 바꿨다.
  • 과연 올해야말로 블로그 대통합을 이룰 수 있을 것인가? 네이버 블로그에 쌓여 있는 글을 모두 나만의 정적 웹사이트로 옮기고 애매하게 둥둥 떠 있는 github pages 는 없애는 게 목표.
0
0
0
Fedify: ActivityPub server framework @fedify@hollo.social
Public
Shared by 洪 民憙 (Hong Minhee)

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.
0
5
1
Fedify: ActivityPub server framework @fedify@hollo.social
Public
Shared by 洪 民憙 (Hong Minhee) :nonbinary:

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.
0
5
1
Fedify: 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.
0
5
1
0
0
0
0
0
0
0
0
0
0
0
0