#2

We Distribute's avatar
We Distribute

@news@wedistribute.org

Six months after an initial analysis, two Fediverse experts come back to examine where user experience has changed. Are we on the path of redemption, or repeating the same old sins?

Last summer, Tim delivered a two-part online sermon on the Seven Deadly UX Sins plaguing the Fediverse: first the diagnosis, then the path to redemption. Sean wrote his own set of solutions. It was the kind of tough love we felt the Open Social Web desperately needed: unflinching about problems, genuinely hopeful about fixes.

It kicked off a lot of great and constructive discussions.

But redemption requires actual work. Good words alone aren’t enough.

So we decided to play professor every 6 months or so, and grade these redemption efforts; not on vibes, not on good intentions, but on what’s actually shipped since then. And what is about to. The goal is not to be a wagging finger, but to applaud and focus attention on good work. And maybe incite donations and volunteering to move other things faster.

Between Tim’s years running Indieweb.social and Sean’s decade-plus chronicling the distributed web at We Distribute, we’ve watched these problems persist longer than we’d like to admit.

The grading scale:

  • A: Shipped and working. Users benefiting right now.
  • B: Solid progress. Real commits, real momentum, shipping soon.
  • C: Good ideas on paper. Some movement, waiting on execution.
  • D: Acknowledged problem. Minimal progress.
  • F: Crickets. Or actively getting worse.

If we missed anything, reach out and we’ll update this. Let’s dig in.


The List of Sins

As with our previous analysis efforts, we’ve split everything up into sections to make it easier to read, navigate, and parse. These are long-standing issues both Tim and Sean have seen in the Fediverse, with reflections on how things may or may not have changed in the past six months.

Sin 1: Instance Selection Paralysis

Redemption: One Single Social Home to Join, Many Doors Later

The Problem

New users arrive ready to escape Big Tech, and we immediately hit them with 8,000 servers named like medieval taverns crossed with startup pitches. Half bail before creating an account. Why does this happen? Our best reasoning suggests that initially joining an instance feels like a big commitment, and people often have to do this while knowing very little about the community they’re getting into.

Our Suggested Fix

The problem is akin to walking into a restaurant with a really, really big menu. You may have had some idea of what you initially wanted, but as you thumb through the different choices, you start to realize you actually are less certain about what to get. Choice is good, but this is overwhelming.

Here’s the thing: keep the offering of choices simple for people just starting out, and offer a single no-brainer choice to get the ball rolling. If centralization is a concern, it’s possible to offer a curated round-robin of trustworthy servers, preventing any individual instance from being overloaded. While everybody wants some level of choice, they also want a reduction in friction. This is one way to do both.

What’s Happened Recently

Mastodon’s mobile apps have long defaulted to mastodon.social with an optional “choose another server” toggle—exactly where it should be. As they stated in their February 2026 blog post: “As people fled from traditional social media in late 2022, we made a strategic decision to send new sign-ups directly to mastodon.social. This choice was driven by our desire to reduce cognitive load for new users and ensure a stable onboarding experience.” That was the right instinct.

New fediverse apps focused on individual communities like the Toot Wales app, completely streamline this purely into their server. This is part of Newsmast’s overall strategy of empowering news and other local communities, and creating dedicated apps and servers specific for each, with specific onboarding for each community.

Image courtesy of Newsmast Foundation

But recently, the Mastodon team has also recognized the problem and added this: “Right now, too many newcomers default to the largest servers. We want to change that—because Mastodon is best when communities are spread across many independent servers.” They’re actively working on a new mobile flow that points users to other servers. That is very close to our round-robin suggestion. Maybe better, as it does some performance checks for best servers near you.

On web: Mastodon 4.4 shrunk web onboarding from four steps to two—real progress, even if incomplete.

Other platforms are also leading:

  • PieFed shipped an instance chooser very close to our suggestion. It includes a big simple way to join the flagship but also with a “help me choose” button for those who want to go deeper. And like Mastodon: a sophisticated instance chooser that sorts by lots of easy-to-grasp criteria for those who want to dig into it.
  • Loops sends users directly to their main server via JoinLoops.org. Simple, direct. (No round-robin, but we applaud the simplicity as a first start.)
  • Holos takes a radical approach: running a complete ActivityPub server on your phone (from the developer of Fedilab). No server choice because your phone IS your server. The relay provides a stable identity, but onboarding is zero-friction because the concept simply doesn’t exist. See how it works and the FAQ. It’s early-days, but fascinating proof that “pick a server” can be eliminated entirely.

What’s Still Broken

Web onboarding across most of the Fediverse: PixelFed, PeerTube, Misskey, etc., all still ask users to solve a puzzle before joining. At the very least, JoinMastodon.org has improved to a “two choices” flow, but we look forward to seeing this exact same mobile UX being applied to Web. It’s in the works.

For most platforms, it’s more hazing ritual than clean onboarding. And other than the planned effort underway at Mastodon (which at first will be mobile only), none of the others have tried the more simple round-robin idea yet. There no doubt would be some complexity in setting this up, but It’s just waiting there for folks to try.

Sean proposed something more ambitious: identity-first onboarding, where you import your social graph and content before choosing a server. The idea: set up a “pre-identity” that pulls in your posts and connections from other networks, then pick a server that fits. Tools like Bounce from A New Social are experimenting in this direction. It’s still aspirational, but points toward a future where “pick a server” isn’t the first question new users face.

Final Grade

Grade: B-

Mastodon, PieFed, Loops, and Holos earn serious credit for shipping (or about to ship) big parts of what we suggested. PieFed’s instance chooser is particularly noteworthy, but could be integrated on. Now the rest need to follow.


Sin 2: Timeline Turmoil

Redemption: One Feed To Rule Them All (at First)

“Relativity” by MC Escher

The Problem

Mastodon and a lot of other Fediverse platforms offer three different timelines for representing social activities: Home, Local, and Federated. Each more metaphysically confusing than the last. “Home” at least makes sense, because it’s everyone you’re following. “Local” sounds cozy, but is actually your server’s collective brain dump. “Federated” is the cosmic firehose of everything, everywhere, in languages you don’t speak.

Kind of like what happened after the Tower of Babel

What people want is to be able to easily cut through all the noise and connect with people on the subjects that they care about the most. It’s not so much that we want a bunch of different timelines, but a way to dig into one timeline in a bunch of different ways.

Our Suggested Fix

Cut the interface down to one feed, with some tools to bring desired behavior to the forefront. Use progressive disclosure to introduce others as “power-ups,” not puzzles. “Want to see what’s trending nearby?” “Curious about the wider Fediverse?” Let them level up like a video game character.

What’s Happened

Mastodon web has since hidden the extra feeds by default, to their credit. They also did this in Mastodon 4.5:

Feed Toggles: Admins can now selectively disable specific content feeds (like the Federated Timeline or Trending) for both logged-in users and unauthenticated visitors. Good: enables admins to choose simplicity.

Loops launched something especially interesting: They present both a “Following” feed (chronological, people you trust) and a “For You” feed (algorithmic discovery). The key distinction from TikTok: “For You” is powered by engagement and social graph signals, not ads or dark patterns. As they put it: “A calm chronological Following feed for the people you trust—and a For You feed that surfaces new creators. No dark-pattern growth hacks.”

(Minor nitpick: we’d suggest they move “Local” feed back under “Explore” and make it only “Following” and “For You.” But we digress.)

What’s Still Broken

No platform implements the true progressive disclosure idea yet. Multi-timeline confusion remains the default on PeerTube, Misskey, and others.

As Sean put it: “We don’t need more timelines, we need better ones.” Projects like FediAlgo and Channel.org are experimenting with custom feeds and algorithmic filtering, following Bluesky’s lead. The goal isn’t to replicate TikTok’s dopamine machine, but to give users powerful ways to sort and filter their Home timeline without needing to understand federation theory. Sean has been following the ActivityPub Client to Server API developments, with a few clients beginning to experiment with that – notably Ghost and WordPress Reader apps –  and we think there may be room for innovating on unified feed UX there.

Final Grade

Grade: B+

Kudos to Mastodon for giving each admin the ability to choose to bury the feeds that never made sense to each individual server community. Loops gets credit for the right framing. Closest to fully solved. The biggest thing now is to focus on intuitive ways that users can filter and curate their own timeline experiences. When more critical mass of platforms actually hide extra timelines until users ask, we’re looking at an A.


Sin 3: Remote Interaction Purgatory

Redemption: Protocol Handlers and JavaScript Salvation

Source: The Flammarion Engraving

The Problem

Following someone on a different instance involves copy-paste gymnastics, cryptic search boxes, and prayers to the federation spirits. Every extra step cuts user retention in half. Why do we have to do this manually in 2026? The awkward truth is that many long-term Fediverse users have simply gotten used to it, but there are definitely better ways to handle the UX shortcomings.

Our Suggested Fix

Browser protocol handlers (like mailto:) to let users set their home server once. For browsers without support, a lightweight JavaScript fallback.

What’s Happened

This one’s complicated. Again: non-issue on mobile apps, but a problem from day one on web.

As we noted last summer: Native apps like Ivory, Mona, and Ice Cubes sidestep this entirely—great for their users, doesn’t help the open web.

Desktop browser support for protocol handlers has now grown to ~90%. We could ship something that works for most desktop users today, with JavaScript covering the rest. Tim gave some sample code here.  But mobile browsers still don’t support protocol handlers at all—and mobile is now the majority of web traffic.

The FediDev community has debated protocol strings for years. “web+ap! fedi+ap! activity+whatever!” But that debate may be settling: mobile apps are adopting web+ap. Fedilab shipped web+ap support (confirmed April 2026), Holos Discover is implementing it, and Tusky has an open issue to add support. This creates a path where Android users can tap a web+ap: link and have it open directly in their Fediverse app—bypassing the browser entirely.

On a semi-adjacent front: A new tech named “Activity Intents” is starting to gain adoption. It doesn’t solve this UX sin now, but might in the future. For today: think of it as a standardized “follow this account” or “like this post” button that any website can use, like the old Facebook buttons embedded across the web. Tomorrow it might help with this exact Remote Interaction Sin.

Activity Intents are kind of like the Android Intents system, but specifically for individual social interactions on remote sites.

Activity Intents (FEP-3b86) merged into Mastodon in March 2026. Emissary has it. PieFed and Loops support it now too. As does WordPress’s ActivityPub plugin. Watch this space.

Sean also highlighted Hubzilla’s MagicAuth, which is a cookie-based approach that lets you interact with remote servers as if you’re logged in. It’s been around for years but never gained cross-platform adoption. The concept is sound: your browser carries credentials that remote servers can verify, letting you like, follow, and reply without the copy-paste dance. If ActivityPub platforms adopted something similar, this sin could be fully redeemed.

But we saved the most interesting thing here for next: 

Here is a promising idea of a new approach from Mastodon’s CTO that began to be implemented in Mastodon 4.6 and will evolve in future versions: where in the not-distant future, the fediverse server you post on would tag URLs pointing to ActivityPub objects, letting other web apps see that “cheat sheet” note, and automagically letting native fediverse apps open content directly without copy-paste. 

To our view this feels like the ultimate answer to a large portion of – but admittedly not all – of  this problem; but that shouldn’t delay getting the partial fixes out the door while we await that.  We feel the above fixes – Protocol Handlers, Javascript backups, and Object Tagging working in combo have the potential to strip away 90% of the UX pain that users currently face 100% of the time. We don’t need to solve the ‘web architecture’ problem to solve the ‘user frustration’ problem.”

What’s Still Broken

There’s a lot of great ideas, and some early motions in the right direction. Unfortunately, the Web experience largely remains copy-paste purgatory. Users don’t see fantastic underlying infrastructure in place to deal with future problems, they see the friction they’re experiencing here and now.

Final Grade

Grade: D-

The roadmap exists. The browser support exists for desktop. Mobile apps are finally adopting web+ap. But the user-facing Web experience hasn’t improved. We’re not bumping the grade for plumbing users can’t see yet, but hope to by the next report.


Sin 4: DM Disasters Waiting to Happen

Redemption: Direct Messages That Aren’t a Death Trap

“Hey, you accidentally mentioned the guy you’re gossiping about in that private message. He read everything.”

The Problem

Private messages in most Fediverse apps are what can be described as a “foot gun”, that is, something to shoot yourself in the foot with unintentionally. Private messages live in the same composer as public posts. One wrong toggle separates “venting to a friend” from “broadcasting to the Fediverse.” Plus, as of today, no encryption—DMs are plaintext dressed as secrets.

Our Suggested Fix

The main headache here is that direct messaging appears to be a separate, distinct interface designed to mimic email or DMs, but it’s really just a post authoring system pretending to be a messaging pane. There’s also some legitimate UX confusion between what a “Private Message” is supposed to be, as opposed to what a “Private Status” is supposed to be. That’s because they’re the same thing, being used in two different ways.

What we need to do is break direct messages out of the status authoring flow, and give it a different interface with distinct behavioral cues. Confirmation modals explaining when someone not in the recipients field is being mentioned might be a good temporary workaround. Visual indicators that these messages aren’t encrypted are a good idea, too.

Sean’s offers a simpler framing: stop calling them “Private Mentions” and build real DMs, where addressing happens outside the post body.

What’s Happened

This is the redemption success story.

Phanpy shipped nearly everything we asked for: separate composer, dramatically different visual styling, private messages in their own tab. It now has an iOS app (iPhanpy) and remains one of the most thoughtfully designed clients. See the source code. Help it and iterate on it.

Newsmast previews show similar design philosophy. Which will power a whole suite of new open source apps.

The core UI for so much of the rest of the Fediverse? Still hasn’t caught up. (At least so far.) You can still accidentally blast a private thought to the world with one wrong toggle. But at least the path is proven. Phanpy did the homework. Everyone else can copy it.

What’s Still Broken

Many clients use the risky unified composer. UX still often implies direct messages are in some way private although they in every way are not encrypted.

Adjacent Big News: Mastodon announced Sovereign Tech Agency funding for E2EE direct messages. Work begins late 2026, with implementation targeted for Q2 2027. They’ll coordinate with the Social Web Foundation’s E2EE project and implement ActivityPub E2EE extensions once the W3C delivers a specification. Real encrypted DMs are finally on the roadmap. And in a first:  Holos has E2EE using Signal Protocol for Holos-to-Holos DMs.

Final Grade

Grade: B+

Phanpy gets an A. The ecosystem gets a C. Averaging to B+ because the solution exists and is shipping in a number of key places—it just hasn’t propagated everywhere. This is how redemption should work: one app leads, others follow. Now we need the following to happen.


Sin 5: Ghost Conversations and Phantom Followers

Redemption: Filling in the Blanks

The Problem

Federation means you only see what your server has fetched. Replies go missing. Threads arrive with limbs amputated. Follower counts are carnival mirrors—someone shows “800 followers” on their server, you see 12 on yours.

Our Suggested Fix

Auto-fetch surrounding context when users open posts. Show a “fetching…” indicator.

What’s Happened

Ghost Conversations: Done. Shipped. Users benefiting. HOORAY!

Mastodon 4.5 (November 2025) includes automatic reply backfilling: “Users on servers running 4.4 and earlier have likely experienced the confusion of seeing replies appearing on other servers but not their own. Mastodon 4.5 automatically checks for missing replies upon page load and again every 15 minutes, enhancing continuity of conversations across the Fediverse.”

Other platforms have been working on this too—NodeBB reports that backfill from Mastodon instances is “working really well” as more instances upgrade.

Credit where due: the initial Mastodon contribution for this came from Jonny (@jonny@neuromatch.social), a new Ruby coder who pushed through anyway. Then the Mastodon team jumped in to review and further implement.  That’s how open source should work. That is exactly the sort of developer contributions we hope these reports help incite on various fediverse development efforts.

What’s Still Broken

Phantom follower counts remain an unchanged set of carnival mirrors. The new backfill fixes missing conversations, not missing follower graphs. Your server still only knows about followers it has seen, so remote accounts show wildly inaccurate counts. No fix shipped yet.

Special note:  Mastodon’s CTO and Tim had some interesting chats over how this might be fixed in the future. In essence, this strategy for ghost followers proposes that servers should fetch remote profile data on-demand only for the specific followers a user is currently browsing, then automatically purge that data from the local database unless the user explicitly chooses to follow those accounts. This would provide the “missing” visibility of followers, that users crave while avoiding the needless database bloat of storing thousands of accounts that the user never intends to follow.

Final Grade

Grade: A-

This is what redemption looks like for ghost conversations. A real problem, identified. Code written and merged. Feature shipped. Users benefiting. A- instead of A because phantom followers remain broken, this needs to branch out beyond Mastodon, and some edge cases remain.


Sin 6 (Part 1): Search Without Surveillance

Redemption: Discovery That Respects Privacy

“Jephthah’s Daughter Coming to Meet Her Father”, Gustave Dore

The Problem

Search is opt-in, buried in settings. At FediForum 2024, Mastodon CTO Renaud Chaput confirmed only 8-10% of users have opted in—not because they chose privacy, but because they never found the setting. The other 90%+ simply never touched it.

Our Fix

Nudge users to opt in during onboarding and when searching. Surface curated feeds. Let admins set appropriate defaults for their communities.

What’s Happened

Mastodon from version 4.3 onward now allows server admins to choose search as “opt out” or “opt-in” as appropriate to each server’s communities needs – and as always, users can still choose which option they wish, and many servers, like Tim’s own Indieweb.social are choosing to enable it as opt-out. Other servers with different community needs are choosing the defaults they need.

Here’s the big news: Fediscovery is actually available, in an early and evolving form. The Fediscoverer reference implementation exists, specs are published, and Manyfold shipped integration in v0.123.0. FASP support is in Mastodon 4.4 behind a feature flag. This is the first of hopefully many “Fediverse Auxiliary Service Providers” or “FASP’s” that can be plugged into any Mastodon or soon any Fediverse server to add functionality to that server. In the case of “Fediscovery” it adds more powerful search. We have big hopes this will dramatically increase search, for as far as it goes.

We like the work that Holos Discovery is doing, both in terms of powerful search while respecting privacy – and hope they consider turning that into a FASP as well. From Holos Discovery’s site: 

We also suggested upping curated feed accounts into search. We’ll discuss those more in the next section…

What’s Still Broken

No opt-in nudging. Adoption for search indexing is still so low. Other platforms should follow Mastodon’s lead and make indexing opt-in/opt-out choices something that each server can decide for themselves.

Our recommendation: Let non-Mastodon server admins also set the indexable default for new accounts. Not to force users, who should always be able to override for themselves, but to let admins who understand their communities make appropriate choices.

Final Grade

Grade: B

Upgraded because Fediscovery is actually available, not just “in development.” Also that Mastodon made search opt-in a server by server choice.  The infrastructure is real. The FASP momentum is real. But still potential energy, not yet kinetic. More adoption and this can move up to an A.


Sin 6 (Part 2): Content Discovery Mirage

Redemption: Make Great Content Unmissable

“Elijah in the Wilderness”, Gustave Dore

The Problem

Catch-as-catch-can trending topics. No fediverse-wide algorithmic curation (by design). But also no human curation surfaced. Wandering alone in the void, occasionally stumbling across a good post.

Our Suggested Fix

Surface curated feeds prominently. Turn server public streams into followable actors (via privacy-respecting ServerBots and server-based Collections). Index everything in Fediscovery FASPs.

What’s Happened

As with the other Search UX Sin, here we think “Fediscovery” is the real solution.  But it needs to be fed curated lists of amazing feeds and accounts and conversations.

We watch this space with hope that curated lists of feeds pull their way into FASP based search and account recommendation engines, but the devil will be in the details, and hope that enough FASP’s evolve that no one becomes overly centralized.

The raw materials of “feed accounts” exist: Newsmast channels, Flipboard magazines, Surf feeds, Lemmy/PieFed/Mbin communities with upvoted posts. They’re just hard to make, non-standardized, and not integrated into discovery flows. Ironic, all things considered.

News: Tim has actually built a trial proof-of-concept FASP for surfacing “feed accounts” like these, or these, directly into the bloodstream of Mastodon and other fediverse server recommendation systems. If that works out, he’ll open source that for others to carry it forward. If you have Fediscovery running and want to alpha test, reach out.

Friendica has long maintained shared directories for years—servers can opt into bridging their directories, proving cross-instance discovery works. The rest of the fediverse can take some notes from that.

Mobile apps like Ice Cubes and Mona and others do hacks to make following and browsing remote public server feeds work simply, and folks are using that. Our past ServerBot idea (turning each server’s public stream into a followable Fediverse actor) is achievable today using a few kludgy but workable techniques. We haven’t seen anyone do it yet, but it could ship quickly.

Other activity on feeds has occurred since:

  • PieFed has proposed their own FEP for a feed format for federating out PieFed communities. They implemented it, enabling communities or sets of communities to become one account feed. Rimu writes: “Feeds are federated, can be created by anyone and can be public or private. There are now hundreds of feeds at https://piefed.social/feeds. A feed being federated means that people using other instances can subscribe to feeds that were created on your instance, in the same way that people can subscribe/join [Threadiverse] communities on remote instances.”
  • Tags.pub launched: It is a global hashtag server built by the Social Web Foundation. As this blog post describes: “The idea is simple: tags.pub collects publicly posted content from across the Fediverse and redistributes it based on hashtags. When you follow a hashtag account like @photography, you’ll see posts tagged from servers your instance might never have heard of. It fills in the gaps that decentralization naturally creates.” Evan has proposed a FASP to turbocharge this even more, and function, which is a bit like a very focused relay. Which is the point of FASP’s in essence. Yes. More.Please.
  • Bluesky has shown the power of AT Proto-based Feeds as a central innovation on their platform. Even in a closed beta, Surf Social is thriving with massive numbers of great highly curated feeds being created, consumed, and shared.
  • The W3C Social CG working group has been convened to standardize exactly this. In part of that group’s kick-off they said: “We’ve seen a number of new features and services launching recently, having to do with aggregating and remixing feeds. Surf, Channel.org from Newsmast. There’s interest in illustrating/declaring the ‘recipe’ of what went into the feed (accounts, hashtags, algorithm) so that it can be reused, forked, and so on.” But it has been quiet for a bit. That work cannot happen fast enough.

This is proven, non-theoretical, and users are ready. LFG.

Final Grade

Grade: C

The ingredients are in the pantry, but in classic open source fashion, we have yet to bake a cake with them. This is more of a coordination and prioritization problem, and less of a technical one.


Sin 7: User Discovery Hell

Redemption: Starter Kits, I mean, “Collections,”  to the Rescue

The Problem

Server directories on Mastodon servers are still simply flat walls of relatively unsorted profiles. Following lists from friends are invisible due to federation fragmentation. No “you might like.” Just vibes and dusty wikis from 2022.

Our Suggested Fix

Better directories. Federated Starter Packs with privacy controls so you can opt out of packs you don’t want.

What’s Happened

Server directories like this one at Tim’s indieweb.scocial remain mostly useless in Mastodon. Sortable by “recently active” and… that’s about it.

Starter Packs are shipping from multiple directions.

Loops Starter Kits are now live with opt-in consent—every featured account must agree to be there.

Mastodon Collections are rolling out within the next few weeks, already testable on mastodon.social. Key design choices reflecting lessons from Bluesky:

  • Smaller by design: 25 accounts max (vs Bluesky’s 150) to reduce spammy behavior
  • No “Follow All” button at launch: Avoids subpar feeds from mass-following stale packs
  • Real consent controls: Users can remove themselves without blocking the creator—something Bluesky still doesn’t offer
  • Notification on inclusion: You know when someone adds you

More good news: this is becoming a defacto standard: Loops has said it will be compatible with Mastodon Collections. Fedidevs has had starter kits of their own around for a while, and has since committed to adapt it to be compatible with Collections too. You love to see it.

We’d suggest that mastodon servers build Collections support into the admin, where admins can expose top users to the rest of the community as a “starter kit.” Here is one proof of concept startker kit  for the Forkiverse server using the Fedidev’s version of starter kits. Here is one for Tim’s server, indieweb.social.

What’s Still Broken

Server directories remain terrible. Other fediverse plaforms evolving this and adopting things like integrating Fediscovery Account recommendations are crucial there.

Two things to watch

Global hashtag discovery is getting real infrastructure.

Services like tags.pub, relay.fedi.buzz, andtagpush.app already provide followable ActivityPub actors for each hashtag—collecting public content in realtime. There’s now a proposal to add a FASP interface so servers can transparently enhance the existing “subscribe to hashtag” feature with global data streams. Currently, hashtag feeds only show content from accounts someone on your server follows. A global hashtag FASP would fill in the gaps automatically, but would also need to enable server admins to manage in ways that don’t swamp them or spike costs.

And the bigger structural issue: there’s no agreed ActivityPub standard for feed accounts. The W3C SWICG Remixing and Aggregation Task Force is working on related issues, and FEP-1d80 proposes a “Feed Actor” concept (emerging from PieFed’s work), but both are early. Flipboard’s magazines, Loops’ For You, Newsmast’s channels, Bluesky’s custom feeds—they all exist in isolation because nobody’s agreed on how feeds should federate. Without a standard, cross-platform feed discovery is impossible. If you care about discovery, get involved in the standards work.

Final Grade

Grade: B-

Upgraded because Collections are actually rolling out—not “coming soon,” but live on mastodon.social and shipping next week. Loops Starter Kits in production. The cold-start problem is getting real solutions with thoughtful consent controls.


Reflections

Looking over everything together, we can come up with a final report card based on what we’ve observed. This is not intended to overtly praise or condemn the Fediverse, but to realistically highlight where things are today.

The Final Report Card

SinProblemGradeStatus
1. Instance SelectionOnboarding chaosB-Mastodon, PieFed, Loops, Holos lead
2. Timeline TurmoilThree-feed confusionB+Mastodon buried feeds; Loops has good framing
3. Remote InteractionCopy-paste purgatoryD-Infrastructure work, no user-facing fix
4. DM DisastersPrivacy time bombsB+Phanpy and Newsmast and others shipped it
5. Ghost ConversationsMissing repliesA-Shipped in Mastodon 4.5! (Phantom followers still broken)
6 (Part 1). SearchOpt-in buriedB+Fediscovery available; admins can set opt-in for their servers on Mastodon, not yet on other platforms.
6 (Part 2). Content DiscoveryWandering the voidCIngredients exist, Fedisvoery potential, no integration, no standard feed format yet.
7. User DiscoveryFinding people is hellB-Collections  and compatible efforts rolling out on Mastodon, Loops, Fedidevs

Overall GPA: 2.5 (C+)

The Professors’ Notes

Good news: We have our first A grade. Ghost Conversations—that infuriating problem where you couldn’t see replies that existed elsewhere—is fixed in Mastodon 4.5. Shipped. Working. Users benefiting.

Mastodon’s pace has accelerated. 4.4 brought FASP infrastructure and streamlined onboarding. 4.5 shipped quote posts with consent controls and reply backfilling. 4.6 is imminent with Collections and profile redesigns. Activity Intents just landed. Fediscovery is actually available to test. 

Frustrating news: We’re still not doing some of the partial fixes that we could, and while none of these are “easy” or they would have been done literally years ago, we hope some of these suggestions in these reports focuses attention and donation and development where it matters.

Remote Interaction (Sin 3) remains the most embarrassing. Activity Intents is infrastructure—users don’t see infrastructure, they see copy-paste boxes. Protocol handlers remain unshipped despite years of documentation. Someone just needs to deploy them.

What moved grades:

  • Sin 2: B- → B+ (Loops framing, mobile apps de-emphasizing feeds)
  • Sin 5: B → A- (Ghost conversations fixed in 4.5!)
  • Sin 6 (Part 1): C → B (Fediscovery available, Search opt-in settable by admins on Mastodon)
  • Sin 7: C- → B- (Collections rolling out, Loops Starter Kits shipped)

Extra Credit – What You Can Do to Help

  1. Other Platform Developers: Copy elements of  PieFed’s instance chooser. Sorting by ping, not size, actively decentralizes. Mastodon, Pixelfed, Lemmy—your turn.
  2. Mobile App Developers: Deploy protocol handlers. Be the first domino. Prove it works. Blog about it. This sin has been stuck at D too long. Get into the weeds here on how it can be done TODAY.
  3. Programmers and Fediverse Developers: Integrate curated feeds into onboarding. Feature Newsmast and Flipboard in suggested follows. Make great content findable from day one.
  4. Server Admins and Developers: Support FASP’s for Discovery Search and more.
  5. Help standardize federated feeds. Get involved with W3C SWICG and FEP-1d80. The Fediverse desperately needs agreement on how feeds should work.
  6. Mastodon server admins: Upgrade to Mastodon 4.5. Reply backfilling alone makes it worth it. Your users will thank you.

In Conclusion

The Fediverse has what Big Tech can’t buy: passion, values, and a community that gives a damn. Now we have proof that caring can turn into shipping.

  • Ghost Conversations—fixed.
  • Starter Kits—shipping.
  • Discovery infrastructure—building.
  • Quote posts—done right, with consent controls.

The Mastodon team is moving faster than they have in years. Loops proves a single developer with good taste can ship features the whole ecosystem should copy. PieFed shows smart defaults can actively decentralize.

The Open Social Web won’t win on ideology alone. It’ll win when a normie can join, find friends, discover content, and interact seamlessly—without understanding federation theory.

We’re closer than we were. These grades reflect that honestly.

Redemption is within reach. Some has already arrived.

Who’s bumping their grade next?


Follow-up to Tim’s Part 1and Part 2, and Sean’s solutions.

Tim Chambers (@tchambers@indieweb.social) runs Indieweb.social. Sean Tilley (@deadsuperhero@wedistribute.org) edits We Distribute.

 Share
We Distribute's avatar
We Distribute

@news@wedistribute.org

Six months after an initial analysis, two Fediverse experts come back to examine where user experience has changed. Are we on the path of redemption, or repeating the same old sins?

Last summer, Tim delivered a two-part online sermon on the Seven Deadly UX Sins plaguing the Fediverse: first the diagnosis, then the path to redemption. Sean wrote his own set of solutions. It was the kind of tough love we felt the Open Social Web desperately needed: unflinching about problems, genuinely hopeful about fixes.

It kicked off a lot of great and constructive discussions.

But redemption requires actual work. Good words alone aren’t enough.

So we decided to play professor every 6 months or so, and grade these redemption efforts; not on vibes, not on good intentions, but on what’s actually shipped since then. And what is about to. The goal is not to be a wagging finger, but to applaud and focus attention on good work. And maybe incite donations and volunteering to move other things faster.

Between Tim’s years running Indieweb.social and Sean’s decade-plus chronicling the distributed web at We Distribute, we’ve watched these problems persist longer than we’d like to admit.

The grading scale:

  • A: Shipped and working. Users benefiting right now.
  • B: Solid progress. Real commits, real momentum, shipping soon.
  • C: Good ideas on paper. Some movement, waiting on execution.
  • D: Acknowledged problem. Minimal progress.
  • F: Crickets. Or actively getting worse.

If we missed anything, reach out and we’ll update this. Let’s dig in.


The List of Sins

As with our previous analysis efforts, we’ve split everything up into sections to make it easier to read, navigate, and parse. These are long-standing issues both Tim and Sean have seen in the Fediverse, with reflections on how things may or may not have changed in the past six months.

Sin 1: Instance Selection Paralysis

Redemption: One Single Social Home to Join, Many Doors Later

The Problem

New users arrive ready to escape Big Tech, and we immediately hit them with 8,000 servers named like medieval taverns crossed with startup pitches. Half bail before creating an account. Why does this happen? Our best reasoning suggests that initially joining an instance feels like a big commitment, and people often have to do this while knowing very little about the community they’re getting into.

Our Suggested Fix

The problem is akin to walking into a restaurant with a really, really big menu. You may have had some idea of what you initially wanted, but as you thumb through the different choices, you start to realize you actually are less certain about what to get. Choice is good, but this is overwhelming.

Here’s the thing: keep the offering of choices simple for people just starting out, and offer a single no-brainer choice to get the ball rolling. If centralization is a concern, it’s possible to offer a curated round-robin of trustworthy servers, preventing any individual instance from being overloaded. While everybody wants some level of choice, they also want a reduction in friction. This is one way to do both.

What’s Happened Recently

Mastodon’s mobile apps have long defaulted to mastodon.social with an optional “choose another server” toggle—exactly where it should be. As they stated in their February 2026 blog post: “As people fled from traditional social media in late 2022, we made a strategic decision to send new sign-ups directly to mastodon.social. This choice was driven by our desire to reduce cognitive load for new users and ensure a stable onboarding experience.” That was the right instinct.

New fediverse apps focused on individual communities like the Toot Wales app, completely streamline this purely into their server. This is part of Newsmast’s overall strategy of empowering news and other local communities, and creating dedicated apps and servers specific for each, with specific onboarding for each community.

Image courtesy of Newsmast Foundation

But recently, the Mastodon team has also recognized the problem and added this: “Right now, too many newcomers default to the largest servers. We want to change that—because Mastodon is best when communities are spread across many independent servers.” They’re actively working on a new mobile flow that points users to other servers. That is very close to our round-robin suggestion. Maybe better, as it does some performance checks for best servers near you.

On web: Mastodon 4.4 shrunk web onboarding from four steps to two—real progress, even if incomplete.

Other platforms are also leading:

  • PieFed shipped an instance chooser very close to our suggestion. It includes a big simple way to join the flagship but also with a “help me choose” button for those who want to go deeper. And like Mastodon: a sophisticated instance chooser that sorts by lots of easy-to-grasp criteria for those who want to dig into it.
  • Loops sends users directly to their main server via JoinLoops.org. Simple, direct. (No round-robin, but we applaud the simplicity as a first start.)
  • Holos takes a radical approach: running a complete ActivityPub server on your phone (from the developer of Fedilab). No server choice because your phone IS your server. The relay provides a stable identity, but onboarding is zero-friction because the concept simply doesn’t exist. See how it works and the FAQ. It’s early-days, but fascinating proof that “pick a server” can be eliminated entirely.

What’s Still Broken

Web onboarding across most of the Fediverse: PixelFed, PeerTube, Misskey, etc., all still ask users to solve a puzzle before joining. At the very least, JoinMastodon.org has improved to a “two choices” flow, but we look forward to seeing this exact same mobile UX being applied to Web. It’s in the works.

For most platforms, it’s more hazing ritual than clean onboarding. And other than the planned effort underway at Mastodon (which at first will be mobile only), none of the others have tried the more simple round-robin idea yet. There no doubt would be some complexity in setting this up, but It’s just waiting there for folks to try.

Sean proposed something more ambitious: identity-first onboarding, where you import your social graph and content before choosing a server. The idea: set up a “pre-identity” that pulls in your posts and connections from other networks, then pick a server that fits. Tools like Bounce from A New Social are experimenting in this direction. It’s still aspirational, but points toward a future where “pick a server” isn’t the first question new users face.

Final Grade

Grade: B-

Mastodon, PieFed, Loops, and Holos earn serious credit for shipping (or about to ship) big parts of what we suggested. PieFed’s instance chooser is particularly noteworthy, but could be integrated on. Now the rest need to follow.


Sin 2: Timeline Turmoil

Redemption: One Feed To Rule Them All (at First)

“Relativity” by MC Escher

The Problem

Mastodon and a lot of other Fediverse platforms offer three different timelines for representing social activities: Home, Local, and Federated. Each more metaphysically confusing than the last. “Home” at least makes sense, because it’s everyone you’re following. “Local” sounds cozy, but is actually your server’s collective brain dump. “Federated” is the cosmic firehose of everything, everywhere, in languages you don’t speak.

Kind of like what happened after the Tower of Babel

What people want is to be able to easily cut through all the noise and connect with people on the subjects that they care about the most. It’s not so much that we want a bunch of different timelines, but a way to dig into one timeline in a bunch of different ways.

Our Suggested Fix

Cut the interface down to one feed, with some tools to bring desired behavior to the forefront. Use progressive disclosure to introduce others as “power-ups,” not puzzles. “Want to see what’s trending nearby?” “Curious about the wider Fediverse?” Let them level up like a video game character.

What’s Happened

Mastodon web has since hidden the extra feeds by default, to their credit. They also did this in Mastodon 4.5:

Feed Toggles: Admins can now selectively disable specific content feeds (like the Federated Timeline or Trending) for both logged-in users and unauthenticated visitors. Good: enables admins to choose simplicity.

Loops launched something especially interesting: They present both a “Following” feed (chronological, people you trust) and a “For You” feed (algorithmic discovery). The key distinction from TikTok: “For You” is powered by engagement and social graph signals, not ads or dark patterns. As they put it: “A calm chronological Following feed for the people you trust—and a For You feed that surfaces new creators. No dark-pattern growth hacks.”

(Minor nitpick: we’d suggest they move “Local” feed back under “Explore” and make it only “Following” and “For You.” But we digress.)

What’s Still Broken

No platform implements the true progressive disclosure idea yet. Multi-timeline confusion remains the default on PeerTube, Misskey, and others.

As Sean put it: “We don’t need more timelines, we need better ones.” Projects like FediAlgo and Channel.org are experimenting with custom feeds and algorithmic filtering, following Bluesky’s lead. The goal isn’t to replicate TikTok’s dopamine machine, but to give users powerful ways to sort and filter their Home timeline without needing to understand federation theory. Sean has been following the ActivityPub Client to Server API developments, with a few clients beginning to experiment with that – notably Ghost and WordPress Reader apps –  and we think there may be room for innovating on unified feed UX there.

Final Grade

Grade: B+

Kudos to Mastodon for giving each admin the ability to choose to bury the feeds that never made sense to each individual server community. Loops gets credit for the right framing. Closest to fully solved. The biggest thing now is to focus on intuitive ways that users can filter and curate their own timeline experiences. When more critical mass of platforms actually hide extra timelines until users ask, we’re looking at an A.


Sin 3: Remote Interaction Purgatory

Redemption: Protocol Handlers and JavaScript Salvation

Source: The Flammarion Engraving

The Problem

Following someone on a different instance involves copy-paste gymnastics, cryptic search boxes, and prayers to the federation spirits. Every extra step cuts user retention in half. Why do we have to do this manually in 2026? The awkward truth is that many long-term Fediverse users have simply gotten used to it, but there are definitely better ways to handle the UX shortcomings.

Our Suggested Fix

Browser protocol handlers (like mailto:) to let users set their home server once. For browsers without support, a lightweight JavaScript fallback.

What’s Happened

This one’s complicated. Again: non-issue on mobile apps, but a problem from day one on web.

As we noted last summer: Native apps like Ivory, Mona, and Ice Cubes sidestep this entirely—great for their users, doesn’t help the open web.

Desktop browser support for protocol handlers has now grown to ~90%. We could ship something that works for most desktop users today, with JavaScript covering the rest. Tim gave some sample code here.  But mobile browsers still don’t support protocol handlers at all—and mobile is now the majority of web traffic.

The FediDev community has debated protocol strings for years. “web+ap! fedi+ap! activity+whatever!” But that debate may be settling: mobile apps are adopting web+ap. Fedilab shipped web+ap support (confirmed April 2026), Holos Discover is implementing it, and Tusky has an open issue to add support. This creates a path where Android users can tap a web+ap: link and have it open directly in their Fediverse app—bypassing the browser entirely.

On a semi-adjacent front: A new tech named “Activity Intents” is starting to gain adoption. It doesn’t solve this UX sin now, but might in the future. For today: think of it as a standardized “follow this account” or “like this post” button that any website can use, like the old Facebook buttons embedded across the web. Tomorrow it might help with this exact Remote Interaction Sin.

Activity Intents are kind of like the Android Intents system, but specifically for individual social interactions on remote sites.

Activity Intents (FEP-3b86) merged into Mastodon in March 2026. Emissary has it. PieFed and Loops support it now too. As does WordPress’s ActivityPub plugin. Watch this space.

Sean also highlighted Hubzilla’s MagicAuth, which is a cookie-based approach that lets you interact with remote servers as if you’re logged in. It’s been around for years but never gained cross-platform adoption. The concept is sound: your browser carries credentials that remote servers can verify, letting you like, follow, and reply without the copy-paste dance. If ActivityPub platforms adopted something similar, this sin could be fully redeemed.

But we saved the most interesting thing here for next: 

Here is a promising idea of a new approach from Mastodon’s CTO that began to be implemented in Mastodon 4.6 and will evolve in future versions: where in the not-distant future, the fediverse server you post on would tag URLs pointing to ActivityPub objects, letting other web apps see that “cheat sheet” note, and automagically letting native fediverse apps open content directly without copy-paste. 

To our view this feels like the ultimate answer to a large portion of – but admittedly not all – of  this problem; but that shouldn’t delay getting the partial fixes out the door while we await that.  We feel the above fixes – Protocol Handlers, Javascript backups, and Object Tagging working in combo have the potential to strip away 90% of the UX pain that users currently face 100% of the time. We don’t need to solve the ‘web architecture’ problem to solve the ‘user frustration’ problem.”

What’s Still Broken

There’s a lot of great ideas, and some early motions in the right direction. Unfortunately, the Web experience largely remains copy-paste purgatory. Users don’t see fantastic underlying infrastructure in place to deal with future problems, they see the friction they’re experiencing here and now.

Final Grade

Grade: D-

The roadmap exists. The browser support exists for desktop. Mobile apps are finally adopting web+ap. But the user-facing Web experience hasn’t improved. We’re not bumping the grade for plumbing users can’t see yet, but hope to by the next report.


Sin 4: DM Disasters Waiting to Happen

Redemption: Direct Messages That Aren’t a Death Trap

“Hey, you accidentally mentioned the guy you’re gossiping about in that private message. He read everything.”

The Problem

Private messages in most Fediverse apps are what can be described as a “foot gun”, that is, something to shoot yourself in the foot with unintentionally. Private messages live in the same composer as public posts. One wrong toggle separates “venting to a friend” from “broadcasting to the Fediverse.” Plus, as of today, no encryption—DMs are plaintext dressed as secrets.

Our Suggested Fix

The main headache here is that direct messaging appears to be a separate, distinct interface designed to mimic email or DMs, but it’s really just a post authoring system pretending to be a messaging pane. There’s also some legitimate UX confusion between what a “Private Message” is supposed to be, as opposed to what a “Private Status” is supposed to be. That’s because they’re the same thing, being used in two different ways.

What we need to do is break direct messages out of the status authoring flow, and give it a different interface with distinct behavioral cues. Confirmation modals explaining when someone not in the recipients field is being mentioned might be a good temporary workaround. Visual indicators that these messages aren’t encrypted are a good idea, too.

Sean’s offers a simpler framing: stop calling them “Private Mentions” and build real DMs, where addressing happens outside the post body.

What’s Happened

This is the redemption success story.

Phanpy shipped nearly everything we asked for: separate composer, dramatically different visual styling, private messages in their own tab. It now has an iOS app (iPhanpy) and remains one of the most thoughtfully designed clients. See the source code. Help it and iterate on it.

Newsmast previews show similar design philosophy. Which will power a whole suite of new open source apps.

The core UI for so much of the rest of the Fediverse? Still hasn’t caught up. (At least so far.) You can still accidentally blast a private thought to the world with one wrong toggle. But at least the path is proven. Phanpy did the homework. Everyone else can copy it.

What’s Still Broken

Many clients use the risky unified composer. UX still often implies direct messages are in some way private although they in every way are not encrypted.

Adjacent Big News: Mastodon announced Sovereign Tech Agency funding for E2EE direct messages. Work begins late 2026, with implementation targeted for Q2 2027. They’ll coordinate with the Social Web Foundation’s E2EE project and implement ActivityPub E2EE extensions once the W3C delivers a specification. Real encrypted DMs are finally on the roadmap. And in a first:  Holos has E2EE using Signal Protocol for Holos-to-Holos DMs.

Final Grade

Grade: B+

Phanpy gets an A. The ecosystem gets a C. Averaging to B+ because the solution exists and is shipping in a number of key places—it just hasn’t propagated everywhere. This is how redemption should work: one app leads, others follow. Now we need the following to happen.


Sin 5: Ghost Conversations and Phantom Followers

Redemption: Filling in the Blanks

The Problem

Federation means you only see what your server has fetched. Replies go missing. Threads arrive with limbs amputated. Follower counts are carnival mirrors—someone shows “800 followers” on their server, you see 12 on yours.

Our Suggested Fix

Auto-fetch surrounding context when users open posts. Show a “fetching…” indicator.

What’s Happened

Ghost Conversations: Done. Shipped. Users benefiting. HOORAY!

Mastodon 4.5 (November 2025) includes automatic reply backfilling: “Users on servers running 4.4 and earlier have likely experienced the confusion of seeing replies appearing on other servers but not their own. Mastodon 4.5 automatically checks for missing replies upon page load and again every 15 minutes, enhancing continuity of conversations across the Fediverse.”

Other platforms have been working on this too—NodeBB reports that backfill from Mastodon instances is “working really well” as more instances upgrade.

Credit where due: the initial Mastodon contribution for this came from Jonny (@jonny@neuromatch.social), a new Ruby coder who pushed through anyway. Then the Mastodon team jumped in to review and further implement.  That’s how open source should work. That is exactly the sort of developer contributions we hope these reports help incite on various fediverse development efforts.

What’s Still Broken

Phantom follower counts remain an unchanged set of carnival mirrors. The new backfill fixes missing conversations, not missing follower graphs. Your server still only knows about followers it has seen, so remote accounts show wildly inaccurate counts. No fix shipped yet.

Special note:  Mastodon’s CTO and Tim had some interesting chats over how this might be fixed in the future. In essence, this strategy for ghost followers proposes that servers should fetch remote profile data on-demand only for the specific followers a user is currently browsing, then automatically purge that data from the local database unless the user explicitly chooses to follow those accounts. This would provide the “missing” visibility of followers, that users crave while avoiding the needless database bloat of storing thousands of accounts that the user never intends to follow.

Final Grade

Grade: A-

This is what redemption looks like for ghost conversations. A real problem, identified. Code written and merged. Feature shipped. Users benefiting. A- instead of A because phantom followers remain broken, this needs to branch out beyond Mastodon, and some edge cases remain.


Sin 6 (Part 1): Search Without Surveillance

Redemption: Discovery That Respects Privacy

“Jephthah’s Daughter Coming to Meet Her Father”, Gustave Dore

The Problem

Search is opt-in, buried in settings. At FediForum 2024, Mastodon CTO Renaud Chaput confirmed only 8-10% of users have opted in—not because they chose privacy, but because they never found the setting. The other 90%+ simply never touched it.

Our Fix

Nudge users to opt in during onboarding and when searching. Surface curated feeds. Let admins set appropriate defaults for their communities.

What’s Happened

Mastodon from version 4.3 onward now allows server admins to choose search as “opt out” or “opt-in” as appropriate to each server’s communities needs – and as always, users can still choose which option they wish, and many servers, like Tim’s own Indieweb.social are choosing to enable it as opt-out. Other servers with different community needs are choosing the defaults they need.

Here’s the big news: Fediscovery is actually available, in an early and evolving form. The Fediscoverer reference implementation exists, specs are published, and Manyfold shipped integration in v0.123.0. FASP support is in Mastodon 4.4 behind a feature flag. This is the first of hopefully many “Fediverse Auxiliary Service Providers” or “FASP’s” that can be plugged into any Mastodon or soon any Fediverse server to add functionality to that server. In the case of “Fediscovery” it adds more powerful search. We have big hopes this will dramatically increase search, for as far as it goes.

We like the work that Holos Discovery is doing, both in terms of powerful search while respecting privacy – and hope they consider turning that into a FASP as well. From Holos Discovery’s site: 

We also suggested upping curated feed accounts into search. We’ll discuss those more in the next section…

What’s Still Broken

No opt-in nudging. Adoption for search indexing is still so low. Other platforms should follow Mastodon’s lead and make indexing opt-in/opt-out choices something that each server can decide for themselves.

Our recommendation: Let non-Mastodon server admins also set the indexable default for new accounts. Not to force users, who should always be able to override for themselves, but to let admins who understand their communities make appropriate choices.

Final Grade

Grade: B

Upgraded because Fediscovery is actually available, not just “in development.” Also that Mastodon made search opt-in a server by server choice.  The infrastructure is real. The FASP momentum is real. But still potential energy, not yet kinetic. More adoption and this can move up to an A.


Sin 6 (Part 2): Content Discovery Mirage

Redemption: Make Great Content Unmissable

“Elijah in the Wilderness”, Gustave Dore

The Problem

Catch-as-catch-can trending topics. No fediverse-wide algorithmic curation (by design). But also no human curation surfaced. Wandering alone in the void, occasionally stumbling across a good post.

Our Suggested Fix

Surface curated feeds prominently. Turn server public streams into followable actors (via privacy-respecting ServerBots and server-based Collections). Index everything in Fediscovery FASPs.

What’s Happened

As with the other Search UX Sin, here we think “Fediscovery” is the real solution.  But it needs to be fed curated lists of amazing feeds and accounts and conversations.

We watch this space with hope that curated lists of feeds pull their way into FASP based search and account recommendation engines, but the devil will be in the details, and hope that enough FASP’s evolve that no one becomes overly centralized.

The raw materials of “feed accounts” exist: Newsmast channels, Flipboard magazines, Surf feeds, Lemmy/PieFed/Mbin communities with upvoted posts. They’re just hard to make, non-standardized, and not integrated into discovery flows. Ironic, all things considered.

News: Tim has actually built a trial proof-of-concept FASP for surfacing “feed accounts” like these, or these, directly into the bloodstream of Mastodon and other fediverse server recommendation systems. If that works out, he’ll open source that for others to carry it forward. If you have Fediscovery running and want to alpha test, reach out.

Friendica has long maintained shared directories for years—servers can opt into bridging their directories, proving cross-instance discovery works. The rest of the fediverse can take some notes from that.

Mobile apps like Ice Cubes and Mona and others do hacks to make following and browsing remote public server feeds work simply, and folks are using that. Our past ServerBot idea (turning each server’s public stream into a followable Fediverse actor) is achievable today using a few kludgy but workable techniques. We haven’t seen anyone do it yet, but it could ship quickly.

Other activity on feeds has occurred since:

  • PieFed has proposed their own FEP for a feed format for federating out PieFed communities. They implemented it, enabling communities or sets of communities to become one account feed. Rimu writes: “Feeds are federated, can be created by anyone and can be public or private. There are now hundreds of feeds at https://piefed.social/feeds. A feed being federated means that people using other instances can subscribe to feeds that were created on your instance, in the same way that people can subscribe/join [Threadiverse] communities on remote instances.”
  • Tags.pub launched: It is a global hashtag server built by the Social Web Foundation. As this blog post describes: “The idea is simple: tags.pub collects publicly posted content from across the Fediverse and redistributes it based on hashtags. When you follow a hashtag account like @photography, you’ll see posts tagged from servers your instance might never have heard of. It fills in the gaps that decentralization naturally creates.” Evan has proposed a FASP to turbocharge this even more, and function, which is a bit like a very focused relay. Which is the point of FASP’s in essence. Yes. More.Please.
  • Bluesky has shown the power of AT Proto-based Feeds as a central innovation on their platform. Even in a closed beta, Surf Social is thriving with massive numbers of great highly curated feeds being created, consumed, and shared.
  • The W3C Social CG working group has been convened to standardize exactly this. In part of that group’s kick-off they said: “We’ve seen a number of new features and services launching recently, having to do with aggregating and remixing feeds. Surf, Channel.org from Newsmast. There’s interest in illustrating/declaring the ‘recipe’ of what went into the feed (accounts, hashtags, algorithm) so that it can be reused, forked, and so on.” But it has been quiet for a bit. That work cannot happen fast enough.

This is proven, non-theoretical, and users are ready. LFG.

Final Grade

Grade: C

The ingredients are in the pantry, but in classic open source fashion, we have yet to bake a cake with them. This is more of a coordination and prioritization problem, and less of a technical one.


Sin 7: User Discovery Hell

Redemption: Starter Kits, I mean, “Collections,”  to the Rescue

The Problem

Server directories on Mastodon servers are still simply flat walls of relatively unsorted profiles. Following lists from friends are invisible due to federation fragmentation. No “you might like.” Just vibes and dusty wikis from 2022.

Our Suggested Fix

Better directories. Federated Starter Packs with privacy controls so you can opt out of packs you don’t want.

What’s Happened

Server directories like this one at Tim’s indieweb.scocial remain mostly useless in Mastodon. Sortable by “recently active” and… that’s about it.

Starter Packs are shipping from multiple directions.

Loops Starter Kits are now live with opt-in consent—every featured account must agree to be there.

Mastodon Collections are rolling out within the next few weeks, already testable on mastodon.social. Key design choices reflecting lessons from Bluesky:

  • Smaller by design: 25 accounts max (vs Bluesky’s 150) to reduce spammy behavior
  • No “Follow All” button at launch: Avoids subpar feeds from mass-following stale packs
  • Real consent controls: Users can remove themselves without blocking the creator—something Bluesky still doesn’t offer
  • Notification on inclusion: You know when someone adds you

More good news: this is becoming a defacto standard: Loops has said it will be compatible with Mastodon Collections. Fedidevs has had starter kits of their own around for a while, and has since committed to adapt it to be compatible with Collections too. You love to see it.

We’d suggest that mastodon servers build Collections support into the admin, where admins can expose top users to the rest of the community as a “starter kit.” Here is one proof of concept startker kit  for the Forkiverse server using the Fedidev’s version of starter kits. Here is one for Tim’s server, indieweb.social.

What’s Still Broken

Server directories remain terrible. Other fediverse plaforms evolving this and adopting things like integrating Fediscovery Account recommendations are crucial there.

Two things to watch

Global hashtag discovery is getting real infrastructure.

Services like tags.pub, relay.fedi.buzz, andtagpush.app already provide followable ActivityPub actors for each hashtag—collecting public content in realtime. There’s now a proposal to add a FASP interface so servers can transparently enhance the existing “subscribe to hashtag” feature with global data streams. Currently, hashtag feeds only show content from accounts someone on your server follows. A global hashtag FASP would fill in the gaps automatically, but would also need to enable server admins to manage in ways that don’t swamp them or spike costs.

And the bigger structural issue: there’s no agreed ActivityPub standard for feed accounts. The W3C SWICG Remixing and Aggregation Task Force is working on related issues, and FEP-1d80 proposes a “Feed Actor” concept (emerging from PieFed’s work), but both are early. Flipboard’s magazines, Loops’ For You, Newsmast’s channels, Bluesky’s custom feeds—they all exist in isolation because nobody’s agreed on how feeds should federate. Without a standard, cross-platform feed discovery is impossible. If you care about discovery, get involved in the standards work.

Final Grade

Grade: B-

Upgraded because Collections are actually rolling out—not “coming soon,” but live on mastodon.social and shipping next week. Loops Starter Kits in production. The cold-start problem is getting real solutions with thoughtful consent controls.


Reflections

Looking over everything together, we can come up with a final report card based on what we’ve observed. This is not intended to overtly praise or condemn the Fediverse, but to realistically highlight where things are today.

The Final Report Card

SinProblemGradeStatus
1. Instance SelectionOnboarding chaosB-Mastodon, PieFed, Loops, Holos lead
2. Timeline TurmoilThree-feed confusionB+Mastodon buried feeds; Loops has good framing
3. Remote InteractionCopy-paste purgatoryD-Infrastructure work, no user-facing fix
4. DM DisastersPrivacy time bombsB+Phanpy and Newsmast and others shipped it
5. Ghost ConversationsMissing repliesA-Shipped in Mastodon 4.5! (Phantom followers still broken)
6 (Part 1). SearchOpt-in buriedB+Fediscovery available; admins can set opt-in for their servers on Mastodon, not yet on other platforms.
6 (Part 2). Content DiscoveryWandering the voidCIngredients exist, Fedisvoery potential, no integration, no standard feed format yet.
7. User DiscoveryFinding people is hellB-Collections  and compatible efforts rolling out on Mastodon, Loops, Fedidevs

Overall GPA: 2.5 (C+)

The Professors’ Notes

Good news: We have our first A grade. Ghost Conversations—that infuriating problem where you couldn’t see replies that existed elsewhere—is fixed in Mastodon 4.5. Shipped. Working. Users benefiting.

Mastodon’s pace has accelerated. 4.4 brought FASP infrastructure and streamlined onboarding. 4.5 shipped quote posts with consent controls and reply backfilling. 4.6 is imminent with Collections and profile redesigns. Activity Intents just landed. Fediscovery is actually available to test. 

Frustrating news: We’re still not doing some of the partial fixes that we could, and while none of these are “easy” or they would have been done literally years ago, we hope some of these suggestions in these reports focuses attention and donation and development where it matters.

Remote Interaction (Sin 3) remains the most embarrassing. Activity Intents is infrastructure—users don’t see infrastructure, they see copy-paste boxes. Protocol handlers remain unshipped despite years of documentation. Someone just needs to deploy them.

What moved grades:

  • Sin 2: B- → B+ (Loops framing, mobile apps de-emphasizing feeds)
  • Sin 5: B → A- (Ghost conversations fixed in 4.5!)
  • Sin 6 (Part 1): C → B (Fediscovery available, Search opt-in settable by admins on Mastodon)
  • Sin 7: C- → B- (Collections rolling out, Loops Starter Kits shipped)

Extra Credit – What You Can Do to Help

  1. Other Platform Developers: Copy elements of  PieFed’s instance chooser. Sorting by ping, not size, actively decentralizes. Mastodon, Pixelfed, Lemmy—your turn.
  2. Mobile App Developers: Deploy protocol handlers. Be the first domino. Prove it works. Blog about it. This sin has been stuck at D too long. Get into the weeds here on how it can be done TODAY.
  3. Programmers and Fediverse Developers: Integrate curated feeds into onboarding. Feature Newsmast and Flipboard in suggested follows. Make great content findable from day one.
  4. Server Admins and Developers: Support FASP’s for Discovery Search and more.
  5. Help standardize federated feeds. Get involved with W3C SWICG and FEP-1d80. The Fediverse desperately needs agreement on how feeds should work.
  6. Mastodon server admins: Upgrade to Mastodon 4.5. Reply backfilling alone makes it worth it. Your users will thank you.

In Conclusion

The Fediverse has what Big Tech can’t buy: passion, values, and a community that gives a damn. Now we have proof that caring can turn into shipping.

  • Ghost Conversations—fixed.
  • Starter Kits—shipping.
  • Discovery infrastructure—building.
  • Quote posts—done right, with consent controls.

The Mastodon team is moving faster than they have in years. Loops proves a single developer with good taste can ship features the whole ecosystem should copy. PieFed shows smart defaults can actively decentralize.

The Open Social Web won’t win on ideology alone. It’ll win when a normie can join, find friends, discover content, and interact seamlessly—without understanding federation theory.

We’re closer than we were. These grades reflect that honestly.

Redemption is within reach. Some has already arrived.

Who’s bumping their grade next?


Follow-up to Tim’s Part 1and Part 2, and Sean’s solutions.

Tim Chambers (@tchambers@indieweb.social) runs Indieweb.social. Sean Tilley (@deadsuperhero@wedistribute.org) edits We Distribute.

 Share
pkg update's avatar
pkg update

@pkgupdt@hl.pkgu.net

이란 공격 #2

미국과 이스라엘의 이란 공격에 대한 단상 .

F-15E와 A-10의 격추와 파일럿 구출 작전에서의 피해는, 1. 이란의 저고도 방공망이 아직 작동 중임, 2. 비스텔스 재래식 항공전력의 안전이 담보되지 않음, 3. 이란 내부 침투는 막대한 피해를 수반함, 을 증명했다.

특히 2번 비스텔스기의 투입이 어렵다면 미국도 이란을 석기시대로 돌릴 수 없다. F-35, B-2, 토마호크 정도로 이란 정도의 나라를 쑥대밭으로 만드는 건 돈 이전에 물량이 되지 않는다. 트럼프 대통령이 발전소나 다리 등을 지목하는 이유도 딱 그 정도만 폭격할 수 있기 때문일 것이다.

공수부대나 해병대 투입? 최정예인 조종사 구출 부대도 해안, 국경에서 가깝고 반정부 세력이 강하다는 이란 남부 지대에서 며칠 작전하다 수송기 2대를 날려먹었고, 중상자가 많다는 루머도 돈다. 육상 전력 투입은 불가능하다. 이란은 여전히 저항할 힘을 가지고 있다.

미군은 지금 후퇴 후 재정비가 필요하지만 이란도 이는 잘 알고 있는데다 트럼프는 그럴 여유가 없다. 당장 일방적으로 물러서고 싶겠지만 걸프 국가들과 이스라엘 방어가 문제다. 이란은 이번 기회에 자신들의 공격에 협력한 국가들을 응징할 이유가 있다. 트럼프는 몰려있다. 모두의 위기다.

https://hl.pkgu.net/@pkgupdt/019d4541-2275-7f9a-b117-c5e5a6ab3356

pkg update's avatar
pkg update

@pkgupdt@hl.pkgu.net

이란 공격

잠 안 오는 새벽에 이란 - 미국, 이스라엘 전쟁에 대해서 개인적 단상 하나를 정리해본다.

핵심은 미국 공중 전력의 피해. E-3 센트리에, 공중급유기 다수, 사드 레이더 등 억 달러 단위의 핵심 전력들이 파괴되었다. F-15 오인 격추는 이에 비하면 가벼워 보일 정도. 걸프전 이래 미 공군이 이런 피해를 입은 전쟁은 없다. 미군의 전술에 큰 허점이 드러났고, 이는 미군을 오래 지켜보고 연구한 전술가들이 필요한 일이다. 공격에 필요한 위성 정보까지 생각하면 어디가 끼어들었는지는 거의 정해진 상황. 당연히 미군은 보완하겠지만 상당한 시간과 돈이 필요하다. 지금 당장은 아니다.

그래서 물러나서 재배치 하려고 하는데, 그에 필요한 기지들을 보유한 유럽 국가들이 거부했다. 미 공군 전력이 지중해로 후퇴, 재정비 하지 말라는 의미다. 유럽은 이 전쟁 - 정확히는 미국과 이스라엘의 공격 - 에 끼어들기는 커녕 이게 빨리 끝나길 바란다. 미 정부 입장에서는 정말로 비싼 군용기들이 위험한 중동 기지를 계속 쓰라는 말이니, 속이 탈만하다. 방공망 비용에 정밀 장거리 미사일 비용도 부담이고, 미 공군의 폭격은 AWACS와 공중급유 없이는 진행될 수 없다. 항모도 가까이에 배치하기 어렵다. 항모는 정말로 정말로 비싸고 상징적인 장비다.

탄도 미사일, 드론 믹스 공격이 미군의 전술 구도를 완전히 흐트려트렸다. 공군 기지는 위성 감시에서 벗어날 수 없다. 이 둘의 조합은 미 공군에게 몇십년 이래의 엄청난 피해를 강요했고, 지금 미군은 난감한 지경에 빠졌다.

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

@hongminhee@hackers.pub


So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool!

But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard.

That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel.

This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.

Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently

At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start.

First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors.

Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:

  • Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:
    // No name property
    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Note",
      "content": ""
    }
    // Equivalent to:
    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Note",
      "name": [],
      "content": ""
    }
  • Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:
    // Single value
    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Note",
      "content": "Hello"
    }
    // Equivalent to:
    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Note",
      "content": ["Hello"]
    }
  • Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):
    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "type": "Announce",
      // Embedded objects:
      "actor": {
        "type": "Person",
        "id": "http://sally.example.org/",
        "name": "Sally"
      },
      "object": {
        "type": "Arrive",
        "id": "https://sally.example.com/arrive",
        /* ... */
      }
    }
    // Equivalent to:
    {
      "@context":
      "https://www.w3.org/ns/activitystreams",
      "type": "Announce",
      // URI references:
      "actor": "http://sally.example.org/",
      "object": "https://sally.example.com/arrive"
    }

Attempting to manually handle all these vocabulary rules and JSON-LD variations consistently across your application inevitably leads to verbose, complex, and fragile code, ripe for subtle bugs that break federation.

Fedify tackles this entire data modeling challenge with its comprehensive, type-safe Activity Vocabulary API. It provides TypeScript classes for ActivityStreams types and common extensions, giving you autocompletion and compile-time safety. Crucially, these classes internally manage all the tricky JSON-LD nuances. Fedify's property accessors present a consistent interface—non-functional properties (like tags) always return arrays, functional properties (like content) always return single values or null. It handles object references versus embedded objects seamlessly through dereferencing accessors (like activity.getActor()) which automatically fetch remote objects via URI when needed—a feature known as property hydration. With Fedify, you work with a clean, predictable TypeScript API, letting the framework handle the messy details of AS vocabulary and JSON-LD encoding.

Challenge #2: Discovery & Identity—Finding Your Actors

Once you can model data, you need to make your actors discoverable. This primarily involves the WebFinger protocol (RFC 7033). You'd need to build a server endpoint at /.well-known/webfinger capable of parsing resource queries (like acct: URIs), validating the requested domain against your server, and responding with a precisely formatted JSON Resource Descriptor (JRD). This JRD must include specific links, like a self link pointing to the actor's ActivityPub ID using the correct media type. Getting any part of this wrong can make your actors invisible.

Fedify simplifies this significantly. It automatically handles WebFinger requests based on the actor information you provide through its setActorDispatcher() method. Fedify generates the correct JRD response. If you need more advanced control, like mapping user-facing handles to internal identifiers, you can easily register mapHandle() or mapAlias() callbacks. You focus on defining your actors; Fedify handles making them discoverable.

// Example: Define how to find actors
federation.setActorDispatcher(
  "/users/{username}",
  async (ctx, username) => { /* ... */ }
);
// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works!

Challenge #3: Core ActivityPub Mechanics—Handling Requests and Collections

Serving actor profiles requires careful content negotiation. A request for an actor's ID needs JSON-LD for machine clients (Accept: application/activity+json) but HTML for browsers (Accept: text/html). Handling incoming activities at the inbox endpoint involves validating POST requests, verifying cryptographic signatures, parsing the payload, preventing duplicates (idempotency), and routing based on activity type. Implementing collections (outbox, followers, etc.) with correct pagination adds another layer.

Fedify streamlines all of this. Its core request handler (via Federation.fetch() or framework adapters like @fedify/express) manages content negotiation. You define actors with setActorDispatcher() and web pages with your framework (Hono, Express, SvelteKit, etc.)—Fedify routes appropriately. For the inbox, setInboxListeners() lets you define handlers per activity type (e.g., .on(Follow, ...)), while Fedify automatically handles validation, signature verification, parsing, and idempotency checks using its KV Store. Collection implementation is simplified via dispatchers (e.g., setFollowersDispatcher()); you provide logic to fetch a page of data, and Fedify constructs the correct Collection or CollectionPage with pagination.

// Define inbox handlers
federation.setInboxListeners("/inbox", "/users/{handle}/inbox")
  .on(Follow, async (ctx, follow) => { /* Handle follow */ })
  .on(Undo, async (ctx, undo) => { /* Handle undo */ });

// Define followers collection logic
federation.setFollowersDispatcher(
  "/users/{handle}/followers",
  async (ctx, handle, cursor) => { /* ... */ }
);

Challenge #4: Reliable Delivery & Asynchronous Processing—Sending Activities Robustly

Sending an activity requires more than a simple POST. Networks fail, servers go down. You need robust failure handling and retry logic (ideally with backoff). Processing incoming activities synchronously can block your server. Efficiently broadcasting to many followers (fan-out) requires background processing and using shared inboxes where possible.

Fedify addresses reliability and scalability using its MessageQueue abstraction. When configured (highly recommended), Context.sendActivity() enqueues delivery tasks. Background workers handle sending with automatic retries based on configurable policies (like outboxRetryPolicy). Fedify supports various queue backends (Deno KV, Redis, PostgreSQL, AMQP). For high-traffic fan-out, Fedify uses an optimized two-stage mechanism to distribute the load efficiently.

// Configure Fedify with a persistent queue (e.g., Deno KV)
const federation = createFederation({
  queue: new DenoKvMessageQueue(/* ... */),
  // ...
});
// Sending is now reliable and non-blocking
await ctx.sendActivity({ handle: "myUser" }, recipient, someActivity);

Challenge #5: Security—Avoiding Common Pitfalls

Securing an ActivityPub server is critical. You need to implement HTTP Signatures (draft-cavage-http-signatures-12) for server-to-server authentication—a complex process. You might also need Linked Data Signatures (LDS) or Object Integrity Proofs (OIP) based on FEP-8b32 for data integrity and compatibility. Managing cryptographic keys securely is essential. Lastly, fetching remote resources risks Server-Side Request Forgery (SSRF) if not validated properly.

Fedify is designed with security in mind. It automatically handles the creation and verification of HTTP Signatures, LDS, and OIP, provided you supply keys via setKeyPairsDispatcher(). It includes key management utilities. Crucially, Fedify's default document loader includes built-in SSRF protection, blocking requests to private IPs unless explicitly allowed.

Challenge #6: Interoperability & Maintenance—Playing Nicely with Others

The fediverse is diverse. Different servers have quirks. Ensuring compatibility requires testing and adaptation. Standards evolve with new Federation Enhancement Proposals (FEPs). You also need protocols like NodeInfo to advertise server capabilities.

Fedify aims for broad interoperability and is actively maintained. It includes features like ActivityTransformers to smooth over implementation differences. NodeInfo support is built-in via setNodeInfoDispatcher().

Challenge #7: Developer Experience—Actually Building Your App

Beyond the protocol, building any server involves setup, testing, and debugging. With federation, debugging becomes harder—was the message malformed? Was the signature wrong? Is the remote server down? Is it a compatibility quirk? Good tooling is essential.

Fedify enhances the developer experience significantly. Being built with TypeScript, it offers excellent type safety and editor auto-completion. The fedify CLI is a powerful companion designed to streamline common development tasks.

You can quickly scaffold a new project tailored to your chosen runtime and web framework using fedify init.

For debugging interactions and verifying data, fedify lookup is invaluable. It lets you inspect how any remote actor or object appears from the outside by performing WebFinger discovery and fetching the object's data. Fedify then displays the parsed object structure and properties directly in your terminal. For example, running:

$ fedify lookup @fedify-example@fedify-blog.deno.dev

Will first show progress messages and then output the structured representation of the actor, similar to this:

// Output of fedify lookup command (shows parsed object structure)
Person {
  id: URL "https://fedify-blog.deno.dev/users/fedify-example",
  name: "Fedify Example Blog",
  published: 2024-03-03T13:18:11.857Z, // Simplified timestamp
  summary: "This blog is powered by Fedify, a fediverse server framework.",
  url: URL "https://fedify-blog.deno.dev/",
  preferredUsername: "fedify-example",
  publicKey: CryptographicKey {
    id: URL "https://fedify-blog.deno.dev/users/fedify-example#main-key",
    owner: URL "https://fedify-blog.deno.dev/users/fedify-example",
    publicKey: CryptoKey { /* ... CryptoKey details ... */ }
  },
  // ... other properties like inbox, outbox, followers, endpoints ...
}

This allows you to easily check how data is structured or troubleshoot why an interaction might be failing by seeing the actual properties Fedify parsed.

Testing outgoing activities from your application during development is made much easier with fedify inbox. Running the command starts a temporary local server that acts as a publicly accessible inbox, displaying key information about the temporary actor it creates for receiving messages:

$ fedify inbox
✔ The ephemeral ActivityPub server is up and running: https://<unique_id>.lhr.life/
✔ Sent follow request to @<some_test_account>@activitypub.academy.
╭───────────────┬─────────────────────────────────────────╮
│ Actor handle: │ i@<unique_id>.lhr.life                  │
├───────────────┼─────────────────────────────────────────┤
│   Actor URI:  │ https://<unique_id>.lhr.life/i          │
├───────────────┼─────────────────────────────────────────┤
│  Actor inbox: │ https://<unique_id>.lhr.life/i/inbox    │
├───────────────┼─────────────────────────────────────────┤
│ Shared inbox: │ https://<unique_id>.lhr.life/inbox      │
╰───────────────┴─────────────────────────────────────────╯

Web interface available at: http://localhost:8000/

You then configure your developing application to send an activity to the Actor inbox or Shared inbox URI provided. When an activity arrives, fedify inbox only prints a summary table to your console indicating that a request was received:

╭────────────────┬─────────────────────────────────────╮
│     Request #: │ 2                                   │
├────────────────┼─────────────────────────────────────┤
│ Activity type: │ Follow                              │
├────────────────┼─────────────────────────────────────┤
│  HTTP request: │ POST /i/inbox                       │
├────────────────┼─────────────────────────────────────┤
│ HTTP response: │ 202                                 │
├────────────────┼─────────────────────────────────────┤
│       Details  │ https://<unique_id>.lhr.life/r/2    │
╰────────────────┴─────────────────────────────────────╯

Crucially, the detailed information about the received request—including the full headers (like Signature), the request body (the Activity JSON), and the signature verification status—is only available in the web interface provided by fedify inbox. This web UI allows you to thoroughly inspect incoming activities during development.

Screenshot of the Fedify Inbox web interface showing received activities and their details.
The Fedify Inbox web UI is where you view detailed activity information.

When you need to test interactions with the live fediverse from your local machine beyond just sending, fedify tunnel can securely expose your entire local development server temporarily. This suite of tools significantly eases the process of building and debugging federated applications.

Conclusion: Build Features, Not Plumbing

Implementing the ActivityPub suite of protocols from scratch is an incredibly complex and time-consuming undertaking. It involves deep dives into multiple technical specifications, cryptographic signing, security hardening, and navigating the nuances of a diverse ecosystem. While educational, it dramatically slows down the process of building the actual, unique features of your federated application.

Fedify offers a well-architected, secure, and type-safe foundation, handling the intricacies of federation for you—data modeling, discovery, core mechanics, delivery, security, and interoperability. It lets you focus on your application's unique value and user experience. Stop wrestling with low-level protocol details and start building your vision for the fediverse faster and more reliably. Give Fedify a try!

Getting started is straightforward. First, install the Fedify CLI using your preferred method. Once installed, create a new project template by running fedify init your-project-name.

Check out the Fedify tutorials and Fedify manual to learn more. Happy federating!

pkg update's avatar
pkg update

@pkgupdt@hl.pkgu.net

https://www.youtube.com/@Imago-train

내용에 비해 인기가 없어 아까운 유튜브 채널 소개 .

이 채널은 솔직히 인기가 있기는 어려운 철덕 내용이긴 한데; 그래도 일본 여행에 관심이 있다면 운임 제도에 대한 설명 영상만 봐도 매우 도움이 될 겁니다. 그래서 추천합니다.

  • 근데 저 운임제도를 어떻게 이용할지 감이 온다면 일본 여행 최소 중수... 😇

Week in Fediverse :fediverse_light:'s avatar
Week in Fediverse :fediverse_light:

@weekinfediverse@mitra.social

Week in Fediverse 2024-12-13

Servers

- snac v2.66
- Lemmy v0.19.8
- ActivityPub for WordPress v4.4.0
- Mobilizon v5.1.0
- activity-pub-relay v0.6.0
- NeoDB v0.10.5
- Trunk & Tidbits, November 2024

Clients

- Husky v1.6.1
- AndStatus v62.01
- Voyager v2.21.0
- PeerTube mobile app : discover videos while caring for your attention
- tinmop: An opinionated client for Gemini, gopher, kami and Mastodon/Pleroma

Tools and Plugins

- Mastodon Bird UI v2.0.6
- PeerTube plugin livechat v12.0.2
- Fediseer v0.25.0
- notectl: A maintenance CLI tool for Misskey

For developers

- Fedify v1.3.1

Protocol

- Nomad Protocol and Nomadic Identity in the Fediverse
- FEP-1311: Media Attachments

Articles

- Alt Text Health Check image accessibility report #2
- PeerTube, a network of independent, self-managed and interconnectable platforms
- Why is Meta adding fediverse interoperability to Threads?
- Creating a generic "Log-in with Mastodon" service
- Last Week in Fediverse – ep 96

-----

#WeekInFediverse #Fediverse #ActivityPub

Previous edition: https://mitra.social/objects/01939db2-df57-8fe0-d681-88a30070e9a1