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.
๐ฅฉ
What day/night will be the wildest party on your island?โ
@dansup
Check also 
@berlinfedidayBerliner Fediverse Tag - September in Berlin
๊ทผ๋ฐ ์ ๋ค๋ฅธ ์ฌ๋๋ค์ ๊ทธ๊ฑธ ์ ์ ์ฐ๋ ๊ฑธ๊น์...?
๊ทผ๋ฐ ๋๋ฌด ์ค๋๋ง์ ์ด๋๋ผ ์ ๋๋ผ ์์๋ฆฌ ํญํ ๋ง์ผ๋๊น ์ด์ง์ด์งํ๋ค
The people of Minnesota are fucking marvellous.
They're deliberately putting Mexican flags on their cars so that CBP/DHS waste time chasing them. They're calling it ICE fishing ๐คฃ โ
์์ํ๋ฐ ์์ํ์ง ์์ผ๋ ค๊ณ ๋ ธ๋ ฅ ์ค. ๋๊ตฌ ์๋ชป๋ ์๋๊ณ ํผํ ์๋ ์๋ ์ผ์ด์๋ค ์๊ฐ
When will people figure out that machines working in an unconstrained human environment need AGI to be fully autonomous?
There are no shortcuts.
I just got cursed out for asking someone to CW political posts.
Apparently, I'm what's wrong with the Fediverse.
Soโฆ am I?
Okay, I'd like to know more.
็ๆAIใซใใใพใใชๆ็ซ ็ๆใใใใใจใใใใฉใใใฃใฑใ่ชๅใงๆธใใชใใจ้ง็ฎใ ใฃใฆใชใฃใฆใ
When will people figure out that machines working in an unconstrained human environment need AGI to be fully autonomous?
There are no shortcuts.
"Final Answer: Your GMI idea at the 200% level is improbable if funded solely by billionaire taxes. However, a GMI targeted at the 100% poverty line is completely financially viable if we actually enforced the tax code and enacted a wealth tax. We could end official poverty tomorrow; we just choose not to." ๐ค
์์ฆ ์ ์ฐฌ๋ฆฌ์ ํจ๋ณด์ด ํ๋ฝ์ค์ธ๋ฐ ๊ฝค ์ฌ๋ฐ์
this issue took 4.5 months to complete -- FAR too long, thanks to a myriad of health issues that cropped up at once and repeatedly. i'm so grateful for y'all's patience and kindness. <3
and here's a bit of a post-mortem of the first year of good internet!
@djangonews is a wonderful resource for the #Django community. I'm always excited to read the latest edition. This week's included some love for https://django-antipatterns.com
The site includes extra context on JsonResponse(safe=) which clarifies why it's important. Thankfully, browsers have gotten better to the point where this feature (and antipattern) can be removed!
https://www.better-simple.com/django/2026/02/06/a-riskier-jsonresponse/
Does anyone in my Django world use Scalingo for hosting? I hadn't heard of it until today, but they've been around for over a decade!
It seems like every time Heroku comes closer to actually closing its doors, we learn about new hosting options.
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. โWhy can't I follow this person?โ Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
Ulven is sceptical about Caturday today but we arenโt! Hope youโre having a mogginificent day!
JSON-LD ๋ฅผ ์ ๋๋ก ๋ค๋ฃจ๋ ๋ผ์ด๋ธ๋ฌ๋ฆฌ๋ฅผ ํ๋ ๋ง๋ค์ด ๋ณด์๋ฉด ์ด๋จ๊น์
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. โWhy can't I follow this person?โ Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
There's no way with the current tools we got as web designers to replicate Liquid Glass, unfortunately.I, for one, am very happy about this
Does anyone in my Django world use Scalingo for hosting? I hadn't heard of it until today, but they've been around for over a decade!
It seems like every time Heroku comes closer to actually closing its doors, we learn about new hosting options.
I'm not just working on 
@loops, 
@fedidb, 
@webintents, 
@activityrank, and other initiatives.
I'm also quietly rebuilding 
@pixelfed, preparing it for a major release that solves every bug and issue you've ever had.
It's not easy, or quick. I have to redesign and rewrite every page, including the admin dashboard.
But trust me, it will be worth the wait.
If you run a Loops server, you know what I mean ๐
Hey, the Autumn/Winter 2025 issue of the Good Internet magazine is out?
Go read/subscribe!
#Woodbine #caturday #catsofmastodon
Woodbine the cat is looking especially regal this morning.
Toyota (yes, the car company) has released a game engine and itโs written in Flutter of all things fluorite.game
Manami Morita Big Band - My Favorite Things
https://youtu.be/mJAPGFE9Xzc
์ค ๋๋ฌด์กฐ์๋ฐ
Manami Morita Big Band - Le Tombeau de Couperin
Old and new.
(Also the photo is older, from the archive.)
#photography
lol fuck you can prompt inject a self-driving car with a doctored street sign https://www.theregister.com/2026/01/30/road_sign_hijack_ai/
The purpose of Continuous Integration is to fail https://lobste.rs/s/ab9jza #devops
https://blog.nix-ci.com/post/2026-02-05_the-purpose-of-ci-is-to-fail
Habe #Externsteine besichtigt und Freude รผber die Abwesenheit von Internsteinen empfunden.
Und zu #Miosga:
Ja, man muss Faschist*innen inhaltlich stellen, international wie national.
Der richtige Raum dafรผr ist allerdings keine Inszenierung in einer Talkshow, sondern die Prรผfung vor Gericht.
Damit vermeidet man, es spรคter in einem Trรผmmerhaufen vor einem internationalen Tribunal aufarbeiten zu mรผssen.
This one goes out to the #peertube folks.. I've set up my own instance, and I am looking for a way to set up vanity names for recurring livestream links - don't really want to go around and announce a mere alphanumeric string.
Is that a solved problem already, and if so - how?
Would setting up a symlink on the webserver be a workaround?
RP) ๋ถ๋งํฌํด๋๊ณ ๊น๋จน์๋ค๊ฐ 2์์ด ๋ผ์์ผ ์ค๋ฏธ์ฟ ์ง๋ฅผ ํด๋ณด๋ ์ฌ๋
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. โWhy can't I follow this person?โ Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
Life was better when the only known Epstein was the one from Epstein-Barr
are you an intruder or an extruder?
Toyota (yes, the car company) has released a game engine and itโs written in Flutter of all things fluorite.game
This story just came out today www.huffpost.com/entry/trump-...
She Was Honored With A Human R...
Ein Briefbeschwerer ist jemand, der sich per Brief beschwert.
๐ธ 7: #FOSDEM Social Web devroom pics โ Fra of 
@openforfutureOpen For Future | Italia with 
@magostinelliMichele Agostinelli and 
@filippodb
filippodb โ 
during their talk "Building a sustainable Italian Fediverse"
๐ธ 8: #FOSDEM Social Web devroom pics โ 
@benpateBen Pate ๐ค๐ป of Emissary, who gave the inspiring final talk of the day
video: https://ftp.belnet.be/mirror/FOSDEM/video/2026/h2215/CP7KWX-emissary-and-the-fediverse.mp4
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. โWhy can't I follow this person?โ Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. โWhy can't I follow this person?โ Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
Zu Miosga:
Empรถrung in den sozialen Medien bewirkt rein gar nichts. Zero. Nada. DIREKTES FEEDBACK an den Sender ist das einzige, mit dem ihr der rechten Feedbackflut etwas entgegensetzen kรถnnt. Die tun das nรคmlich viel und stรคndig.
Brief (lรคsst sich weniger leicht ignorieren!) verschicken z.B. per https://briefklick.de
Adresse:
NDR Hรถrer- und Zuschauerservice
Rothenbaumchaussee 132
20149 Hamburg
Bitte teilen.
Hรค, in Kรถln scheint die Sonne und es sind 13 Grad.
Hรค, in Kรถln scheint die Sonne und es sind 13 Grad.
Andreas Freise
Jeff Atwood
jnkrtech
Kota Nakatsubo
Stefan Bohacek
Will Vincent
Eugen Rochko
jthan
Quincy โ
marius
nicole mikoลajczyk
