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

New Bark by Aria Salvatrice @woofNo queerphobic death threats on Fedi :

Astro for my Fan-site: Some Fun Party Tricks

A little nerd article explaining how and why i use the Astro framework
@astro for my little game fan-site, focusing on the sort of special use cases it allows me to implement.

https://aria.dog/barks/astro-for-my-fan-site/

0
0
0

Nur mal angenommen...

...jemand baut in Deutschland eine Chatbot-App für Menschen mit psychosozialen Problemen und bewirbt sie mit therapeutischem Jargon, verneint aber auf Rückfrage jeden Vergleich mit Medizinprodukt-Apps und sieht deshalb keine Notwendigkeit, sich an die Anforderungen für Medizinprodukt-Apps zu halten.

Und verstößt außerdem gegen die Versprechen der eigenen Datenschutzerklärung, indem die App Nutzereingaben an einen us-amerikanischen Chatbot-Cloudservice überträgt.

Wo, außer beim Datenschutzbeauftragten des zuständigen Bundeslandes, beschwert man sich denn da?

Frage für einen Freund.

0
0
0
1
0

💻 Mozilla Thunderbird - The Failure of a Once Great Client 💻: prose.winterschon.com/2025/05/

Thunderbird, wtf are you doing where you need 83% CPU plus ~50GB (virt) and 20G (res) of RAM allocated? You’re an email client. You handle IMAP. This has become absurd, the slow death of a once great product.

0
0
0
0
0

Exactly one month from today, I'll be at to present my talk "Why (and how) we're migrating many of our servers from Linux to the BSDs" (AKA: "I solve problems").

As the days go by, I feel increasingly honored to be a speaker at this event, more and more excited to live an experience similar to the incredible one I had last September at in Dublin, and more confident than ever in the technical choices I’ve made over the years - which I’ll be happy to share.

BSD conferences aren’t just technical events - they’re snapshots of the BSD community as a whole: friendly, collaborative, pragmatic, and positive.

To everyone attending: see you in Ottawa!

indico.bsdcan.org/event/5/cont

0
0
0
0
0
0
0
0
0

We're going to the NGI Forum June 19-20 in Brussels and you are warmly invited to come too. Participation is free as in free beer.
There's a great line-up with NGI Zero funded projects like @Mastodon @rosenpassProject Rosenpass @nextgraph @servo & @CryptPad
Michiel Leenaars, our director of strategy, will be joining the panel 'Forging European Digital Sovereignty through an Open Internet Stack'.
This event brings policymakers & internet makers together. Hope to see you there!
https://ngi.eu/ngi-forum25/
#NGI #NGI0

0
0
0
0
0
When I think of the things I enjoy the most about New Hampshire, I think about the smell of the spring breeze delicately perfumed with the delightful scent of our state flower, the purple lilac. And, she ain't so bad to look at, either!

#spring #growth #NH #NewHampshire #stateflower #purplelilac #lilac #bloomscroll #bloomscrolling #nature #naturephotography #landscape #landscapephotography #photo #photography #amateurphotography #getoutdoors #getoutside #S25Ultra #Samsung #pixelfed #fediverse
0

仮にエンティティの形がFederation Protocolのものから乖離していたり未知の拡張を無視したりするならば、特定のアプリケーションと密結合という意味においてMastodon APIと大差なくなってしまうと思うけど、その点でGraphQLのデータモデルはActivity Streamsのそれと馴染まないような気がする。Persisted queriesとかも、不特定多数のクライアントに対応しようとするならば適用できないだろうし

0
0
0

@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

0

I've been thinking about client-server interactions in the . 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.

would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. '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.

0

I've been thinking about client-server interactions in the . 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.

would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. '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.

3
8
0
1
0

이재명·민주당의 빅텐트는 왜 오른쪽으로만 한없이 넓어지는가. 빅텐트로 들어간 진보정당·정치인·활동가는 문제제기를 하긴 하는 걸까? 이들의 자리가 빅텐트 안에 있기는 한가? 등등 여러 생각이 드는 대선정국.

1
0
0
0
0
0
0
0

 今のツイッターのことなんも知らんのだけど、YouTube見てたら、ツイートに対して「@Grok  要約して」とは「@Grok  反論して」とかリプライするとAIが対応してくれると紹介されていた。ガビガビになった漫画の1コマの次の次元来た。なにがGrok?このGlockで風穴あけてやるよ。

0
0
0