洪 民憙 (Hong Minhee) :nonbinary:'s avatar

洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

1,099 following1,872 followers

An intersectionalist, feminist, and socialist living in Seoul (UTC+09:00). @tokolovesme's spouse. Who's behind @fedify, @hollo, and @botkit. Write some free software in , , , & . They/them.

서울에 사는 交叉女性主義者이자 社會主義者. 金剛兔(@tokolovesme)의 配偶者. @fedify, @hollo, @botkit 메인테이너. , , , 等으로 自由 소프트웨어 만듦.

()

Website

https://hongminhee.org/

GitHub

https://github.com/dahlia

Blog

https://writings.hongminhee.org/

Hackers' Pub

https://hackers.pub/@hongminhee

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

ブログ『洪民憙雑記』をPHPからAstro + Netlifyに移行して、ついでにFedifyでActivityPubに対応させた話を文章にまとめた。

https://writings.hongminhee.org/2026/07/fedified-blog/

writings.hongminhee.org

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

洪民憙 (Hong Minhee)
@hongminhee@writings.hongminhee.org
I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd never implemented ActivityPub. TypeScript and modern web tooling are second nature to me now, and ActivityPub has become central to my work. I maintain Fedify, for whatever that's worth, and it bothered me that my own blog wasn't federated. So I fixed that.

The old stack: Jikji and PHP

This blog used to run on Jikji, a static site generator I wrote myself in Deno. Calling it a static site generator is a bit of a stretch, though. Like old Movable Type installations, it didn't just produce HTML; it generated a bit of PHP too. That PHP existed almost entirely for HTTP content negotiation: it read the browser's Accept-Language header and chose among Korean mixed script, hangul-only Korean, English, and Japanese. That's all it did.

I first considered adding a thin ActivityPub implementation directly in PHP, since I was already using it. But I wasn't really writing that PHP by hand; Jikji generated it for me, and I had no interest in hand-coding PHP myself. Federating meant delivering a Create(Article) activity to followers whenever a new post went up, which meant I'd need something like a message queue. Bolting a message queue onto Jikji's generated PHP felt, to me at least, like more complexity than it was worth maintaining. And honestly, with Fedify already around, I had no desire to implement ActivityPub from scratch again.

So I ripped out PHP entirely and decided to bring in Fedify instead.

The new stack: Astro and Netlify

The first decision was to drop Jikji and PHP for Astro, a JavaScript framework built for static-content-heavy sites. I chose Astro largely because it already had a @fedify/astro integration.

I reused as much of the existing CSS and HTML as I could. I'm happy with the current design, and redoing it alongside everything else felt like scope creep waiting to happen. Permalinks stayed exactly as they were. I wanted to replace the stack underneath without visitors noticing anything had changed at all.

For hosting, I went back and forth between Cloudflare Workers and Netlify, and settled on Netlify partly because Fedify had never run there before, and this seemed like a good excuse to add that support. I've hosted static sites on Netlify plenty of times, but this was my first time pairing it with edge functions. The idea of a mostly static site with a few dynamic slices reminded me of the late-nineties web, when a site was static HTML except for whatever lived in /cgi-bin/.

Publishing used to mean committing a Markdown file to Git, pushing, letting GitHub Actions build the static site, and deploying it over SFTP. Now GitHub Actions is out of the build pipeline entirely, since Netlify builds the site itself. It ended up simpler overall.

I'm happy with Astro, and the migration went smoothly. It beats Jikji, which I'd barely touched since building it five years ago. Jikji is now archived; there's no reason left for me to keep maintaining it.

Fitting Fedify into Astro

Updating @fedify/astro

Once I actually tried to add Fedify to Astro, I ran into a problem: @fedify/astro didn't support Astro 7, the current version. The Astro APIs it relied on hadn't changed much internally, but the package's declared compatibility range, and its tests, only went up to Astro 5. So before I could federate the blog, I had to fix @fedify/astro first.

That meant more than widening a version range. The existing tests built a fake Astro context and called the middleware directly, which couldn't catch problems with Vite's SSR configuration, compatibility across adapters, or request routing on a built server. So I wrote new compatibility tests that pack @fedify/astro for real, install it into a small Astro app, build and start the app, and send real HTTP requests to it.

Those tests check, across Astro 5, 6, and 7, that HTML requests reach Astro's pages, that ActivityPub and WebFinger requests are handled by Fedify, and that Astro's 404 Not Found still applies to everything else. For Astro 7 specifically, I also run the tests against Deno and Bun, not just the Node.js adapter.

That work has already been merged upstream and will ship in Fedify 2.4.0.

Static pages, dynamic endpoints

The Astro project as a whole builds with server output, but the existing blog pages are still prerendered, same as before. WebFinger, the actor, the inbox and outbox, the followers collection, and ActivityPub objects are the exceptions: Fedify handles those dynamically, per request. The middleware @fedify/astro provides looks at a request's URL and Accept header and only intercepts what Fedify is meant to handle. The same URL can return the existing Astro page for an HTML request and a Fedify-built object for an ActivityPub one.

What visitors see is still, for all practical purposes, a static site. Nearly all the new dynamic surface lives somewhere only other fediverse servers ever touch. That's the CGI comparison again.

Person and Article

Adding ActivityPub also meant deciding what counts as an actor here, and what counts as an object. I gave the blog's actor a Person type. Publishing itself is automated, but the actor represents me, the person writing these posts, not a piece of software or a service. So the handle is @hongminhee@writings.hongminhee.org, and the actor's web URL points at the blog.

Each post gets an Article. It has a title and a body, and it lives at its own permalink as a long-form document, which fits Article better than Note. Most major ActivityPub implementations support Article these days, Mastodon included. Human-facing permalinks stayed put; ActivityPub objects got their own URIs instead, shaped like /ap/articles/{year}/{month}/{slug}. Article's url points back at the original permalink, so the object's identity and the web page people actually read stay separate.

Multiple languages took more thought. Representing each language as its own Article would scatter likes and shares for the same post across several objects. So I merged the Korean mixed script, hangul-only Korean, English, and Japanese versions under a single Article, all sharing one permalink. Title, summary, and body each carry language-tagged values for every version, which serialize to JSON-LD as nameMap, summaryMap, and contentMap. For implementations that don't handle per-language values, name, summary, and content also carry a default: English if there's an English version, Korean mixed script otherwise. Each language's HTML page also gets a Link on Article's url, tagged with hreflang.

That way, a receiving server that understands multiple languages can pick a title and body matching the reader's language, and one that doesn't can still fall back to the default. In practice, though, I know of hardly any ActivityPub implementation that renders these multilingual values properly yet. There's an open issue for it on Mastodon's tracker, and a similar proposal on Hackers' Pub's, but neither has a timeline. Some of that is probably a UI design problem as much as anything else.

Running Fedify on Netlify

Unlike serving plain static files, an ActivityPub server needs some state that outlives any single deploy. The actor's signing key can't rotate on every deploy. The followers list can't disappear on the next one either. Both live in Netlify Database.

Incoming and outgoing activities go through a message queue built on Async Workloads. Delivery can be slow or fail outright depending on the receiving server, so it can't all happen inside the function handling the HTTP request. Queuing it separates accepting a request from actually delivering it, and failed deliveries can be retried later. Fedify already abstracts this, with pluggable backend adapters, but there wasn't yet an adapter for Netlify's Async Workloads. So I wrote the @fedify/netlify package, which uses Async Workloads as the queue and keeps delivery-order state in Netlify Database.

Announcing new posts to the fediverse turned out to be a separate problem. A static site finishing its build doesn't tell a running ActivityPub server anything about which posts changed. So on every successful production deploy, I diff the current post list against the previous deploy's. New posts get a Create(Article); edited ones, whether the content or just the timestamp changed, get an Update(Article); removed ones get a Delete(Article). All of it goes out to followers. Retries reuse the same activity ID for the same change, and deploy ordering is checked so that an older deploy syncing late can't undo a newer one.

Netlify's deploy previews and branch deploys have federation turned off entirely. Otherwise every preview would spin up an actor claiming to be this same blog, and a test deploy could end up sending activities to real followers. Locally, I develop against an in-memory store and queue; production is the only place using the persistent database and queue.

Fedify now runs on Netlify Functions, alongside Deno Deploy and Cloudflare Workers, on top of its usual support for Node.js, Deno, and Bun.

Wrapping up

None of this gives the blog a timeline, a reply box, or any other social feature. Writing and reading still work the way they always did, and the permalinks and design are basically untouched. What changed is that the blog, and every post on it, now has a name and address the fediverse understands. Follow @hongminhee@writings.hongminhee.org to get new posts, or look up a post's ActivityPub object URI to find the original.

I've maintained Fedify long enough to show other developers how to implement ActivityPub, and I dogfooded it plenty while building Hollo and Hackers' Pub. But this was the first time I'd added it to a site that was already live, and static at that. Along the way I got a compatibility test suite for the Astro integration, Netlify support, and a handful of deployment and operational problems that no amount of reading docs or unit tests would have surfaced. It turns out Fedify isn't just for building new social networks from scratch; it works just as well for bringing an existing site into the fediverse without changing how it looks.

hackers.pub

Hackers' Pub: Local timeline

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Wrote up the story of moving my blog, Hong Minhee on Things (洪民憙雜記), off PHP and onto Astro + Netlify, and adding ActivityPub support along the way with Fedify.

https://writings.hongminhee.org/2026/07/fedified-blog/

writings.hongminhee.org

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

洪民憙 (Hong Minhee)
@hongminhee@writings.hongminhee.org
I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd…

I added ActivityPub to this blog

I built this blog with Jikji, a static site generator I wrote myself, almost five years ago. Back then I barely knew TypeScript or modern web tooling, and I'd never implemented ActivityPub. TypeScript and modern web tooling are second nature to me now, and ActivityPub has become central to my work. I maintain Fedify, for whatever that's worth, and it bothered me that my own blog wasn't federated. So I fixed that.

The old stack: Jikji and PHP

This blog used to run on Jikji, a static site generator I wrote myself in Deno. Calling it a static site generator is a bit of a stretch, though. Like old Movable Type installations, it didn't just produce HTML; it generated a bit of PHP too. That PHP existed almost entirely for HTTP content negotiation: it read the browser's Accept-Language header and chose among Korean mixed script, hangul-only Korean, English, and Japanese. That's all it did.

I first considered adding a thin ActivityPub implementation directly in PHP, since I was already using it. But I wasn't really writing that PHP by hand; Jikji generated it for me, and I had no interest in hand-coding PHP myself. Federating meant delivering a Create(Article) activity to followers whenever a new post went up, which meant I'd need something like a message queue. Bolting a message queue onto Jikji's generated PHP felt, to me at least, like more complexity than it was worth maintaining. And honestly, with Fedify already around, I had no desire to implement ActivityPub from scratch again.

So I ripped out PHP entirely and decided to bring in Fedify instead.

The new stack: Astro and Netlify

The first decision was to drop Jikji and PHP for Astro, a JavaScript framework built for static-content-heavy sites. I chose Astro largely because it already had a @fedify/astro integration.

I reused as much of the existing CSS and HTML as I could. I'm happy with the current design, and redoing it alongside everything else felt like scope creep waiting to happen. Permalinks stayed exactly as they were. I wanted to replace the stack underneath without visitors noticing anything had changed at all.

For hosting, I went back and forth between Cloudflare Workers and Netlify, and settled on Netlify partly because Fedify had never run there before, and this seemed like a good excuse to add that support. I've hosted static sites on Netlify plenty of times, but this was my first time pairing it with edge functions. The idea of a mostly static site with a few dynamic slices reminded me of the late-nineties web, when a site was static HTML except for whatever lived in /cgi-bin/.

Publishing used to mean committing a Markdown file to Git, pushing, letting GitHub Actions build the static site, and deploying it over SFTP. Now GitHub Actions is out of the build pipeline entirely, since Netlify builds the site itself. It ended up simpler overall.

I'm happy with Astro, and the migration went smoothly. It beats Jikji, which I'd barely touched since building it five years ago. Jikji is now archived; there's no reason left for me to keep maintaining it.

Fitting Fedify into Astro

Updating @fedify/astro

Once I actually tried to add Fedify to Astro, I ran into a problem: @fedify/astro didn't support Astro 7, the current version. The Astro APIs it relied on hadn't changed much internally, but the package's declared compatibility range, and its tests, only went up to Astro 5. So before I could federate the blog, I had to fix @fedify/astro first.

That meant more than widening a version range. The existing tests built a fake Astro context and called the middleware directly, which couldn't catch problems with Vite's SSR configuration, compatibility across adapters, or request routing on a built server. So I wrote new compatibility tests that pack @fedify/astro for real, install it into a small Astro app, build and start the app, and send real HTTP requests to it.

Those tests check, across Astro 5, 6, and 7, that HTML requests reach Astro's pages, that ActivityPub and WebFinger requests are handled by Fedify, and that Astro's 404 Not Found still applies to everything else. For Astro 7 specifically, I also run the tests against Deno and Bun, not just the Node.js adapter.

That work has already been merged upstream and will ship in Fedify 2.4.0.

Static pages, dynamic endpoints

The Astro project as a whole builds with server output, but the existing blog pages are still prerendered, same as before. WebFinger, the actor, the inbox and outbox, the followers collection, and ActivityPub objects are the exceptions: Fedify handles those dynamically, per request. The middleware @fedify/astro provides looks at a request's URL and Accept header and only intercepts what Fedify is meant to handle. The same URL can return the existing Astro page for an HTML request and a Fedify-built object for an ActivityPub one.

What visitors see is still, for all practical purposes, a static site. Nearly all the new dynamic surface lives somewhere only other fediverse servers ever touch. That's the CGI comparison again.

Person and Article

Adding ActivityPub also meant deciding what counts as an actor here, and what counts as an object. I gave the blog's actor a Person type. Publishing itself is automated, but the actor represents me, the person writing these posts, not a piece of software or a service. So the handle is @hongminhee@writings.hongminhee.org, and the actor's web URL points at the blog.

Each post gets an Article. It has a title and a body, and it lives at its own permalink as a long-form document, which fits Article better than Note. Most major ActivityPub implementations support Article these days, Mastodon included. Human-facing permalinks stayed put; ActivityPub objects got their own URIs instead, shaped like /ap/articles/{year}/{month}/{slug}. Article's url points back at the original permalink, so the object's identity and the web page people actually read stay separate.

Multiple languages took more thought. Representing each language as its own Article would scatter likes and shares for the same post across several objects. So I merged the Korean mixed script, hangul-only Korean, English, and Japanese versions under a single Article, all sharing one permalink. Title, summary, and body each carry language-tagged values for every version, which serialize to JSON-LD as nameMap, summaryMap, and contentMap. For implementations that don't handle per-language values, name, summary, and content also carry a default: English if there's an English version, Korean mixed script otherwise. Each language's HTML page also gets a Link on Article's url, tagged with hreflang.

That way, a receiving server that understands multiple languages can pick a title and body matching the reader's language, and one that doesn't can still fall back to the default. In practice, though, I know of hardly any ActivityPub implementation that renders these multilingual values properly yet. There's an open issue for it on Mastodon's tracker, and a similar proposal on Hackers' Pub's, but neither has a timeline. Some of that is probably a UI design problem as much as anything else.

Running Fedify on Netlify

Unlike serving plain static files, an ActivityPub server needs some state that outlives any single deploy. The actor's signing key can't rotate on every deploy. The followers list can't disappear on the next one either. Both live in Netlify Database.

Incoming and outgoing activities go through a message queue built on Async Workloads. Delivery can be slow or fail outright depending on the receiving server, so it can't all happen inside the function handling the HTTP request. Queuing it separates accepting a request from actually delivering it, and failed deliveries can be retried later. Fedify already abstracts this, with pluggable backend adapters, but there wasn't yet an adapter for Netlify's Async Workloads. So I wrote the @fedify/netlify package, which uses Async Workloads as the queue and keeps delivery-order state in Netlify Database.

Announcing new posts to the fediverse turned out to be a separate problem. A static site finishing its build doesn't tell a running ActivityPub server anything about which posts changed. So on every successful production deploy, I diff the current post list against the previous deploy's. New posts get a Create(Article); edited ones, whether the content or just the timestamp changed, get an Update(Article); removed ones get a Delete(Article). All of it goes out to followers. Retries reuse the same activity ID for the same change, and deploy ordering is checked so that an older deploy syncing late can't undo a newer one.

Netlify's deploy previews and branch deploys have federation turned off entirely. Otherwise every preview would spin up an actor claiming to be this same blog, and a test deploy could end up sending activities to real followers. Locally, I develop against an in-memory store and queue; production is the only place using the persistent database and queue.

Fedify now runs on Netlify Functions, alongside Deno Deploy and Cloudflare Workers, on top of its usual support for Node.js, Deno, and Bun.

Wrapping up

None of this gives the blog a timeline, a reply box, or any other social feature. Writing and reading still work the way they always did, and the permalinks and design are basically untouched. What changed is that the blog, and every post on it, now has a name and address the fediverse understands. Follow @hongminhee@writings.hongminhee.org to get new posts, or look up a post's ActivityPub object URI to find the original.

I've maintained Fedify long enough to show other developers how to implement ActivityPub, and I dogfooded it plenty while building Hollo and Hackers' Pub. But this was the first time I'd added it to a site that was already live, and static at that. Along the way I got a compatibility test suite for the Astro integration, Netlify support, and a handful of deployment and operational problems that no amount of reading docs or unit tests would have surfaced. It turns out Fedify isn't just for building new social networks from scratch; it works just as well for bringing an existing site into the fediverse without changing how it looks.

hackers.pub

Hackers' Pub: Local timeline

kopper :colon_three:
@kopper@not-brain.d.on-t.work · Reply to kopper :colon_three:
one interesting thing with sqlite is its main downside (1 concurrent writer max) can be alleviated if you partition your database, which in something like postgres is only needed if you Scale Massively. like, the bluesky pds software uses sqlite, but partitions it so each user has their own sqlite file, with the expectation that one user won't ever write fast enough for sqlite to be the bottleneck.

this has an interesting interaction with tools like ORMs that aim to be portable among database systems, because they are flat out not built for it and lead you to having One Sqlite For Everything, and can even make doing the correct thing harder by assuming you'll not really live dis/connect to databases all too often. i imagine this is why stuff like nextcloud or gotosocial or forgejo on sqlite is such a slog. you really have to build for sqlite if you want to use sqlite and can't Just have it be Another Option
洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Sharing my post from last November once again today. As I continue to navigate this journey of self-discovery, celebrating my very first International Non-Binary People's Day feels quietly meaningful. Claiming my own space and identity is still a work in progress, but I am deeply grateful for the quiet support and honest conversations that have brought me here. Wishing peace and warmth to everyone celebrating today. 💜💛

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Growing up, I never quite fit into the typical mold of masculinity. My name, Minhee, doesn't help either—it carries a fairly feminine connotation in Korean, which only made it harder to feel any strong sense of male identity.

For the longest time, society categorized me as male, and I didn't really push back against that label. I just went along with it.

But over time, I've realized something important: I don't just lack the traits society expects from men—I have zero interest in pursuing what people call “masculine values.” Sometimes I find myself actively rejecting them.

Things really clicked after I met my spouse, Lisa (@tokolovesme). Through our deep, honest conversations, I finally found words for something I'd felt all along: I'm fundamentally different from a typical cisgender, heterosexual man.

I have come to identify as non-binary and bisexual.

After introducing myself as a man for my entire life, claiming this identity—actually saying “I am non-binary”—still feels new and awkward. But I'm starting to share this truth with the people close to me, one conversation at a time.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

Growing up, I never quite fit into the typical mold of masculinity. My name, Minhee, doesn't help either—it carries a fairly feminine connotation in Korean, which only made it harder to feel any strong sense of male identity.

For the longest time, society categorized me as male, and I didn't really push back against that label. I just went along with it.

But over time, I've realized something important: I don't just lack the traits society expects from men—I have zero interest in pursuing what people call “masculine values.” Sometimes I find myself actively rejecting them.

Things really clicked after I met my spouse, Lisa (@tokolovesme). Through our deep, honest conversations, I finally found words for something I'd felt all along: I'm fundamentally different from a typical cisgender, heterosexual man.

I have come to identify as non-binary and bisexual.

After introducing myself as a man for my entire life, claiming this identity—actually saying “I am non-binary”—still feels new and awkward. But I'm starting to share this truth with the people close to me, one conversation at a time.

Evan Prodromou
@evan@cosocial.ca

Hurting people around you and being forgiven is one way to prove that you are loved, but it's not the only way.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to Sashin

@sashin I mainly work on my F/OSS projects. I need a web browser to check issues, PRs, and related materials, and I use Zed and Ghostty for coding. Zed actually has a built-in terminal, but I find built-in editor terminals to be too cramped, so I don't really use them. I usually assign one project per workspace, but sometimes I'll assign two or more different issues from the same project to separate workspaces.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

I use Fedora Linux as my primary operating system, and I absolutely love GNOME's workspaces. I typically create a workspace for each specific task, assigning a Ghostty, Zed, and Firefox window to each one accordingly. This is because I want to focus on just one task within each workspace. Even after submitting a pull request, I don't close the workspace until it's been reviewed and successfully merged. This way, I'm currently maintaining a total of 8 workspaces.

help.gnome.org

What is a workspace, and how will it help me?

wakest ⁂
@liaizon@wake.st

Cool to see Fedify, Mitra and the FEP processes get some time on stage at the Open Social track at from Sefano and Zach

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to fedicat

@fedicat Yeah, the quote post collision was a clear example. Whether it's deliberate or just indifference, the Mastodon team doesn't seem to treat the API as a shared surface that evolves across implementations. Hard to build on top of that.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to fedicat

@fedicat That's fair. I know other platforms extend the Mastodon API, but I've been reluctant to do the same. It doesn't feel like a surface that's meant to be extended, and I'd rather not pile more non-standard behavior on top of an API that's already a moving target.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to Dawn Ahukanna

@dahukanna I'm not sure I'm following the storage question. Could you say more about what you mean by runtime data here?

On the second point: the Mastodon API and ActivityPub are completely different in design. They're separate specifications: the Mastodon API is a REST API, ActivityPub is an entirely different protocol. The two look nothing alike, so I'm not sure what “Mastodon instance API that implements ActivityPub” refers to.

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

The more I work on Hollo, the more its Mastodon-compatible API feels like a straitjacket. I chose it for a practical reason: people could use existing clients, and I wouldn't have to build a frontend too. I still think that was the right call at the time.

The problem is that clients can only expose what Mastodon's API represents. I keep coming up with ideas, then asking whether the API has anywhere to put them. If it doesn't, I have no way to get the feature in front of users.

ActivityPub API (so-called “C2S”) might be the eventual answer, but it doesn't help much today. I don't know of any clients Hollo users could realistically use with it, and adoption is still limited.

So I keep coming back to the idea that Hollo will need a frontend of its own. I'd keep the Mastodon API for existing apps. I'm not especially eager to take on a whole frontend, but I don't see another way to try ideas that don't fit Mastodon's model.

Nuages
@nuages@mediaformat.org

Hello World

Coucou! This is just a first post announcing Nuages to the world.

Nuages is an ActivityPub app, connecting to your favourite servers that support the Client to Server API.

Follow us to get our latest updates, we’ll be officially launching the app in the coming weeks 😉

mediaformat.org

Nuages – MediaFormat

Do you yearn for a user powered social network? A social space free from constant Ads, Sponsored and AI generated slop? The Fediverse 1 is a network where you c

django
@django@social.coop

Announcing it here publicly for the first time!

I've been building a general purpose activitypub pwa.

Follow @nuages for official updates!

mediaformat.org

Hello World – MediaFormat

Coucou! This is just a first post announcing Nuages to the world. Nuages is an ActivityPub app, connecting to your favourite servers that support the Client to

Nuages
@nuages@mediaformat.org

Hello World

Coucou! This is just a first post announcing Nuages to the world.

Nuages is an ActivityPub app, connecting to your favourite servers that support the Client to Server API.

Follow us to get our latest updates, we’ll be officially launching the app in the coming weeks 😉

mediaformat.org

Nuages – MediaFormat

Do you yearn for a user powered social network? A social space free from constant Ads, Sponsored and AI generated slop? The Fediverse 1 is a network where you c

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social

I recently moved my personal blog from a PHP setup to Astro on Netlify because I wanted to add ActivityPub support with Fedify.

Somehow, it took me until then to realize that I had never actually tried running Fedify on Netlify.

Netlify Database is PostgreSQL, so the persistence side should already fit @fedify/postgres. The less obvious part is background delivery: Netlify Functions cannot keep a queue consumer alive, while Async Workloads uses a push-based model similar to WorkersMessageQueue in @fedify/cfworkers.

So I’m going to try making @fedify/netlify, with my own blog as its first real test case. I wrote down the initial design in issue #930.

github.com

`@fedify/netlify` for Netlify Async Workloads · Issue #930 · fedify-dev/fedify

Background Fedify can serve federation requests from Netlify Functions through the standard Request and Response APIs. Persistent state also does not need a Netlify-specific adapter: Netlify Databa...