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.
카카오톡에서 상대방이 메시지를 입력할 때 노란색 점들이 나타나 실시간으로 대화 준비 상황을 알 수 있는 기능이 생겼습니다. 다만, 대화를 주고 받는 이용자 모두 이 기능을 활성화해야 상태를 확인할 수 있습니다. 🔽 기사 더 읽기 hani.com/u/MTAwNDU
barely been online and posts are already failing to federate 
이런거.. 복숭아 3단 파르페. 2750엔. 예약 요...
RE: https://bsky.app/profile/did:plc:a6qvfkbrohedqy3dt6k5mdv6/post/3lp4q7ksa5s2l
FPGA 나름 재밌어요.
이제 뭐가 안 되면 시뮬레이터와 ILA와 문서를 들고 웨않되!! 하게 되는게 문제지만 
“시민 죽음을 막지 못해 매일 후회한다. 난 그때 전남도청 앞에 앉아 있었어야 했다. 만약 내가 죽었더라도 보람있는 일이라고 생각했을 것이다. 그런 희생은 기꺼이 하겠다.”
데이비드 돌린저(한국명 임대운)는 눈물을 보이며 이같이 말했습니다. 그는 명예시민증을 받기 위해 광주를 찾았습니다.
‘푸른 눈의 시민군’ 돌린저 “도청 앞 시민 죽음 못 ...
𝒹𝑜𝓃𝓀𝓈
#Sciop #WorldPremiere #MusicVideo #LiveEvent #AttendanceInTheBillions #UncountableAttendance #AQuantityOfDocsThatShamesTheHeavens #IfIcarusHadActuallyMadeItToSpaceInsteadOfMeltingThosePunkAssWingsItWouldBeLikeTheseDocs #ActuallyMostlyStillUnfinished #NotThatBigOfAChange #DontClickAnyOtherLinks #IfYouCantTakeMeAtMyPartiallyDocumentedYouDontDeserveMeAtMyFullyDocumented
보드 설계 지옥: 코스트 잘라내기
lucie→tokyo is live!
59 photographs from 3 months in Tokyo — mostly film.
I hope you’ll enjoy browsing through it.
집 가는 버스 탔당
문서 보면서 가야지...
“시민 죽음을 막지 못해 매일 후회한다. 난 그때 전남도청 앞에 앉아 있었어야 했다. 만약 내가 죽었더라도 보람있는 일이라고 생각했을 것이다. 그런 희생은 기꺼이 하겠다.”
데이비드 돌린저(한국명 임대운)는 눈물을 보이며 이같이 말했습니다. 그는 명예시민증을 받기 위해 광주를 찾았습니다.
‘푸른 눈의 시민군’ 돌린저 “도청 앞 시민 죽음 못 ...
[단독] 中전투기에 라팔 격추, 남일 아니었다...韓전투기도 작년 라팔용 미사일 도입 계약 [★★글로벌] - 매일경제
https://www.mk.co.kr/news/world/11317263
라팔이 격추당한건 미사일 탓이 아니라 전술문제가 더 컸는데 뭔소리여
불고기버거 먹어보고싶어요
JVNVU#96741814: Intel製品に複数の脆弱性（2025年5月） : 👀
---
https://jvn.jp/vu/JVNVU96741814/
Misskeyで、ドライブ上で閲覧注意フラグを変えても、リモートでは反映されないという挙動は有名ですが【要出典】
Mastodonで、削除して編集した際に添付されていたメディアは再利用されるため、説明などを変更して投稿しても、
Mastodonには反映されるが、Misskeyには反映されないという挙動があるようです。
Misskey側は、既に受け取り済みの同一URIのメディアを、ドライブの仕組みで同一ファイルと判断しているのかもしれません。
Open source maintainer 
@icingStefan Eissing has been building connections since the days of dial-up modems. From grassroots mailbox networks in the 1980s to maintaining essential internet infrastructure today, his journey is a testament to the power of collaboration without borders.
(1/2)
雖然我來不久但
新實習生或是工作經驗不多的新人：
下班了還戴識別證搭大眾運輸
遙想我過往的新鮮半社畜生活 
요 몇개월 간 llm 최적화 기법을 공부하고있다... 일하는 데 쓰기 때문이다... 문제는 나는 쓰는 쪽이 아니라 구현하는 쪽이다...
일본 오카야마현은 1년 내내 여러 종류의 과일이 유명한 지역인데, 그래서 지자체에서 아예 파르페 가게 맵을 정기적으로 공개하고 있음. 각종 복숭아, 포도, 딸기, 토마토가 유명하고... 신칸센 기준 대충 히로시마하고 오사카 사이 정도. okayama-parfait.com
@hongminhee洪 民憙 (Hong Minhee) this doesn't address serious concerns with GraphQL raised by the article I've linked. Both authorisation and rate limiting are crucial for client2server communication. You may achieve acceptable results using GraphQL with trivial well-behaved clients, in 2025 you can't assume every client is well-behaved. Bots will abuse the API no question, and without proper authorization and rate limiting it will bring servers down.
OpenAPI is much more flexible and doesn't have these issues.
@maxdMax Desiatov @hongminhee洪 民憙 (Hong Minhee)
What may be interesting is #AsyncAPI which is like #OpenAPI but then oriented towards event-driven architectures. More appropriate for message passing protocols like #ActivityPub.
A small pet is investigating PET samples 🧐 (for MNT Desktop Reform)
@PuercoPop 
@thisismissemEmelia 👸🏻 You raise a really good point. You're right that different types of applications have different needs, and a one-size-fits-all approach probably isn't ideal.
I think this actually aligns with what I was considering—not a universal API for the entire fediverse, but rather domain-specific standardized APIs that share common patterns where it makes sense.
For example, we might have:
Each domain would have APIs optimized for their specific use cases, but they could share common patterns, authentication methods, and even some base types.
This approach would still give us the benefits of standardization within each domain (better tooling, consistent developer experience) while acknowledging the fundamental differences between these application types.
@hongminhee洪 民憙 (Hong Minhee) @thisismissemEmelia 👸🏻 @PuercoPop
For your information, I recently opened an issue to track current #ActivityPub C2S implementations.
This is the list thus far:
#ActivityPods
#Epicyon
#Onepage.pub
#Pleroma
#RDFPub
#Vocata
#FedBOX
#Mitra
#streams
#forte
https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130
Client-side #AndStatus is a well-known attempt to implement it:
独占配信つらいが、教祖の漫画なら読まざるを得ない（立ち読み分はもう読んだ）
궁극적으로 메모리-세이프한 프로그람은 아무것도 안 하는 프로그램이에요.
아무튼 safe했죠?
@hongminhee洪 民憙 (Hong Minhee) @thisismissemEmelia 👸🏻 Given that C2S is meant to serve the needs very different kind of apps there is no one size fits all. If you design an API to serve the needs of your app/use cases it will be more efficient.
@PuercoPop @thisismissemEmelia 👸🏻 You raise a really good point. You're right that different types of applications have different needs, and a one-size-fits-all approach probably isn't ideal.
I think this actually aligns with what I was considering—not a universal API for the entire fediverse, but rather domain-specific standardized APIs that share common patterns where it makes sense.
For example, we might have:
Each domain would have APIs optimized for their specific use cases, but they could share common patterns, authentication methods, and even some base types.
This approach would still give us the benefits of standardization within each domain (better tooling, consistent developer experience) while acknowledging the fundamental differences between these application types.
@Shilin0127Leisaa 有點像維基百科流行的年代吧
但維基編輯至少經過人手驗證，論述需要提供來源出處。AI陳述事實連出處都沒有，甚至會亂掰，比前者還不可靠
@voyagerMJ 我覺得是一種思維習慣，普通人比較容易「接受」知識，而不做很多分辨，就是傳播理論上的「靶子」。而且大多數人只求結果不問過程，AI 恰好滿足了人們的思維惰性。
這其實是一個非常危險的事情。
しごおわ＆帰宅
相変わらずウェブコンポーネントのことを考えらさってる。そして暗い気持ちになる。
@hongminhee洪 民憙 (Hong Minhee) also keep in mind that to securely do graphql it is complex, because of query complexity, persisted queries, field resolver reuse, etc (I've worked on several large graphql projects)
Another oft cited tool in the JSON-LD world is SPARQL which theoretically solves thing, but everyone I've met typically hates it or loves it, but implementation tend to be slow due to inefficiency on the network
@thisismissemEmelia 👸🏻 You're right that C2S doesn't provide efficient ways to fetch common app views like chronological feeds or pending follow requests. That's exactly why I think we need something better designed for client use cases.
Regarding GraphQL complexity—that's a valid concern. I've also worked with GraphQL in production, and security, performance, and complexity management are real challenges. However:
The key advantage would be that clients wouldn't need to implement the heavy processing themselves, as the server would handle the data shaping via resolvers.
As for SPARQL—interesting alternative! It does have performance challenges as you mentioned. My thinking is that GraphQL has much wider adoption and tooling, which might make it easier for developers to work with.
What I'm really seeking is something that combines ActivityPub's federation capabilities with a more client-friendly query interface. Do you have other ideas that might achieve this balance?
진짜 얇아요
배터리는 몇mAh다?
RE: https://k.lapy.link/notes/a7rbbh4d3l
無印、なんか何でも屋さんだな
@hongminhee洪 民憙 (Hong Minhee) I think it goes beyond that: if C2S was actually useful for building applications & didn't require heavy processing on the client, then it'd likely be more used.
But it doesn't define like "give me a chronological feed of all incoming posts" or "give me a chronological feed of all my notifications" or "give me all my follow requests that I haven't accepted or rejected"
Those are application concerns, which to implement with current C2S would mean fetching the entire inbox and/or outbox collection and filtering/reducing that dataset.
The consequence is that you inherently end up with either a backend for frontend (custom API / AppView) or a very heavy and potentially slow client application.
@hongminhee洪 民憙 (Hong Minhee) also keep in mind that to securely do graphql it is complex, because of query complexity, persisted queries, field resolver reuse, etc (I've worked on several large graphql projects)
Another oft cited tool in the JSON-LD world is SPARQL which theoretically solves thing, but everyone I've met typically hates it or loves it, but implementation tend to be slow due to inefficiency on the network
I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
Curious what others think about this approach.
@hongminhee洪 民憙 (Hong Minhee) I think it goes beyond that: if C2S was actually useful for building applications & didn't require heavy processing on the client, then it'd likely be more used.
But it doesn't define like "give me a chronological feed of all incoming posts" or "give me a chronological feed of all my notifications" or "give me all my follow requests that I haven't accepted or rejected"
Those are application concerns, which to implement with current C2S would mean fetching the entire inbox and/or outbox collection and filtering/reducing that dataset.
The consequence is that you inherently end up with either a backend for frontend (custom API / AppView) or a very heavy and potentially slow client application.
こはるりっかペタンって座ってるの好き好き部
I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
Curious what others think about this approach.
@steve@social.technoetic.comSteve Bate
Which specific errors in #ActivityPub are you referring to?
@nickNordnick 🐘
@thisismissemEmelia 👸🏻 
@bengo
Here's a list maintained at the W3C...
Goodmorning #Fosstodon and #Fediverse, another update! ☕
Our new mod team is complete and has just started training! 😊 Over the next weeks they'll go through the CoC and modding rules, they'll handle a wide variety of practice cases, and will then move on to (already resolved) real reports. Because we're based all over the world, from Japan, South Korea, India, Europe, South Africa, to the US, the chat is asynchronous and slow. Hence the training will take a while.
1/2
推理小說的心得不乏會看到說「我讀到一半就知道誰是兇手了，太明顯了吧」這類簡短的評論。
我覺得這也是台灣填鴨式教育的特色吧，好像只要知道兇手是誰就結束了。
I've felt for a while that a mainstream method, reverse engineering, in cognitive science & AI is incompatible w computationalism‼️ So I wrote "Modern Alchemy: Neurocognitive Reverse Engineering" w the wonderful Natalia Scharfenberg & 
@IrisIris van Rooij 💭 to elaborate: https://philsci-archive.pitt.edu/25289/
1/n
原來"健怡可樂"與"Zero可樂"的差別在於：
健怡可樂裡頭只含有一種代糖，但是大家都知道代糖會有一種奇怪的後味，後來可口可樂的研發中心想說要怎麼把這令人不悅的後味減少或去除，經過他們的嘗試後，發覺如果一次加了好幾種代糖的話，那不悅的後味就會減少很多，這就是為何後頭又出了一個Zero可樂的由來，用了多種代糖減少了不悅的後味讓更多人可以接受促進購買。
結論: 林北原本只吃了一種代糖而已，最後卻吃了更多種代糖 (咦
The massive adoption of “AI” by the tech “moderate” tells me that most of them only objected to the scam portion of cryptocoins not the fact that the tech itself was built on a dysfunctional libertarian worldview and designed from the ground to bypass or destroy our existing financial infrastructure
They’re FINE with tech destroying the fabric of society as long as there isn’t an outright scam component to it or the scam element can be regulated separately without affecting the main event: the dismantling of the economy for the benefit of the wealthy.
Destruction is fine. Minor scams are not
原來"健怡可樂"與"Zero可樂"的差別在於：
健怡可樂裡頭只含有一種代糖，但是大家都知道代糖會有一種奇怪的後味，後來可口可樂的研發中心想說要怎麼把這令人不悅的後味減少或去除，經過他們的嘗試後，發覺如果一次加了好幾種代糖的話，那不悅的後味就會減少很多，這就是為何後頭又出了一個Zero可樂的由來，用了多種代糖減少了不悅的後味讓更多人可以接受促進購買。
結論: 林北原本只吃了一種代糖而已，最後卻吃了更多種代糖 (咦
The massive adoption of “AI” by the tech “moderate” tells me that most of them only objected to the scam portion of cryptocoins not the fact that the tech itself was built on a dysfunctional libertarian worldview and designed from the ground to bypass or destroy our existing financial infrastructure
Writing that changed how I think about programming languages
Link: https://bernsteinbear.com/blog/pl-writing/
Discussion: https://news.ycombinator.com/item?id=43980760
Writing that changed how I think about PL
Every so often I come across a paper, blog post, or (occasionally) video that completely changes how I think about a topic in programming languages and compilers. For some of these posts, I can’t even remember how I thought about the idea before reading it—it was that impactful.
bernsteinbear.com · Max Bernstein
Link author: 
Max B@tekknolagi@mastodon.social
FPGA가 이렇게 위험합니다.....
RE: https://serafuku.moe/notes/a7raje4x96
서버메이드 깐프 
![[단독] 中전투기에 라팔 격추, 남일 아니었다...韓전투기도 작년 라팔용 미사일 도입 계약 [★★글로벌]](https://pimg.mk.co.kr/news/cms/202505/14/news-p.v1.20250514.4359eaae1dce48a89295e5799a890467_R.jpg)
洪 民憙 (Hong Minhee)
아사
Andy Piper
