๐๏ธ Early Bird tickets for FediCon 2026 are still on sale โ don't miss your chance to grab a discounted pass!
Early Bird tickets are only available for a limited time.
We want this event to be accessible to as many people as possible, so weโre also offering a reduced-fare (early bird) ticket option for attendees who need an even lower-cost option.
Join us for a gathering all about the Fediverse, the Social Web, and the people building what comes next.
๐ August 6โ9, 2026 ๐ UBC campus, Vancouver, BC
๐๏ธ Early Bird tickets for FediCon 2026 are still on sale โ don't miss your chance to grab a discounted pass!
Early Bird tickets are only available for a limited time.
We want this event to be accessible to as many people as possible, so weโre also offering a reduced-fare (early bird) ticket option for attendees who need an even lower-cost option.
Join us for a gathering all about the Fediverse, the Social Web, and the people building what comes next.
๐ August 6โ9, 2026 ๐ UBC campus, Vancouver, BC
๐๏ธ Early Bird tickets for FediCon 2026 are still on sale โ don't miss your chance to grab a discounted pass!
Early Bird tickets are only available for a limited time.
We want this event to be accessible to as many people as possible, so weโre also offering a reduced-fare (early bird) ticket option for attendees who need an even lower-cost option.
Join us for a gathering all about the Fediverse, the Social Web, and the people building what comes next.
๐ August 6โ9, 2026 ๐ UBC campus, Vancouver, BC
7.3 Update Activity
For server to server interactions, an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity. Unlike the client to server handling of the Update activity, this is not a partial update but a complete replacement of the object.
The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.
ALT text
7.3 Update Activity
For server to server interactions, an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity. Unlike the client to server handling of the Update activity, this is not a partial update but a complete replacement of the object.
The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.
7.3 Update Activity
For server to server interactions, an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity. Unlike the client to server handling of the Update activity, this is not a partial update but a complete replacement of the object.
The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.
ALT text
7.3 Update Activity
For server to server interactions, an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity. Unlike the client to server handling of the Update activity, this is not a partial update but a complete replacement of the object.
The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.
ActivityPub being treated as JSON is a good thing.
1/
Some of us are old enough to remember RSS and blogs.
Some of us are old enough to remember the absurd levels of hype that blogs and RSS attracted โ similar to the modern AI hype and recent crypto hype. During that era, it felt like everyone any their pet cat wanted a blog with an RSS feed. During that era, there was a get-rich-quick fever around blogs and RSS.
ActivityPub being treated as JSON is a good thing.
1/
Some of us are old enough to remember RSS and blogs.
Some of us are old enough to remember the absurd levels of hype that blogs and RSS attracted โ similar to the modern AI hype and recent crypto hype. During that era, it felt like everyone any their pet cat wanted a blog with an RSS feed. During that era, there was a get-rich-quick fever around blogs and RSS.
ActivityPub being treated as JSON is a good thing.
1/
Some of us are old enough to remember RSS and blogs.
Some of us are old enough to remember the absurd levels of hype that blogs and RSS attracted โ similar to the modern AI hype and recent crypto hype. During that era, it felt like everyone any their pet cat wanted a blog with an RSS feed. During that era, there was a get-rich-quick fever around blogs and RSS.
ActivityPub being treated as JSON is a good thing.
1/
Some of us are old enough to remember RSS and blogs.
Some of us are old enough to remember the absurd levels of hype that blogs and RSS attracted โ similar to the modern AI hype and recent crypto hype. During that era, it felt like everyone any their pet cat wanted a blog with an RSS feed. During that era, there was a get-rich-quick fever around blogs and RSS.
I think ActivityPub Partial Updates won't work well with attachments or tags.
Not unless there is a way to reliably just target the item in the attachments or tags array that you want to modify. AFAIK, there isn't.
You have to download the old version of the whole attachments or tags array first, update it locally, and then upload the whole (updated) thing. This creates a race-condition.
I think ActivityPub Partial Updates won't work well with attachments or tags.
Not unless there is a way to reliably just target the item in the attachments or tags array that you want to modify. AFAIK, there isn't.
You have to download the old version of the whole attachments or tags array first, update it locally, and then upload the whole (updated) thing. This creates a race-condition.
A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.
I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?
They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.
I'm glad to see Fedify put to use for something like this. Worth checking out.
I'm pleased to announce SiliconBeest v1.0.0, a serverless fediverse software project built on Cloudflare edge computing, aiming for Mastodon API compatibility.
SiliconBeest is a fediverse project designed to run on Cloudflare Workers.
After seeing many fediverse servers become unavailable when Cloudflare had outages, I realized that the fediverse already relies heavily on Cloudflare infrastructure.
So I thought: why not build fediverse software directly on top of Cloudflare?
This project was inspired by Cloudflare Inc.โs Wildebeest project, and it also references some of its ideas and code.
The project name, SiliconBeest, comes from my nickname silicon(sjang) combined with Cloudflareโs Wildebeest.
Iโm still working on making it as inexpensive to run as possible. For now, the goal is to support a small number of users with a small federation footprint on the free plan, and a medium federation footprint on the $5 plan.
From an API perspective, SiliconBeest aims to be compatible with both Mastodon and Misskey APIs. However, as many people know, full compatibility is difficult in practice, so this remains a long-term goal rather than something fully implemented today.
This is still an early version, and many parts are not implemented yet. However, SiliconBeest is an experiment in how lightweight and affordable fediverse software can be when built on top of Cloudflareโs serverless infrastructure, such as Workers, D1, R2, and Queues.
In v1.0.0, I focused on organizing the basic architecture and core functionality first. Going forward, I plan to gradually improve Mastodon API compatibility, federation stability, admin tooling, and documentation.
SiliconBeest can be deployed relatively easily using a GitHub template and Cloudflare.
Create a new repository from the GitHub template.
Set up the required resources and environment on Cloudflare.
Store the Cloudflare API token and required environment variables in GitHub Secrets.
Deploy automatically using GitHub Actions.
Once deployment is complete, finish configuring your instance.
The installation process is still being refined, and Iโm aware that there is plenty of room for improvement. I plan to keep improving the documentation and deployment flow over time, and related PRs are always welcome.
A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.
I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?
They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.
I'm glad to see Fedify put to use for something like this. Worth checking out.
I'm pleased to announce SiliconBeest v1.0.0, a serverless fediverse software project built on Cloudflare edge computing, aiming for Mastodon API compatibility.
SiliconBeest is a fediverse project designed to run on Cloudflare Workers.
After seeing many fediverse servers become unavailable when Cloudflare had outages, I realized that the fediverse already relies heavily on Cloudflare infrastructure.
So I thought: why not build fediverse software directly on top of Cloudflare?
This project was inspired by Cloudflare Inc.โs Wildebeest project, and it also references some of its ideas and code.
The project name, SiliconBeest, comes from my nickname silicon(sjang) combined with Cloudflareโs Wildebeest.
Iโm still working on making it as inexpensive to run as possible. For now, the goal is to support a small number of users with a small federation footprint on the free plan, and a medium federation footprint on the $5 plan.
From an API perspective, SiliconBeest aims to be compatible with both Mastodon and Misskey APIs. However, as many people know, full compatibility is difficult in practice, so this remains a long-term goal rather than something fully implemented today.
This is still an early version, and many parts are not implemented yet. However, SiliconBeest is an experiment in how lightweight and affordable fediverse software can be when built on top of Cloudflareโs serverless infrastructure, such as Workers, D1, R2, and Queues.
In v1.0.0, I focused on organizing the basic architecture and core functionality first. Going forward, I plan to gradually improve Mastodon API compatibility, federation stability, admin tooling, and documentation.
SiliconBeest can be deployed relatively easily using a GitHub template and Cloudflare.
Create a new repository from the GitHub template.
Set up the required resources and environment on Cloudflare.
Store the Cloudflare API token and required environment variables in GitHub Secrets.
Deploy automatically using GitHub Actions.
Once deployment is complete, finish configuring your instance.
The installation process is still being refined, and Iโm aware that there is plenty of room for improvement. I plan to keep improving the documentation and deployment flow over time, and related PRs are always welcome.
A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.
I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?
They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.
I'm glad to see Fedify put to use for something like this. Worth checking out.
I'm pleased to announce SiliconBeest v1.0.0, a serverless fediverse software project built on Cloudflare edge computing, aiming for Mastodon API compatibility.
SiliconBeest is a fediverse project designed to run on Cloudflare Workers.
After seeing many fediverse servers become unavailable when Cloudflare had outages, I realized that the fediverse already relies heavily on Cloudflare infrastructure.
So I thought: why not build fediverse software directly on top of Cloudflare?
This project was inspired by Cloudflare Inc.โs Wildebeest project, and it also references some of its ideas and code.
The project name, SiliconBeest, comes from my nickname silicon(sjang) combined with Cloudflareโs Wildebeest.
Iโm still working on making it as inexpensive to run as possible. For now, the goal is to support a small number of users with a small federation footprint on the free plan, and a medium federation footprint on the $5 plan.
From an API perspective, SiliconBeest aims to be compatible with both Mastodon and Misskey APIs. However, as many people know, full compatibility is difficult in practice, so this remains a long-term goal rather than something fully implemented today.
This is still an early version, and many parts are not implemented yet. However, SiliconBeest is an experiment in how lightweight and affordable fediverse software can be when built on top of Cloudflareโs serverless infrastructure, such as Workers, D1, R2, and Queues.
In v1.0.0, I focused on organizing the basic architecture and core functionality first. Going forward, I plan to gradually improve Mastodon API compatibility, federation stability, admin tooling, and documentation.
SiliconBeest can be deployed relatively easily using a GitHub template and Cloudflare.
Create a new repository from the GitHub template.
Set up the required resources and environment on Cloudflare.
Store the Cloudflare API token and required environment variables in GitHub Secrets.
Deploy automatically using GitHub Actions.
Once deployment is complete, finish configuring your instance.
The installation process is still being refined, and Iโm aware that there is plenty of room for improvement. I plan to keep improving the documentation and deployment flow over time, and related PRs are always welcome.
A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.
I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?
They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.
I'm glad to see Fedify put to use for something like this. Worth checking out.
I'm pleased to announce SiliconBeest v1.0.0, a serverless fediverse software project built on Cloudflare edge computing, aiming for Mastodon API compatibility.
SiliconBeest is a fediverse project designed to run on Cloudflare Workers.
After seeing many fediverse servers become unavailable when Cloudflare had outages, I realized that the fediverse already relies heavily on Cloudflare infrastructure.
So I thought: why not build fediverse software directly on top of Cloudflare?
This project was inspired by Cloudflare Inc.โs Wildebeest project, and it also references some of its ideas and code.
The project name, SiliconBeest, comes from my nickname silicon(sjang) combined with Cloudflareโs Wildebeest.
Iโm still working on making it as inexpensive to run as possible. For now, the goal is to support a small number of users with a small federation footprint on the free plan, and a medium federation footprint on the $5 plan.
From an API perspective, SiliconBeest aims to be compatible with both Mastodon and Misskey APIs. However, as many people know, full compatibility is difficult in practice, so this remains a long-term goal rather than something fully implemented today.
This is still an early version, and many parts are not implemented yet. However, SiliconBeest is an experiment in how lightweight and affordable fediverse software can be when built on top of Cloudflareโs serverless infrastructure, such as Workers, D1, R2, and Queues.
In v1.0.0, I focused on organizing the basic architecture and core functionality first. Going forward, I plan to gradually improve Mastodon API compatibility, federation stability, admin tooling, and documentation.
SiliconBeest can be deployed relatively easily using a GitHub template and Cloudflare.
Create a new repository from the GitHub template.
Set up the required resources and environment on Cloudflare.
Store the Cloudflare API token and required environment variables in GitHub Secrets.
Deploy automatically using GitHub Actions.
Once deployment is complete, finish configuring your instance.
The installation process is still being refined, and Iโm aware that there is plenty of room for improvement. I plan to keep improving the documentation and deployment flow over time, and related PRs are always welcome.
A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.
I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?
They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.
I'm glad to see Fedify put to use for something like this. Worth checking out.
I'm pleased to announce SiliconBeest v1.0.0, a serverless fediverse software project built on Cloudflare edge computing, aiming for Mastodon API compatibility.
SiliconBeest is a fediverse project designed to run on Cloudflare Workers.
After seeing many fediverse servers become unavailable when Cloudflare had outages, I realized that the fediverse already relies heavily on Cloudflare infrastructure.
So I thought: why not build fediverse software directly on top of Cloudflare?
This project was inspired by Cloudflare Inc.โs Wildebeest project, and it also references some of its ideas and code.
The project name, SiliconBeest, comes from my nickname silicon(sjang) combined with Cloudflareโs Wildebeest.
Iโm still working on making it as inexpensive to run as possible. For now, the goal is to support a small number of users with a small federation footprint on the free plan, and a medium federation footprint on the $5 plan.
From an API perspective, SiliconBeest aims to be compatible with both Mastodon and Misskey APIs. However, as many people know, full compatibility is difficult in practice, so this remains a long-term goal rather than something fully implemented today.
This is still an early version, and many parts are not implemented yet. However, SiliconBeest is an experiment in how lightweight and affordable fediverse software can be when built on top of Cloudflareโs serverless infrastructure, such as Workers, D1, R2, and Queues.
In v1.0.0, I focused on organizing the basic architecture and core functionality first. Going forward, I plan to gradually improve Mastodon API compatibility, federation stability, admin tooling, and documentation.
SiliconBeest can be deployed relatively easily using a GitHub template and Cloudflare.
Create a new repository from the GitHub template.
Set up the required resources and environment on Cloudflare.
Store the Cloudflare API token and required environment variables in GitHub Secrets.
Deploy automatically using GitHub Actions.
Once deployment is complete, finish configuring your instance.
The installation process is still being refined, and Iโm aware that there is plenty of room for improvement. I plan to keep improving the documentation and deployment flow over time, and related PRs are always welcome.
A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.
I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?
They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.
I'm glad to see Fedify put to use for something like this. Worth checking out.
I'm pleased to announce SiliconBeest v1.0.0, a serverless fediverse software project built on Cloudflare edge computing, aiming for Mastodon API compatibility.
SiliconBeest is a fediverse project designed to run on Cloudflare Workers.
After seeing many fediverse servers become unavailable when Cloudflare had outages, I realized that the fediverse already relies heavily on Cloudflare infrastructure.
So I thought: why not build fediverse software directly on top of Cloudflare?
This project was inspired by Cloudflare Inc.โs Wildebeest project, and it also references some of its ideas and code.
The project name, SiliconBeest, comes from my nickname silicon(sjang) combined with Cloudflareโs Wildebeest.
Iโm still working on making it as inexpensive to run as possible. For now, the goal is to support a small number of users with a small federation footprint on the free plan, and a medium federation footprint on the $5 plan.
From an API perspective, SiliconBeest aims to be compatible with both Mastodon and Misskey APIs. However, as many people know, full compatibility is difficult in practice, so this remains a long-term goal rather than something fully implemented today.
This is still an early version, and many parts are not implemented yet. However, SiliconBeest is an experiment in how lightweight and affordable fediverse software can be when built on top of Cloudflareโs serverless infrastructure, such as Workers, D1, R2, and Queues.
In v1.0.0, I focused on organizing the basic architecture and core functionality first. Going forward, I plan to gradually improve Mastodon API compatibility, federation stability, admin tooling, and documentation.
SiliconBeest can be deployed relatively easily using a GitHub template and Cloudflare.
Create a new repository from the GitHub template.
Set up the required resources and environment on Cloudflare.
Store the Cloudflare API token and required environment variables in GitHub Secrets.
Deploy automatically using GitHub Actions.
Once deployment is complete, finish configuring your instance.
The installation process is still being refined, and Iโm aware that there is plenty of room for improvement. I plan to keep improving the documentation and deployment flow over time, and related PRs are always welcome.
The Fediverse would be better off if if back-end servers and front-end clients were separate projects.
I have been arguing that for a while. (I know I am not the only one.)
With respect to Fediverse server, there are different types you might want, depending on your needs. And, it would be nice if you could pick and choose (separate from your choice of front-end).
For example, is it single-user or mutli-user? Should it be light-weight, or deal with high-scale? Etc?
The Fediverse would be better off if if back-end servers and front-end clients were separate projects.
I have been arguing that for a while. (I know I am not the only one.)
With respect to Fediverse server, there are different types you might want, depending on your needs. And, it would be nice if you could pick and choose (separate from your choice of front-end).
For example, is it single-user or mutli-user? Should it be light-weight, or deal with high-scale? Etc?
Once again, Jaz lays out a fantastic vision for Fediverse design. Chronological feeds are better than rage-bait algorithms, but they give give loudmouths too much real estate.
- Design for people, not protocols -Community, not one personโs stream of consciousness - Community notes (from trusted sources) on divisive issues
In my work supporting a broad array of open social web community managers, moderators, administrators, and developers, I regularly hear sweeping generalisations like "the fediverse is anti-this", "the fediverse doesnโt approve of that", "the fediverse holds this very specific opinion".
Iโve always struggled with these statements. How can anyone possibly come to a definitive conclusion about what "the fediverse" believes? As I've said before, there isn't just one fediverse, there are a [โฆ]
In my work supporting a broad array of open social web community managers, moderators, administrators, and developers, I regularly hear sweeping generalisations like “the fediverse is anti-this”, “the fediverse doesnโt approve of that”, “the fediverse holds this very specific opinion”.
Iโve always struggled with these statements. How can anyone possibly come to a definitive conclusion about what “the fediverse” believes? As I’ve said before, there isn’t just one fediverse, there are a million fediverses. Youโre only ever subjected to the specific fediverse you inhabit, the community you reside on and the people you choose to follow.
If you happen to follow high-signal accounts – people who post prolifically, loudly, and relentlessly – their sheer output completely shapes your reality. Their volume becomes your perception of what the entire network thinks.
For years, we have held up the chronological timeline as our great escape from this kind of distortion. In the open social web, we often point to our lack of an engagement-driven algorithm as a moral high ground. We donโt have a black box sorting our conversations for outrage and engagement, we just have time. First in, first out.
But Iโve long believed this is an incorrect oversimplification. Pure chronological timelines are incredibly easily dominated. They do not naturally create a balanced feed; rather, they inherently privilege whoever has the most time, the most grievance, and the loudest voice.
Iโve struggled to communicate this clearly, but after reading Tobias Rose-Stockwell’s brilliant breakdown at The Noisy Room Iโm happy to defer to someone way smarter than me. He outlines a simple metaphor for how commercial social media distorts our reality.
ย
Imagine walking into a pub with a hundred people inside. Ninety-seven of them are having perfectly normal, nuanced conversations. Three of them, however, are screaming at the top of their lungs about politics, about each other, about whatever gets a reaction.
Now, imagine the pub employs a bouncer who gets paid by the minute you spend staring at the spectacle. To keep your attention, the bouncer wires those three screaming people into the pub’s PA system and turns it up to eleven. You walk in, you hear the deafening roar of the three-voiced extremes, and you conclude – logically, based on what you are hearing – that the room is entirely full of unhinged trolls.
In the commercial, centralised web, that bouncer is the algorithm. It amplifies the 3% of users who post severely toxic content because toxicity drives engagement and sells ads.
We look at that and say โthank goodness we fired that bouncer, heโs uselessโ. We boast that our decentralised, chronological feeds don’t have algorithms manipulating our conversations. But it turns out we donโt need a bouncer to amplify the toxicity via the PA when our timeline does it automatically for us.
The Chronological Illusion
When you build a network on a purely chronological feed you replace algorithmic amplification with sheer volume. If those same 3% of vocal, toxic, aggrieved accounts are posting twenty times a day while the 97% of us post once or twice, who dominates your timeline? They do. They don’t need a viral algorithm to amplify them, they just need access to the firehose.
First in, first out simply means the most frequent posters are the most frequently seen/heard.
This creates the exact same distortion that The Noisy Room identifies. We perform an environment scan of our fediverse feeds and conclude that a select few dominant voices reflect the zeitgeist. Maybe we see acrimony, rapid-fire hot takes, relentless indignation, and we believe – falsely – that we are in the minority.
This leads to the same tragic outcomes we see on commercial networks. The quiet majority goes silent. People self-censor. They step away from the keyboard, or they leave the platform entirely, ceding the space to the most extreme voices. The loudest users start to believe they are the majority.
Everyone gets each other wrong.
We designed a protocol to save us from algorithms, but we forgot or failed to design for human perception.
We need to design for people, not protocols
If weโre going to build better social media, we have to acknowledge that a pure, unfiltered chronological timeline is not a neutral arbiter. It is a megaphone for the relentless. So, how do we enhance the fediverse to fix this?
1. We need client-side enhancements that recognise when a single account is dominating a timeline. If one account posts say ten times in an hour, those posts could collapse into a single stack on my timeline. Let me choose to expand them. Give me back my chronological view of my community, not one personโs stream of consciousness.
2. We need to stop treating curation as a dirty word. An algorithm designed by a corporation to maximise ad revenue is harmful, yes. An algorithm, which is just a set of robust filtering tools, designed by you to protect your peace and balance your feed is empowering. We need apps and clients that allow members to easily dial down the volume on highly active accounts without having to fully block or unfollow them, softening the edges without severing relationships.
3. The Noisy Room suggests a “Community Check“, a representative layer of polling shown below contentious issues to show what the silent majority actually thinks. While this would be complex to implement across a decentralised network, we can build tools that gauge consensus without relying on the loudest voices. We need to find ways to measure and display community sentiment that isn’t just counting the number of angry, rapid-fire replies. Community managers should be able to add community notes to posts, or reply with them in a fashion that pins them to the OP. Emelia and the W3 SWCG Trust and Safety taskforce has some thoughts on this.
Youโre not in the minority
Most people want their own space, shaped by their needs and their values. They want to connect, share, and learn without being shouted at. The social web is full of these people. I’m one of them. We are the 97% having a normal conversation in the pub while the 3% scream near the bar.
Our goal shouldn’t just be preserving a chronological feed at all costs. Our goal should be building better relationships. We need to ensure that when a new member joins any one of our million fediverses, they see the whole room, not just the people shouting the loudest.
Letโs find our common ground, letโs build tools that reflect the reality of our communities, and letโs give the quiet majority their voice.
ALT text
A depiction of a crowd of people, three are highlighted in red and are louder than the others.
Once again, Jaz lays out a fantastic vision for Fediverse design. Chronological feeds are better than rage-bait algorithms, but they give give loudmouths too much real estate.
- Design for people, not protocols -Community, not one personโs stream of consciousness - Community notes (from trusted sources) on divisive issues
In my work supporting a broad array of open social web community managers, moderators, administrators, and developers, I regularly hear sweeping generalisations like "the fediverse is anti-this", "the fediverse doesnโt approve of that", "the fediverse holds this very specific opinion".
Iโve always struggled with these statements. How can anyone possibly come to a definitive conclusion about what "the fediverse" believes? As I've said before, there isn't just one fediverse, there are a [โฆ]
In my work supporting a broad array of open social web community managers, moderators, administrators, and developers, I regularly hear sweeping generalisations like “the fediverse is anti-this”, “the fediverse doesnโt approve of that”, “the fediverse holds this very specific opinion”.
Iโve always struggled with these statements. How can anyone possibly come to a definitive conclusion about what “the fediverse” believes? As I’ve said before, there isn’t just one fediverse, there are a million fediverses. Youโre only ever subjected to the specific fediverse you inhabit, the community you reside on and the people you choose to follow.
If you happen to follow high-signal accounts – people who post prolifically, loudly, and relentlessly – their sheer output completely shapes your reality. Their volume becomes your perception of what the entire network thinks.
For years, we have held up the chronological timeline as our great escape from this kind of distortion. In the open social web, we often point to our lack of an engagement-driven algorithm as a moral high ground. We donโt have a black box sorting our conversations for outrage and engagement, we just have time. First in, first out.
But Iโve long believed this is an incorrect oversimplification. Pure chronological timelines are incredibly easily dominated. They do not naturally create a balanced feed; rather, they inherently privilege whoever has the most time, the most grievance, and the loudest voice.
Iโve struggled to communicate this clearly, but after reading Tobias Rose-Stockwell’s brilliant breakdown at The Noisy Room Iโm happy to defer to someone way smarter than me. He outlines a simple metaphor for how commercial social media distorts our reality.
ย
Imagine walking into a pub with a hundred people inside. Ninety-seven of them are having perfectly normal, nuanced conversations. Three of them, however, are screaming at the top of their lungs about politics, about each other, about whatever gets a reaction.
Now, imagine the pub employs a bouncer who gets paid by the minute you spend staring at the spectacle. To keep your attention, the bouncer wires those three screaming people into the pub’s PA system and turns it up to eleven. You walk in, you hear the deafening roar of the three-voiced extremes, and you conclude – logically, based on what you are hearing – that the room is entirely full of unhinged trolls.
In the commercial, centralised web, that bouncer is the algorithm. It amplifies the 3% of users who post severely toxic content because toxicity drives engagement and sells ads.
We look at that and say โthank goodness we fired that bouncer, heโs uselessโ. We boast that our decentralised, chronological feeds don’t have algorithms manipulating our conversations. But it turns out we donโt need a bouncer to amplify the toxicity via the PA when our timeline does it automatically for us.
The Chronological Illusion
When you build a network on a purely chronological feed you replace algorithmic amplification with sheer volume. If those same 3% of vocal, toxic, aggrieved accounts are posting twenty times a day while the 97% of us post once or twice, who dominates your timeline? They do. They don’t need a viral algorithm to amplify them, they just need access to the firehose.
First in, first out simply means the most frequent posters are the most frequently seen/heard.
This creates the exact same distortion that The Noisy Room identifies. We perform an environment scan of our fediverse feeds and conclude that a select few dominant voices reflect the zeitgeist. Maybe we see acrimony, rapid-fire hot takes, relentless indignation, and we believe – falsely – that we are in the minority.
This leads to the same tragic outcomes we see on commercial networks. The quiet majority goes silent. People self-censor. They step away from the keyboard, or they leave the platform entirely, ceding the space to the most extreme voices. The loudest users start to believe they are the majority.
Everyone gets each other wrong.
We designed a protocol to save us from algorithms, but we forgot or failed to design for human perception.
We need to design for people, not protocols
If weโre going to build better social media, we have to acknowledge that a pure, unfiltered chronological timeline is not a neutral arbiter. It is a megaphone for the relentless. So, how do we enhance the fediverse to fix this?
1. We need client-side enhancements that recognise when a single account is dominating a timeline. If one account posts say ten times in an hour, those posts could collapse into a single stack on my timeline. Let me choose to expand them. Give me back my chronological view of my community, not one personโs stream of consciousness.
2. We need to stop treating curation as a dirty word. An algorithm designed by a corporation to maximise ad revenue is harmful, yes. An algorithm, which is just a set of robust filtering tools, designed by you to protect your peace and balance your feed is empowering. We need apps and clients that allow members to easily dial down the volume on highly active accounts without having to fully block or unfollow them, softening the edges without severing relationships.
3. The Noisy Room suggests a “Community Check“, a representative layer of polling shown below contentious issues to show what the silent majority actually thinks. While this would be complex to implement across a decentralised network, we can build tools that gauge consensus without relying on the loudest voices. We need to find ways to measure and display community sentiment that isn’t just counting the number of angry, rapid-fire replies. Community managers should be able to add community notes to posts, or reply with them in a fashion that pins them to the OP. Emelia and the W3 SWCG Trust and Safety taskforce has some thoughts on this.
Youโre not in the minority
Most people want their own space, shaped by their needs and their values. They want to connect, share, and learn without being shouted at. The social web is full of these people. I’m one of them. We are the 97% having a normal conversation in the pub while the 3% scream near the bar.
Our goal shouldn’t just be preserving a chronological feed at all costs. Our goal should be building better relationships. We need to ensure that when a new member joins any one of our million fediverses, they see the whole room, not just the people shouting the loudest.
Letโs find our common ground, letโs build tools that reflect the reality of our communities, and letโs give the quiet majority their voice.
ALT text
A depiction of a crowd of people, three are highlighted in red and are louder than the others.
Once again, Jaz lays out a fantastic vision for Fediverse design. Chronological feeds are better than rage-bait algorithms, but they give give loudmouths too much real estate.
- Design for people, not protocols -Community, not one personโs stream of consciousness - Community notes (from trusted sources) on divisive issues
In my work supporting a broad array of open social web community managers, moderators, administrators, and developers, I regularly hear sweeping generalisations like "the fediverse is anti-this", "the fediverse doesnโt approve of that", "the fediverse holds this very specific opinion".
Iโve always struggled with these statements. How can anyone possibly come to a definitive conclusion about what "the fediverse" believes? As I've said before, there isn't just one fediverse, there are a [โฆ]
In my work supporting a broad array of open social web community managers, moderators, administrators, and developers, I regularly hear sweeping generalisations like “the fediverse is anti-this”, “the fediverse doesnโt approve of that”, “the fediverse holds this very specific opinion”.
Iโve always struggled with these statements. How can anyone possibly come to a definitive conclusion about what “the fediverse” believes? As I’ve said before, there isn’t just one fediverse, there are a million fediverses. Youโre only ever subjected to the specific fediverse you inhabit, the community you reside on and the people you choose to follow.
If you happen to follow high-signal accounts – people who post prolifically, loudly, and relentlessly – their sheer output completely shapes your reality. Their volume becomes your perception of what the entire network thinks.
For years, we have held up the chronological timeline as our great escape from this kind of distortion. In the open social web, we often point to our lack of an engagement-driven algorithm as a moral high ground. We donโt have a black box sorting our conversations for outrage and engagement, we just have time. First in, first out.
But Iโve long believed this is an incorrect oversimplification. Pure chronological timelines are incredibly easily dominated. They do not naturally create a balanced feed; rather, they inherently privilege whoever has the most time, the most grievance, and the loudest voice.
Iโve struggled to communicate this clearly, but after reading Tobias Rose-Stockwell’s brilliant breakdown at The Noisy Room Iโm happy to defer to someone way smarter than me. He outlines a simple metaphor for how commercial social media distorts our reality.
ย
Imagine walking into a pub with a hundred people inside. Ninety-seven of them are having perfectly normal, nuanced conversations. Three of them, however, are screaming at the top of their lungs about politics, about each other, about whatever gets a reaction.
Now, imagine the pub employs a bouncer who gets paid by the minute you spend staring at the spectacle. To keep your attention, the bouncer wires those three screaming people into the pub’s PA system and turns it up to eleven. You walk in, you hear the deafening roar of the three-voiced extremes, and you conclude – logically, based on what you are hearing – that the room is entirely full of unhinged trolls.
In the commercial, centralised web, that bouncer is the algorithm. It amplifies the 3% of users who post severely toxic content because toxicity drives engagement and sells ads.
We look at that and say โthank goodness we fired that bouncer, heโs uselessโ. We boast that our decentralised, chronological feeds don’t have algorithms manipulating our conversations. But it turns out we donโt need a bouncer to amplify the toxicity via the PA when our timeline does it automatically for us.
The Chronological Illusion
When you build a network on a purely chronological feed you replace algorithmic amplification with sheer volume. If those same 3% of vocal, toxic, aggrieved accounts are posting twenty times a day while the 97% of us post once or twice, who dominates your timeline? They do. They don’t need a viral algorithm to amplify them, they just need access to the firehose.
First in, first out simply means the most frequent posters are the most frequently seen/heard.
This creates the exact same distortion that The Noisy Room identifies. We perform an environment scan of our fediverse feeds and conclude that a select few dominant voices reflect the zeitgeist. Maybe we see acrimony, rapid-fire hot takes, relentless indignation, and we believe – falsely – that we are in the minority.
This leads to the same tragic outcomes we see on commercial networks. The quiet majority goes silent. People self-censor. They step away from the keyboard, or they leave the platform entirely, ceding the space to the most extreme voices. The loudest users start to believe they are the majority.
Everyone gets each other wrong.
We designed a protocol to save us from algorithms, but we forgot or failed to design for human perception.
We need to design for people, not protocols
If weโre going to build better social media, we have to acknowledge that a pure, unfiltered chronological timeline is not a neutral arbiter. It is a megaphone for the relentless. So, how do we enhance the fediverse to fix this?
1. We need client-side enhancements that recognise when a single account is dominating a timeline. If one account posts say ten times in an hour, those posts could collapse into a single stack on my timeline. Let me choose to expand them. Give me back my chronological view of my community, not one personโs stream of consciousness.
2. We need to stop treating curation as a dirty word. An algorithm designed by a corporation to maximise ad revenue is harmful, yes. An algorithm, which is just a set of robust filtering tools, designed by you to protect your peace and balance your feed is empowering. We need apps and clients that allow members to easily dial down the volume on highly active accounts without having to fully block or unfollow them, softening the edges without severing relationships.
3. The Noisy Room suggests a “Community Check“, a representative layer of polling shown below contentious issues to show what the silent majority actually thinks. While this would be complex to implement across a decentralised network, we can build tools that gauge consensus without relying on the loudest voices. We need to find ways to measure and display community sentiment that isn’t just counting the number of angry, rapid-fire replies. Community managers should be able to add community notes to posts, or reply with them in a fashion that pins them to the OP. Emelia and the W3 SWCG Trust and Safety taskforce has some thoughts on this.
Youโre not in the minority
Most people want their own space, shaped by their needs and their values. They want to connect, share, and learn without being shouted at. The social web is full of these people. I’m one of them. We are the 97% having a normal conversation in the pub while the 3% scream near the bar.
Our goal shouldn’t just be preserving a chronological feed at all costs. Our goal should be building better relationships. We need to ensure that when a new member joins any one of our million fediverses, they see the whole room, not just the people shouting the loudest.
Letโs find our common ground, letโs build tools that reflect the reality of our communities, and letโs give the quiet majority their voice.
ALT text
A depiction of a crowd of people, three are highlighted in red and are louder than the others.
Looking to hear from #ActivityPub and #FediDev audiences: When do you expect a link (either an id or a Link.href) to have an AS2 representation? When do you expect it might *not* have one? Is there a good way to make those expectations clearer or more explicit? Please weigh in.
Looking to hear from #ActivityPub and #FediDev audiences: When do you expect a link (either an id or a Link.href) to have an AS2 representation? When do you expect it might *not* have one? Is there a good way to make those expectations clearer or more explicit? Please weigh in.
Does #mastodon support a root level domain handles yet? Like, say, user having his AP-enabled single-user website under example.com having a @example.com handle instead of @something@example.com
Does #mastodon support a root level domain handles yet? Like, say, user having his AP-enabled single-user website under example.com having a @example.com handle instead of @something@example.com
ActivityPub specifications don't seem to provide a way to do Idempotent POSTs to your outbox.
That seems like a problem for C2S to me.
Networks are unreliable. You cannot tell the difference between an unreceived request vs an unreceived response. You'll get unwanted identical duplicate activities.
Although it isn't difficult to solve โ a convention just needs to be picked.
For example, a new Idempotency field could be added to the JSON-LD payload.
ActivityPub specifications don't seem to provide a way to do Idempotent POSTs to your outbox.
That seems like a problem for C2S to me.
Networks are unreliable. You cannot tell the difference between an unreceived request vs an unreceived response. You'll get unwanted identical duplicate activities.
Although it isn't difficult to solve โ a convention just needs to be picked.
For example, a new Idempotency field could be added to the JSON-LD payload.
ActivityPub specifications don't seem to provide a way to do Idempotent POSTs to your outbox.
That seems like a problem for C2S to me.
Networks are unreliable. You cannot tell the difference between an unreceived request vs an unreceived response. You'll get unwanted identical duplicate activities.
Although it isn't difficult to solve โ a convention just needs to be picked.
For example, a new Idempotency field could be added to the JSON-LD payload.
ActivityPub specifications don't seem to provide a way to do Idempotent POSTs to your outbox.
That seems like a problem for C2S to me.
Networks are unreliable. You cannot tell the difference between an unreceived request vs an unreceived response. You'll get unwanted identical duplicate activities.
Although it isn't difficult to solve โ a convention just needs to be picked.
For example, a new Idempotency field could be added to the JSON-LD payload.
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
โข "Accepted" rather than "Accept" โข "Added" rather than "Add" โข "Announced" rather than "Announce" โข "Arrived" rather than "Arrive" โข "Blocked" rather than "Block" โข "Created" rather than "Create" โข etc
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.
The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.
This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:
mjankowski
commented
on Nov 21, 2024
This has been rebased/maintained for ~2.5 years, which is somewhat absurd.
Is there anything I can do review-wise to help nudge this forward and/or decide to kill it ... or are just waiting on reviewer availability from team?
rkingett
commented
on Nov 26, 2024
This needs to be merged!
ALT text
github issue: Hide subthreads by blocked users when looking at a post's descendants#18468
ClearlyClaire
wants to merge 10 commits into
mastodon:main
from
ClearlyClaire:features/hide-blocked-users
github issue comments:
graue
commented
on Aug 22, 2024
@Gargron, please allow this to be merged! It's incredibly frustrating that when I get an abusive reply, there's nothing I can do to avoid providing a platform for it - short of deleting my own post that the person replied to. This is such an easy win that will help prevent people from being forced off of Mastodon due to toxic harassment.
Divine, a short video Vine-like experience, had their app go live this week. It includes vintage vines previously archived from the original platform. Instant nostalgia is a great hook.
But the thing I find most interesting - this is a Nostr app. But itโs not being presented to users as such, at all.
Lots of new Nostr users who donโt even know they ARE Nostr users. Iโm curious how this will work out!
Divine, a short video Vine-like experience, had their app go live this week. It includes vintage vines previously archived from the original platform. Instant nostalgia is a great hook.
But the thing I find most interesting - this is a Nostr app. But itโs not being presented to users as such, at all.
Lots of new Nostr users who donโt even know they ARE Nostr users. Iโm curious how this will work out!
Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!
Divine, a short video Vine-like experience, had their app go live this week. It includes vintage vines previously archived from the original platform. Instant nostalgia is a great hook.
But the thing I find most interesting - this is a Nostr app. But itโs not being presented to users as such, at all.
Lots of new Nostr users who donโt even know they ARE Nostr users. Iโm curious how this will work out!
Thought here โฆ #fediforum, #fedidev, #atproto builders who are deeper in the architecture than I can getโฆ
Are there any self-hosting options out there that can literally just be the sign-in server for other services? Whereโs our independent, federated โsign in with {Google/fb/linkedIn/mastodon}โ option? Am I just talking about a Mastodon instance that doesnโt federate and doesnโt allow posting?
Maybe this is not even a need, Iโm trying to assemble a systems theory map in my head.
Thought here โฆ #fediforum, #fedidev, #atproto builders who are deeper in the architecture than I can getโฆ
Are there any self-hosting options out there that can literally just be the sign-in server for other services? Whereโs our independent, federated โsign in with {Google/fb/linkedIn/mastodon}โ option? Am I just talking about a Mastodon instance that doesnโt federate and doesnโt allow posting?
Maybe this is not even a need, Iโm trying to assemble a systems theory map in my head.
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
I think it is probably a bad idea to just restrict it to things with 'type': "Application", "Group", "Organization", "Person", and "Service". Restricting it to just those would mean you couldn't have new actor types (and sub-types) in the future.
So then, do we do it in a duck-typing way? And if "yes", how?
Maybe if something has an "inbox" OR and "outbox" it is an Actor. I.e., it could have just one of those.
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
I think it is probably a bad idea to just restrict it to things with 'type': "Application", "Group", "Organization", "Person", and "Service". Restricting it to just those would mean you couldn't have new actor types (and sub-types) in the future.
So then, do we do it in a duck-typing way? And if "yes", how?
Maybe if something has an "inbox" OR and "outbox" it is an Actor. I.e., it could have just one of those.
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:
2/X Thats why we are building Fediway โ not as a way to dictate which algorithm a platform should use, but as a powerful framework that lets you build your own feed #algorithms for your #Mastodon instance.
I think it is probably a bad idea to just restrict it to things with 'type': "Application", "Group", "Organization", "Person", and "Service". Restricting it to just those would mean you couldn't have new actor types (and sub-types) in the future.
So then, do we do it in a duck-typing way? And if "yes", how?
Maybe if something has an "inbox" OR and "outbox" it is an Actor. I.e., it could have just one of those.
I think it is probably a bad idea to just restrict it to things with 'type': "Application", "Group", "Organization", "Person", and "Service". Restricting it to just those would mean you couldn't have new actor types (and sub-types) in the future.
So then, do we do it in a duck-typing way? And if "yes", how?
Maybe if something has an "inbox" OR and "outbox" it is an Actor. I.e., it could have just one of those.
I think it is probably a bad idea to just restrict it to things with 'type': "Application", "Group", "Organization", "Person", and "Service". Restricting it to just those would mean you couldn't have new actor types (and sub-types) in the future.
So then, do we do it in a duck-typing way? And if "yes", how?
Maybe if something has an "inbox" OR and "outbox" it is an Actor. I.e., it could have just one of those.
I think it is probably a bad idea to just restrict it to things with 'type': "Application", "Group", "Organization", "Person", and "Service". Restricting it to just those would mean you couldn't have new actor types (and sub-types) in the future.
So then, do we do it in a duck-typing way? And if "yes", how?
Maybe if something has an "inbox" OR and "outbox" it is an Actor. I.e., it could have just one of those.
- Objects identified using fragment IDs SHOULD NOT have integrity proofs. It is enough to secure the top-level document. - Verifiers SHOULD ignore proofs that use unsupported algorithms and verification methods. This requirement provides forward compatibility, which is important because sooner or later we will need to use different algorithms.
Your player gains things in the game by being followed (and perhaps following back) Actors on the Fediverse.
For example, you would have a team. The characters on your team would be Fedivese Actors / accounts. This could be bot accounts, but could also be the accounts of other people playing the game.
Same with energy sources, special powers, etc โ all Fedivese Actors / accounts.
I think Mastodon will strip image attachments from ActivityPub 'Question' objects.
That is too bad.
That means even if you create an 'Question' with 'Image' attachments elsewhere, you still won't see them in Mastodon (or in the Mastodon client-server API)
โฆ
I guess the work-around is to post a 'Note' with an 'Image' attachment(s), and then reply to it with a 'Question'. That feels clunkier, but doable
I got access to the iOS version of @HolosSocial and I'm excited to give it a go.
I'm wanting to setup my own relay, but not sure I can wait until next weekend to try it out! Might break down and setup a temp account on holos.social.
I got access to the iOS version of @HolosSocial and I'm excited to give it a go.
I'm wanting to setup my own relay, but not sure I can wait until next weekend to try it out! Might break down and setup a temp account on holos.social.
I got access to the iOS version of @HolosSocial and I'm excited to give it a go.
I'm wanting to setup my own relay, but not sure I can wait until next weekend to try it out! Might break down and setup a temp account on holos.social.
I got access to the iOS version of @HolosSocial and I'm excited to give it a go.
I'm wanting to setup my own relay, but not sure I can wait until next weekend to try it out! Might break down and setup a temp account on holos.social.
(For example, the low-level asset flow destination address or route could be in an HTTP header, or in the HTML <head> as a <meta /> or <link /> or <script>, etc.)
So, that suggests we may need to create a new URI scheme for this.
(Of course, I think we would still want a way to make it work with acct URIs, too, as a back-up. But the new URI scheme would be attempted first when trying to do a resolution.)
Fediverse IDs get turned into acct URIs before they given to WebFinger.
But, acct URIs don't support paths.
So, what do you give WebFinger if you Fediverse ID has a path.
As I mentioned before, either you (1) have to use some other type of URI with WebFinger, or (2) use an acct URI with WebFinger and have the path come into play at some point AFTER the WebFinger step.
Or, do both. First trying โ1, and if that fails trying โ2.
Do you somehow give that information to WebFinger?
acct URIs don't support paths.
So, either you (1) have to use some other type of URI with WebFinger, or (2) use an acct URI and have the path come into play at some point AFTER the WebFinger step.
Or, could do both, trying โ1 first, and if that fails, trying โ2.
What happens if you want to send it to a sub- asset flow destination. The exact notation for it is yet to be decided, but, what if the Fediverse'ish ID is somethinglike:
๏ผ joeblow๏ผ exampleยทcom/prd123
Or, the asset flow address is somethinglike:
%joeblow๏ผ exampleยทcom/prd123
(Assuming we use the "%" character as the prefix.)
I wish ActivityPub extensions would stop putting stuff in "attachment".
When new developers come to ActivityPub they expect dot-notation to work when working with JSON. Ex:
actor.publicKey.publicKeyPem
Some of them later discover that JSON-LD is not JSON (despite having "JSON" in its name). And, while dot-notation sometimes works, arrays can appear in unexpected places, etc.
Putting stuff in "attachment" makes it so dot-notation never works. It is worse than the JSON-LD problem.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
We're working on a new #tutorial for #Fedify: Building a Federated Blog with Astro!
It walks you through creating a hybrid blogโstatic Markdown posts powered by #Astro content collections, with #ActivityPub federation layered on top. By the end, your blog will be followable from Mastodon, send Create/Update/Delete activities when you publish or edit posts, and display #fediverse replies as comments.
Activity Intents are now supported (or soon to be) by the biggest #Fediverse apps out there: WordPress, Mastodon, and Loops (plus a tiny ones, like Forte, streams, PieFed, and Emissary)
It's a fantastic step that brings the social web closer together ๐ป
But there's more to do.
What happens if I want to `Follow` but don't already have an account? Our UX still has gaps.
Please check out FEP-7b29 ~ a simple way to connect the dots all the way through new user signup
Holos Discover added a couple of new filters to its API search - minimum likes and minimum boosts. Additionally, you can pass contentType=image|video|audio|text|all|none to the `/api/search` endpoint and it works.
Interesting combinations, which I took advantage of for the Open Web Image Gallery.
Holos Discover added a couple of new filters to its API search - minimum likes and minimum boosts. Additionally, you can pass contentType=image|video|audio|text|all|none to the `/api/search` endpoint and it works.
Interesting combinations, which I took advantage of for the Open Web Image Gallery.
Activity Intents are now supported (or soon to be) by the biggest #Fediverse apps out there: WordPress, Mastodon, and Loops (plus a tiny ones, like Forte, streams, PieFed, and Emissary)
It's a fantastic step that brings the social web closer together ๐ป
But there's more to do.
What happens if I want to `Follow` but don't already have an account? Our UX still has gaps.
Please check out FEP-7b29 ~ a simple way to connect the dots all the way through new user signup
Holos Discover added a couple of new filters to its API search - minimum likes and minimum boosts. Additionally, you can pass contentType=image|video|audio|text|all|none to the `/api/search` endpoint and it works.
Interesting combinations, which I took advantage of for the Open Web Image Gallery.
Holos Discover added a couple of new filters to its API search - minimum likes and minimum boosts. Additionally, you can pass contentType=image|video|audio|text|all|none to the `/api/search` endpoint and it works.
Interesting combinations, which I took advantage of for the Open Web Image Gallery.
Holos Discover added a couple of new filters to its API search - minimum likes and minimum boosts. Additionally, you can pass contentType=image|video|audio|text|all|none to the `/api/search` endpoint and it works.
Interesting combinations, which I took advantage of for the Open Web Image Gallery.
Activity Intents are now supported (or soon to be) by the biggest #Fediverse apps out there: WordPress, Mastodon, and Loops (plus a tiny ones, like Forte, streams, PieFed, and Emissary)
It's a fantastic step that brings the social web closer together ๐ป
But there's more to do.
What happens if I want to `Follow` but don't already have an account? Our UX still has gaps.
Please check out FEP-7b29 ~ a simple way to connect the dots all the way through new user signup
Activity Intents are now supported (or soon to be) by the biggest #Fediverse apps out there: WordPress, Mastodon, and Loops (plus a tiny ones, like Forte, streams, PieFed, and Emissary)
It's a fantastic step that brings the social web closer together ๐ป
But there's more to do.
What happens if I want to `Follow` but don't already have an account? Our UX still has gaps.
Please check out FEP-7b29 ~ a simple way to connect the dots all the way through new user signup
I've started working on generating RFC9421 compatible HTTP-Signatures in #GoActivityPub about a week and a half ago, but it felt more like a month.
Writing tests for the client module took the bulk of this time and it was a proper slog. We did manage to increase code coverage from under 20% to 80% plus.
This makes it a bit harder to migrate to a new API when the future version 1 of the library will be tagged, but the changes I have planned shouldn't be insurmountable.
Now I just need to implement the verification, and I'll be done with what is a very large milestone for the library.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!
Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!
Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse โ just read from their outbox.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8โ9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
COSCUP๏ผConference for Open Source Coders, Users, and Promoters๏ผใฏใๅฐๆนพใปๅฐๅใงๆฏๅนด้ๅฌใใใ็กๆใฎใชใผใใณใฝใผในใซใณใใกใฌใณในใงใใๆฑใขใธใข็ใฎFOSDEMใจใคใกใผใธใใฆใใใ ใใใฐใใใใใใใใจๆใใพใใไปๅนดใฏ8ๆ8โ9ๆฅใซๅฝ็ซๅฐๆนพ็งๆๅคงๅญฆใซใฆUbuCon Asia 2026ใจๅ ฑๅ้ๅฌใใใพใใ
FediDev KR and FediLUG (Japan) are pleased to announce the Fediverse & Social Web track at COSCUP 2026, and invite participants to submit proposals for talks.
COSCUP (Conference for Open Source Coders, Users, and Promoters) is a free, community-run open source conference held annually in Taipei, Taiwan. Think FOSDEM, but in East Asia. This year it takes place August 8โ9 at the National Taiwan University of Science and Technology, and is co-hosted with UbuCon Asia 2026.
The Fediverse & Social Web track runs for a full day, six hours in total. It is the first dedicated fediverse track at a major open source conference in East Asia, and we hope it becomes a regular gathering point for the fediverse community in the region.
Format
The default talk length is 30 minutes. If you need more or less time, note your preferred length when submitting.
Topics
We welcome proposals on anything related to the fediverse and the open social web, including:
Implementations of ActivityPub or related protocols
Clients for ActivityPub-enabled software
Libraries, toolkits, and frameworks for fediverse development
You can write your proposal in English or Chinese. COSCUP publishes session descriptions bilingually in English and Chinese, but that translation happens after acceptance; you don't need to provide both languages when submitting.
All sessions will be recorded and released under CC BY-SA 4.0. If your talk contains material that cannot be recorded or released under those terms, please note this in your submission.
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
@COSCUP 2026๏ผๅฐๅใ8ๆ8โ9ๆฅ๏ผใซใฆใFediverse & Social Webใใฉใใฏใๆกๆใใใพใใ๏ผ#ใใงใใฃใใผในใ#ActivityPubใใชใผใใณใชใฝใผใทใฃใซใฆใงใใใใผใใซใไธธไธๆฅใป่จ6ๆ้ใฎใใฉใใฏใไบๅฎใใฆใใพใใ
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
@COSCUP 2026๏ผๅฐๅใ8ๆ8โ9ๆฅ๏ผใซใฆใFediverse & Social Webใใฉใใฏใๆกๆใใใพใใ๏ผ#ใใงใใฃใใผในใ#ActivityPubใใชใผใใณใชใฝใผใทใฃใซใฆใงใใใใผใใซใไธธไธๆฅใป่จ6ๆ้ใฎใใฉใใฏใไบๅฎใใฆใใพใใ
@COSCUP 2026๏ผๅฐๅใ8ๆ8โ9ๆฅ๏ผใซใฆใFediverse & Social Webใใฉใใฏใๆกๆใใใพใใ๏ผ#ใใงใใฃใใผในใ#ActivityPubใใชใผใใณใชใฝใผใทใฃใซใฆใงใใใใผใใซใไธธไธๆฅใป่จ6ๆ้ใฎใใฉใใฏใไบๅฎใใฆใใพใใ
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
@COSCUP 2026๏ผๅฐๅใ8ๆ8โ9ๆฅ๏ผใซใฆใFediverse & Social Webใใฉใใฏใๆกๆใใใพใใ๏ผ#ใใงใใฃใใผในใ#ActivityPubใใชใผใใณใชใฝใผใทใฃใซใฆใงใใใใผใใซใไธธไธๆฅใป่จ6ๆ้ใฎใใฉใใฏใไบๅฎใใฆใใพใใ
@COSCUP 2026๏ผๅฐๅใ8ๆ8โ9ๆฅ๏ผใซใฆใFediverse & Social Webใใฉใใฏใๆกๆใใใพใใ๏ผ#ใใงใใฃใใผในใ#ActivityPubใใชใผใใณใชใฝใผใทใฃใซใฆใงใใใใผใใซใไธธไธๆฅใป่จ6ๆ้ใฎใใฉใใฏใไบๅฎใใฆใใพใใ
Our Fediverse & Social Web track has been accepted for @COSCUP 2026 (Taipei, Aug 8โ9)! We'll have a full dayโsix hoursโto fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn't open yet, but we'll announce it here when it is. Stay tuned!
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue โ utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue โ leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue โ can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
We are pleased to announce the release of #Fedify 1.7.0. This release was expedited at the request of the Ghost team, who are actively using Fedify for their #ActivityPub implementation. As a result, several features originally planned for this version have been moved to Fedify 1.8.0 to ensure timely delivery of the most critical improvements.
This release focuses on enhancing message queue functionality and improving compatibility with ActivityPub servers through refined HTTP signature handling.
Native retry mechanism support
This release introduces support for native retry mechanisms in message queue backends. The new MessageQueue.nativeRetrial property allows queue implementations to indicate whether they provide built-in retry functionality, enabling Fedify to optimize its retry behavior accordingly.
When nativeRetrial is set to true, Fedify will delegate retry handling to the queue backend rather than implementing its own retry logic. This approach reduces overhead and leverages the proven retry mechanisms of established queue systems.
Current implementations with native retry support include:
DenoKvMessageQueue โ utilizes Deno KV's automatic retry with exponential backoff
WorkersMessageQueue โ leverages Cloudflare Queues' automatic retry and dead-letter queue features
AmqpMessageQueue โ can now be configured to use AMQP broker's native retry mechanisms
Alongside Fedify 1.7.0, we have also released @fedify/amqp 0.3.0. This release adds the nativeRetrial option to AmqpMessageQueueOptions, enabling you to leverage your AMQP broker's built-in retry mechanisms. When enabled, this option allows the AMQP broker to handle message retries according to its configured policies, rather than relying on Fedify's internal retry logic.
Configurable double-knocking
The new FederationOptions.firstKnock option provides control over the HTTP Signatures specification used for the initial signature attempt when communicating with previously unknown servers.
Previously, the first knock for newly encountered servers always used RFC 9421 (HTTP Message Signatures), falling back to draft-cavage-http-signatures-12 if needed. With this release, you can now configure which specification to use for the first knock when communicating with unknown servers, with RFC 9421 remaining the default.
Summary
This release maintains Fedify's commitment to reliability and compatibility while laying the groundwork for more efficient message processing. The native retry mechanism support will particularly benefit applications using queue backends with sophisticated retry capabilities, while the double-knocking mechanism addresses real-world compatibility challenges in the ActivityPub ecosystem.
For detailed technical information about these changes, please refer to the changelog in the repository.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like โWebsiteโ, โGitHubโ, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Linkโand PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.
I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.
Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of CALL Service actors associated with it) โ
Maybe a call specific custom top-level attribute would be useful.
But, what about the non- fall-back situation where software could properly support this (when an Actor specifies a list of Service actors associated with it)โฝ
I think some might say, put the associated Service actors in "attachment". And, semantically I think that would work with ActivityPub, but โ I have a very strong dislike with putting everything in "attachment" (and "tag"). It makes parsing difficult.
Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.
Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.
moim.live just crossed 30 members.
Shipped calendar subscription today โ you can now subscribe to your personal schedule directly in Google Calendar and other apps.
Traffic is still an unknown. But I'm not ready to go door-to-door yet anyway. There's one payment feature missing, and that's what I'm building toward next.
ActivityPub is supported and always will be โ but it's not the whole point. The journey to making something genuinely useful is just getting started. Until payments feature shipping, I will not do additional work except for bug fix, changing UI.
moim.live just crossed 30 members.
Shipped calendar subscription today โ you can now subscribe to your personal schedule directly in Google Calendar and other apps.
Traffic is still an unknown. But I'm not ready to go door-to-door yet anyway. There's one payment feature missing, and that's what I'm building toward next.
ActivityPub is supported and always will be โ but it's not the whole point. The journey to making something genuinely useful is just getting started. Until payments feature shipping, I will not do additional work except for bug fix, changing UI.
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
moim.live just crossed 30 members.
Shipped calendar subscription today โ you can now subscribe to your personal schedule directly in Google Calendar and other apps.
Traffic is still an unknown. But I'm not ready to go door-to-door yet anyway. There's one payment feature missing, and that's what I'm building toward next.
ActivityPub is supported and always will be โ but it's not the whole point. The journey to making something genuinely useful is just getting started. Until payments feature shipping, I will not do additional work except for bug fix, changing UI.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Update: we've decided to go ahead and submit the CFP to @COSCUP 2026. The track will be called Fediverse & Social Webโthink FOSDEM's Social Web devroom, but in Taipei. #COSCUP is free to attend, like FOSDEM.
If the track is accepted, would you be interested in coming to Taipei (Aug 8โ9) to give a talk?
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been thinking about adding federation health monitoring to #Fedifyโnot as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedifyโor running federated servers in generalโwould actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
I've been thinking about adding federation health monitoring to #Fedifyโnot as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedifyโor running federated servers in generalโwould actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been thinking about adding federation health monitoring to #Fedifyโnot as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedifyโor running federated servers in generalโwould actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been thinking about adding federation health monitoring to #Fedifyโnot as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedifyโor running federated servers in generalโwould actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
I've been thinking about adding federation health monitoring to #Fedifyโnot as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedifyโor running federated servers in generalโwould actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
I've been thinking about adding federation health monitoring to #Fedifyโnot as a separate data store or custom API, but by extending the existing #OpenTelemetry integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.
Does this sound useful to you? I'm curious whether people building on Fedifyโor running federated servers in generalโwould actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.
I'm building an open source ActivityPub service called "Moim" โ ๋ชจ์ in Korean, meaning gathering or meetup.
It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes โ but places carry meaning on their own, even in quiet, ordinary moments.
So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.
Right now, I'm focusing on three areas:
CRM for Event Organizers
A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
A Federated RSVP Service
I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse โ and ideally, better. Being federated shouldn't mean settling for less.
A Check-in Sharing System
I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.
I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using.
If I'm ready, I will officially announce to public.
ALT text
Check-in screen on Mobile
ALT text
Admin Panel for managing group/place/moderation action
I'm building an open source ActivityPub service called "Moim" โ ๋ชจ์ in Korean, meaning gathering or meetup.
It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes โ but places carry meaning on their own, even in quiet, ordinary moments.
So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.
Right now, I'm focusing on three areas:
CRM for Event Organizers
A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
A Federated RSVP Service
I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse โ and ideally, better. Being federated shouldn't mean settling for less.
A Check-in Sharing System
I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.
I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using.
If I'm ready, I will officially announce to public.
ALT text
Check-in screen on Mobile
ALT text
Admin Panel for managing group/place/moderation action
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.
That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) โ since that is what 'Object' and 'Link' share in common.
I'll just call this common parent: 'Entity'.
...
It could have even been an opportunity to talk about how to handle unknown types.
@soapdog There's a poll-based version specced at https://fediverse.codeberg.page/fep/fep/b06c/, sadly with no notable implementations (wouldn't be interactable by Mastodon etc.), but it's an opportunity to break new ground as an implementer if you know anyone who'd like to experiment with it.
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
@soapdog There's a poll-based version specced at https://fediverse.codeberg.page/fep/fep/b06c/, sadly with no notable implementations (wouldn't be interactable by Mastodon etc.), but it's an opportunity to break new ground as an implementer if you know anyone who'd like to experiment with it.
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
@soapdog There's a poll-based version specced at https://fediverse.codeberg.page/fep/fep/b06c/, sadly with no notable implementations (wouldn't be interactable by Mastodon etc.), but it's an opportunity to break new ground as an implementer if you know anyone who'd like to experiment with it.
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
I'm thinking of proposing a #fediverse/social web community track at @COSCUP 2026 (Aug 8โ9, Taipei)โthink FOSDEM's Social Web devroom, but in East Asia. Before I submit the CFP, I'd love to get a sense of what to call it. What do you think?
Laurens Hof is at it again highlighting the problems of our lack of an adequate ActivityPub API and the hurdles that are to come in it getting adoption. #fedidev
I'm building an open source ActivityPub service called "Moim" โ ๋ชจ์ in Korean, meaning gathering or meetup.
It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes โ but places carry meaning on their own, even in quiet, ordinary moments.
So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.
Right now, I'm focusing on three areas:
CRM for Event Organizers
A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
A Federated RSVP Service
I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse โ and ideally, better. Being federated shouldn't mean settling for less.
A Check-in Sharing System
I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.
I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using.
If I'm ready, I will officially announce to public.
ALT text
Check-in screen on Mobile
ALT text
Admin Panel for managing group/place/moderation action
I'm building an open source ActivityPub service called "Moim" โ ๋ชจ์ in Korean, meaning gathering or meetup.
It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes โ but places carry meaning on their own, even in quiet, ordinary moments.
So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.
Right now, I'm focusing on three areas:
CRM for Event Organizers
A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
A Federated RSVP Service
I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse โ and ideally, better. Being federated shouldn't mean settling for less.
A Check-in Sharing System
I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.
I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using.
If I'm ready, I will officially announce to public.
ALT text
Check-in screen on Mobile
ALT text
Admin Panel for managing group/place/moderation action
I'm building an open source ActivityPub service called "Moim" โ ๋ชจ์ in Korean, meaning gathering or meetup.
It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes โ but places carry meaning on their own, even in quiet, ordinary moments.
So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.
Right now, I'm focusing on three areas:
CRM for Event Organizers
A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
A Federated RSVP Service
I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse โ and ideally, better. Being federated shouldn't mean settling for less.
A Check-in Sharing System
I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.
I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using.
If I'm ready, I will officially announce to public.
ALT text
Check-in screen on Mobile
ALT text
Admin Panel for managing group/place/moderation action
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
@COSCUP 2026๏ผๅฐๅใ8ๆ8ๆฅใ9ๆฅ๏ผใใณใใฅใใใฃใใฉใใฏใฎๆๆกใๅใไปใใฆใใพใใFOSDEMใฎSocial Web devroomใฎใใใชๆใใงใSocial Webใใฉใใฏใ้ใใชใใใชใจๆใฃใฆใใใจใใใงใใ
@COSCUP 2026๏ผๅฐๅใ8ๆ8ๆฅใ9ๆฅ๏ผใใณใใฅใใใฃใใฉใใฏใฎๆๆกใๅใไปใใฆใใพใใFOSDEMใฎSocial Web devroomใฎใใใชๆใใงใSocial Webใใฉใใฏใ้ใใชใใใชใจๆใฃใฆใใใจใใใงใใ
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
@COSCUP 2026๏ผๅฐๅใ8ๆ8ๆฅใ9ๆฅ๏ผใใณใใฅใใใฃใใฉใใฏใฎๆๆกใๅใไปใใฆใใพใใFOSDEMใฎSocial Web devroomใฎใใใชๆใใงใSocial Webใใฉใใฏใ้ใใชใใใชใจๆใฃใฆใใใจใใใงใใ
@COSCUP 2026๏ผๅฐๅใ8ๆ8ๆฅใ9ๆฅ๏ผใใณใใฅใใใฃใใฉใใฏใฎๆๆกใๅใไปใใฆใใพใใFOSDEMใฎSocial Web devroomใฎใใใชๆใใงใSocial Webใใฉใใฏใ้ใใชใใใชใจๆใฃใฆใใใจใใใงใใ
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
@COSCUP 2026๏ผๅฐๅใ8ๆ8ๆฅใ9ๆฅ๏ผใใณใใฅใใใฃใใฉใใฏใฎๆๆกใๅใไปใใฆใใพใใFOSDEMใฎSocial Web devroomใฎใใใชๆใใงใSocial Webใใฉใใฏใ้ใใชใใใชใจๆใฃใฆใใใจใใใงใใ
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
@COSCUP 2026๏ผๅฐๅใ8ๆ8ๆฅใ9ๆฅ๏ผใใณใใฅใใใฃใใฉใใฏใฎๆๆกใๅใไปใใฆใใพใใFOSDEMใฎSocial Web devroomใฎใใใชๆใใงใSocial Webใใฉใใฏใ้ใใชใใใชใจๆใฃใฆใใใจใใใงใใ
I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:
@COSCUP 2026 (Taipei, Aug 8โ9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track thereโsomething in the spirit of the Social Web devroom at FOSDEM.
Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Today @koppershared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.
The author's frustration with naรฏve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you muchโyou end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The โJSON-LD flavored Mastodon APIโ framing is apt.
The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate โclientโ layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.
But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:
C2S server โ a database (PostgreSQL, say)
โClientโ โ an application server (Mastodon, Misskey)
โFrontendโ โ the actual client app on your phone
That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the โclientโ layerโthe bottom boundary.
The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: โwe don't really need a standardized api,โ they write, leaving each client free to expose whatever API it likes.
Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2Sโlog in to any server with any appโisn't actually delivered. It's been pushed one layer down, out of reach of the end user.
There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.
my opinions about how activitypub c2s ought to be implemented, probably with way too much snark for anyone to take it seriously. wrote pretty much all of it at like 1 am so expect the writing to not be great. will prolly regret it tomorrow but eh. whatever
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even excitingโbut never comfortable. That era where your business logic and your protocol plumbing were justโฆ the same thing:
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And waitโwhat's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows itโevery edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you justโฆ build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.
There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.
Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a โpermanentโ link should resolve toโsomething human-readable.
I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedifyโserver-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet. #fedidev
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet. #fedidev
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet. #fedidev
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet. #fedidev
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet. #fedidev
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet. #fedidev
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.
Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a โpermanentโ link should resolve toโsomething human-readable.
I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)
There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.
Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a โpermanentโ link should resolve toโsomething human-readable.
I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)
There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.
Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a โpermanentโ link should resolve toโsomething human-readable.
I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow requestโbut the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanismโif a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as โsupports RFC 9421โโbecause they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
Esta รฉ a maior atualizaรงรฃo da histรณria do Fedify. Destaques:
**Arquitetura modular** โ O pacote monolรญtico `@fedify/fedify` foi dividido em pacotes independentes e focados: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger` e outros. Pacotes menores, imports mais limpos e a possibilidade de estender o ActivityPub com tipos de vocabulรกrio personalizados.
**Painel de depuraรงรฃo em tempo real** โ O novo pacote `@fedify/debugger` oferece um dashboard ao vivo em `/__debug__/` que mostra todo o trรกfego de federaรงรฃo: traces, detalhes das atividades, verificaรงรฃo de assinaturas e logs correlacionados. Basta envolver seu objeto `Federation` e pronto.
**Suporte a relay do ActivityPub** โ Suporte nativo a relays via `@fedify/relay` e o comando CLI `fedify relay`. Compatรญvel com os protocolos Mastodon-style e LitePub-style (FEP-ae0c).
**Entrega ordenada de mensagens** โ A nova opรงรฃo `orderingKey` resolve o problema do "post zumbi", quando um `Delete` chega antes do seu `Create`. Atividades com a mesma chave sรฃo entregues garantidamente na ordem FIFO.
**Tratamento de falhas permanentes** โ `setOutboxPermanentFailureHandler()` permite reagir quando uma inbox remota retorna 404 ou 410, possibilitando limpar seguidores inacessรญveis em vez de tentar reenviar indefinidamente.
Outras novidades incluem negociaรงรฃo de conteรบdo no nรญvel do middleware, `@fedify/lint` para regras compartilhadas de linting, `@fedify/create` para scaffolding rรกpido de projetos, arquivos de configuraรงรฃo para a CLI, suporte nativo ร CLI em Node.js/Bun e diversos fixes de bugs.
Esta versรฃo conta com contribuiรงรตes significativas de participantes do OSSCA da Coreia. Agradecemos imensamente a todos envolvidos!
Trata-se de uma release major com breaking changes. Consulte o guia de migraรงรฃo antes de atualizar.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
Esta รฉ a maior atualizaรงรฃo da histรณria do Fedify. Destaques:
**Arquitetura modular** โ O pacote monolรญtico `@fedify/fedify` foi dividido em pacotes independentes e focados: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger` e outros. Pacotes menores, imports mais limpos e a possibilidade de estender o ActivityPub com tipos de vocabulรกrio personalizados.
**Painel de depuraรงรฃo em tempo real** โ O novo pacote `@fedify/debugger` oferece um dashboard ao vivo em `/__debug__/` que mostra todo o trรกfego de federaรงรฃo: traces, detalhes das atividades, verificaรงรฃo de assinaturas e logs correlacionados. Basta envolver seu objeto `Federation` e pronto.
**Suporte a relay do ActivityPub** โ Suporte nativo a relays via `@fedify/relay` e o comando CLI `fedify relay`. Compatรญvel com os protocolos Mastodon-style e LitePub-style (FEP-ae0c).
**Entrega ordenada de mensagens** โ A nova opรงรฃo `orderingKey` resolve o problema do "post zumbi", quando um `Delete` chega antes do seu `Create`. Atividades com a mesma chave sรฃo entregues garantidamente na ordem FIFO.
**Tratamento de falhas permanentes** โ `setOutboxPermanentFailureHandler()` permite reagir quando uma inbox remota retorna 404 ou 410, possibilitando limpar seguidores inacessรญveis em vez de tentar reenviar indefinidamente.
Outras novidades incluem negociaรงรฃo de conteรบdo no nรญvel do middleware, `@fedify/lint` para regras compartilhadas de linting, `@fedify/create` para scaffolding rรกpido de projetos, arquivos de configuraรงรฃo para a CLI, suporte nativo ร CLI em Node.js/Bun e diversos fixes de bugs.
Esta versรฃo conta com contribuiรงรตes significativas de participantes do OSSCA da Coreia. Agradecemos imensamente a todos envolvidos!
Trata-se de uma release major com breaking changes. Consulte o guia de migraรงรฃo antes de atualizar.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
Esta รฉ a maior atualizaรงรฃo da histรณria do Fedify. Destaques:
**Arquitetura modular** โ O pacote monolรญtico `@fedify/fedify` foi dividido em pacotes independentes e focados: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger` e outros. Pacotes menores, imports mais limpos e a possibilidade de estender o ActivityPub com tipos de vocabulรกrio personalizados.
**Painel de depuraรงรฃo em tempo real** โ O novo pacote `@fedify/debugger` oferece um dashboard ao vivo em `/__debug__/` que mostra todo o trรกfego de federaรงรฃo: traces, detalhes das atividades, verificaรงรฃo de assinaturas e logs correlacionados. Basta envolver seu objeto `Federation` e pronto.
**Suporte a relay do ActivityPub** โ Suporte nativo a relays via `@fedify/relay` e o comando CLI `fedify relay`. Compatรญvel com os protocolos Mastodon-style e LitePub-style (FEP-ae0c).
**Entrega ordenada de mensagens** โ A nova opรงรฃo `orderingKey` resolve o problema do "post zumbi", quando um `Delete` chega antes do seu `Create`. Atividades com a mesma chave sรฃo entregues garantidamente na ordem FIFO.
**Tratamento de falhas permanentes** โ `setOutboxPermanentFailureHandler()` permite reagir quando uma inbox remota retorna 404 ou 410, possibilitando limpar seguidores inacessรญveis em vez de tentar reenviar indefinidamente.
Outras novidades incluem negociaรงรฃo de conteรบdo no nรญvel do middleware, `@fedify/lint` para regras compartilhadas de linting, `@fedify/create` para scaffolding rรกpido de projetos, arquivos de configuraรงรฃo para a CLI, suporte nativo ร CLI em Node.js/Bun e diversos fixes de bugs.
Esta versรฃo conta com contribuiรงรตes significativas de participantes do OSSCA da Coreia. Agradecemos imensamente a todos envolvidos!
Trata-se de uma release major com breaking changes. Consulte o guia de migraรงรฃo antes de atualizar.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
This is the biggest release in Fedify's history. Here are the highlights:
Modular architecture โ The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
Real-time debug dashboard โ The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
ActivityPub relay support โ First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
Ordered message delivery โ The new orderingKey option solves the โzombie postโ problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
Permanent failure handling โ setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changesโplease check the migration guide before upgrading.
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.
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.
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.
Unfortunately for anyone reading this, I had an idea, although I'm not ready to talk publicly about it.
But I do have a question for #fedidev s out here: Is there a nice way to handle account fragmentation? So having 3 accounts for 3 platforms that need to write-interact with the activitypub stream? Really new to all of this, sorry if this question is kinda noob-y
Hey #FediDev gang.. Do you think this is the right way to guide people from personal/organizational websites into the #Fediverse?
Some of this is defined in #FEP3b86. Some of it exists today in #Emissary (and the #oStatus "remote follow") some is being built by @dansup as #WebIntents, and some is just scribbles on paper.
If there's interest, I'm happy to write up the rest of this as an additional #FEP
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.
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.
Hey #FediDev gang.. Do you think this is the right way to guide people from personal/organizational websites into the #Fediverse?
Some of this is defined in #FEP3b86. Some of it exists today in #Emissary (and the #oStatus "remote follow") some is being built by @dansup as #WebIntents, and some is just scribbles on paper.
If there's interest, I'm happy to write up the rest of this as an additional #FEP
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
FEP drafting: Am I using โside effectsโ here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.
The "side effects" of an activity are everything caused by the activity other than it being visible in its actor's outbox and getting posted to its audience's inboxes. For example, a like or reply being represented in the affected object's `likes` or `replies` collection is a side effect, as is likes or replies being shown on a web page corresponding to the object.
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.
FEP drafting: Am I using โside effectsโ here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.
The "side effects" of an activity are everything caused by the activity other than it being visible in its actor's outbox and getting posted to its audience's inboxes. For example, a like or reply being represented in the affected object's `likes` or `replies` collection is a side effect, as is likes or replies being shown on a web page corresponding to the object.
there is currently a #Piefed Hackathon going on if anyone is interested in partaking. There are groups working on spanish, german, french and japanese translations, and a bunch of other things.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
If you cannot get (most) regular people to write JSON-LD, JSON, or even HTML โ
But, you might be able to get them (regular people) to write something similar to Markdown and INI โ
Then, are there ways you could (explicitly or implicitly) encode JSON-LD type information, such as ActivityPub, into a Markdown-like or INI-like file โ in a way where they (regular people) would likely include it?
Unfortunately for anyone reading this, I had an idea, although I'm not ready to talk publicly about it.
But I do have a question for #fedidev s out here: Is there a nice way to handle account fragmentation? So having 3 accounts for 3 platforms that need to write-interact with the activitypub stream? Really new to all of this, sorry if this question is kinda noob-y
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
Soโฆ the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!
Soโฆ the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!
Soโฆ the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!
Soโฆ the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!
Soโฆ the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!
Soโฆ the first day of #FOSDEM 2026 was so inspiring, and it really motivated to build more things for #ActivityPub and the #fediverse! Also it was a lot of fun to meet hundreds of kind and smart people!
The Mastodon team is planning to release a universal "share" button.
(It wasn't clear to me if this was just for Mastodon servers โ or if it would work with non-Mastodon servers, too. It was mentioned briefly from the audience.)
The Mastodon team is planning to release a universal "share" button.
(It wasn't clear to me if this was just for Mastodon servers โ or if it would work with non-Mastodon servers, too. It was mentioned briefly from the audience.)
The Mastodon team is planning to release a universal "share" button.
(It wasn't clear to me if this was just for Mastodon servers โ or if it would work with non-Mastodon servers, too. It was mentioned briefly from the audience.)
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
Day 2 in Brussels (for this trip). I think I have adjusted enough to the time-zone change that I will be able to be (mostly) awake for FOSDEM 2026 โ which takes place this weekend.
Tomorrow (Saturday) is the first day of FOSDEM 2026. I will be attending the Social Web track.
Day 2 in Brussels (for this trip). I think I have adjusted enough to the time-zone change that I will be able to be (mostly) awake for FOSDEM 2026 โ which takes place this weekend.
Tomorrow (Saturday) is the first day of FOSDEM 2026. I will be attending the Social Web track.
If #fedi instances, or accounts on instances, come and go frequently in alpha software, would that kind of churn cause problems with other instances on the #Fediverse? What is the #fediquette for #fediDev?
If #fedi instances, or accounts on instances, come and go frequently in alpha software, would that kind of churn cause problems with other instances on the #Fediverse? What is the #fediquette for #fediDev?
If #fedi instances, or accounts on instances, come and go frequently in alpha software, would that kind of churn cause problems with other instances on the #Fediverse? What is the #fediquette for #fediDev?
I was looking though a feed on a random Friendica instance and recognized an icon that I designed and instantly realized that Friendica is now using my https://iconography.fediverse.info project as an icon source for many pieces of software that federate to them! #fedidev
ALT text
a post that federated to a Friendica instance showing the Bookwyrm icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Ktistec icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Sharkey icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Wafrn icon in the top right hand corner
I was looking though a feed on a random Friendica instance and recognized an icon that I designed and instantly realized that Friendica is now using my https://iconography.fediverse.info project as an icon source for many pieces of software that federate to them! #fedidev
ALT text
a post that federated to a Friendica instance showing the Bookwyrm icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Ktistec icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Sharkey icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Wafrn icon in the top right hand corner
After months of struggling with the โzombie postโ issue on Hackers' Pubโwhere deleted posts wouldn't disappear from remote serversโI had a sudden hypothesis today. As I dug into it, I realized it's a structural issue with Fedify's MessageQueue system: Create(Note) and Delete(Note) activities can be delivered out of order, causing remote instances to receive Delete(Note) before Create(Note).
The fix will likely require API changes, so this will probably need to wait for #Fedify 2.0.0.
After months of struggling with the โzombie postโ issue on Hackers' Pubโwhere deleted posts wouldn't disappear from remote serversโI had a sudden hypothesis today. As I dug into it, I realized it's a structural issue with Fedify's MessageQueue system: Create(Note) and Delete(Note) activities can be delivered out of order, causing remote instances to receive Delete(Note) before Create(Note).
The fix will likely require API changes, so this will probably need to wait for #Fedify 2.0.0.
I was looking though a feed on a random Friendica instance and recognized an icon that I designed and instantly realized that Friendica is now using my https://iconography.fediverse.info project as an icon source for many pieces of software that federate to them! #fedidev
ALT text
a post that federated to a Friendica instance showing the Bookwyrm icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Ktistec icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Sharkey icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Wafrn icon in the top right hand corner
I was looking though a feed on a random Friendica instance and recognized an icon that I designed and instantly realized that Friendica is now using my https://iconography.fediverse.info project as an icon source for many pieces of software that federate to them! #fedidev
ALT text
a post that federated to a Friendica instance showing the Bookwyrm icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Ktistec icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Sharkey icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Wafrn icon in the top right hand corner
I was looking though a feed on a random Friendica instance and recognized an icon that I designed and instantly realized that Friendica is now using my https://iconography.fediverse.info project as an icon source for many pieces of software that federate to them! #fedidev
ALT text
a post that federated to a Friendica instance showing the Bookwyrm icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Ktistec icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Sharkey icon in the top right hand corner
ALT text
a post that federated to a Friendica instance showing the Wafrn icon in the top right hand corner
!["orderedItems": [
"https://localhost:8080/-/019e26f4-456a-77b3-bb80-8ecc8b1a24c9/activity.jsonld",
"https://localhost:8080/-/019e26f4-b6e9-7936-b1cf-5be9dd2c2129/activity.jsonld",
"https://localhost:8080/-/019e26fb-206e-7861-a303-4d88428c8842/activity.jsonld"
]](https://files.mastodon.social/media_attachments/files/116/573/504/597/084/481/original/a5df1eb87744eff9.png)
![{
"subject": "acct:reiver@mastodon.social",
"aliases": [
"https://mastodon.social/@reiver",
"https://mastodon.social/users/reiver"
],
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"type": "text/html",
"href": "https://mastodon.social/@reiver"
},
{
"rel": "self",
"type": "application/activity+json",
"href": "https://mastodon.social/users/reiver"
},
{
"rel": "http://ostatus.org/schema/1.0/subscribe",
"template": "https://mastodon.social/authorize_interaction?uri={uri}"
},
{
"rel": "https://w3id.org/fep/3b86/Create",
"template": "https://mastodon.social/share?text={content}"
},
{
"rel": "https://w3id.org/fep/3b86/Object",
"template": "https://mastodon.social/authorize_interaction?uri={object}"
},
{
"rel": "http://webfinger.net/rel/avatar",
"type": "image/png",
"href": "https://files.mastodon.social/accounts/avatars/108/116/990/725/247/731/original/2e097b7812894201.png"
}
]
}](https://files.mastodon.social/media_attachments/files/116/469/742/963/662/564/original/bb0ed595383447be.png)
!["interactionPolicy": {
"canQuote": {
"automaticApproval": [
"https://mastodon.social/users/reiver"
]
}
},](https://files.mastodon.social/media_attachments/files/116/117/157/844/352/723/original/a7913f3d4ad3ed3f.png)
