👋 Everyone: see what you think:
The Seven Deadly #Fediverse UX Sins Part 2: The Road To Redemption: https://www.timothychambers.net/2025/06/24/the-seven-deadly-fediverse-ux.html
Don't claim that these are final answers - but hope they help continue constructive motion to final answers!
cc: @renchap @dansup
@cheeaun @scottjenson @newsmast @andypiper @ricmac @evan @laurenshof @pfefferle @fediversenews #fedidev #mastodev @timbray
I think we are hitting the limitations of AP, but I have high hopes that one day it's rewired to use Fediverse Discovery Providers (or something similar) and stop relying on inbox/outbox
Thank you for your articles! They help a lot to think the design of Fediverse and get inspiration about how to solve inherent issues!
Loved to read them!
Just waiting for post #3 where you connect a funding model to all of these things. Where you sort out how the 12 people at Mastodon or the 1 person at PixelFed can make all of your dreams come true thanks to their newly discovered funding?
Look, it's great that you have ideas. All of those ideas would be more meaningful if they came with a check attached.
This from @sean is EXACTLY the type of conversation I hoped to spark and everywhere he suggests addition fixes I was unaware of I love them all.
https://social.wedistribute.org/objects/cf1e6d28-20bb-41b9-8677-e085ec15a6d0
A number of folks are looking at conversation containers, now that this effort has solidified. This solves so many thorny decentralisation issues that at this point if you don't provide containers to do things like groups, circles, comment control, and conversation completion (one of the bullets), you've probably painted yourself into a corner. The only way out of that corner is to track down conversation elements across the fediverse.
Yeah, we did that too - and in case folks haven't noticed, it doesn't scale. So we looked for a solution.
That (scaling) doesn't bother me, because we provide a more intimate and personal social networking experience, but for the projects trying to compete with the corporate silos; if it doesn't scale it doesn't actually work. Conversation containers can provide complete, moderated conversations at scale. Moderated by the topic creator, instead of an instance admin that you've never met -- and whose values and anxiety triggers are unknown.
But to do this correctly, we also turned off the public timeline (it's optional) and stopped making everything public by default. These are all personal choices, but in a safer place, the defaults should be for more safety and less harassment potential. And we use OpenWebAuth for one click interactions with remote websites. This allows protected content both over ActivityPub and also to the same audience via the web -- by signing the web requests, just like you would do for requesting ActivityPub objects. OpenWebAuth just does this using webfinger and without requiring your browser to have a copy of your private key (which I probably wouldn't recommend).
So, I am still reading through this but I see a–to me– quite obvious issue with having a roulette of "trusted servers"
…What if your software barely even has other instances, letalone ones that would be considered "trusted"?
App.wafrn.net is to this day basically the only Wafrn instance that we know will be hear in 1-3 years from now; Even if only because we develop directly here; We simply don't have other instances to point to if we wanted to
Do we just note this down as being a painpoint of newer, less widespread software? Is the solution to just wait?
Granted we have some issues as to how we do updates that make running an instance sort of annoying; We don't do versioning, just to name one example. But I really feel like that point – while we were explicitly mentioned – kinda left out cases like ours
Thanks for the boost @1br0wn
eupolicy.social
Am thinking of hosting a Github demo of a bare bones example of code working that does Option A, and at least B as a JavaScript backup as I suggested to combine custom protocol handler/JavaScript fallback work.
Would folks be interested, or interested in helping? cc: @funnymonkey
That’s Tim. Fantastic article! I’ll have more to say after I re-read this a dozen times, but I want to get out early with an answer to #3: remote actions…
This is why I built fep-3b86 “Activity Intents” which lets people take remote actions from their home server with one click and zero fuss. No JS, no funny protocols required.
Could you please weigh in on this?
@tchambers @renchap@dansup @cheeaun @scottjenson @newsmast @andypiper @ricmac @evan @laurenshof @pfefferle @fediversenews @timbray
@benpate - can you post a link to that #FEP here? Is this it: https://codeberg.org/fediverse/fep/src/branch/main/fep/3b86/fep-3b86.md
Thank you! And, sorry. My phone was acting up so I skipped the link.
I opened issues with many of the most popular projects. Fortunately, this kind of thing can be rolled out incrementally, starting with adding a few easy records to WebFinger results.
Further down the road, you could enhance it to include other kinds of interactions that aren't possible now (remote Blocks, anyone?)
Andy, what would be my best next step in getting this on the radar at Mastodon?
I understand wanting to bundle things into AP. Let’s fix the core and not abandon it, right?
But the use case here isn’t in ActivityPub. It happens when I’m visiting a website OUTSIDE of my home server. It’s how we see 90% of the internet.
So building this feature into AS doesn’t make sense.
These interactions need to tie more deeply into Fediverse servers in the same way that the FB “like” button does. That’s what FEP-3b86 does.
I think I skimmed FEP-3b86 some time back and found it interesting, but then promptly forgot about it. Probably overkill for what I'm doing, but we've supported the ostatus subscribe mechanism for follows and it makes sense to use the same for comments and remote posting if it's available. The current rpost mechanism was to add support for some sharing protocol from 2011 that vanished in 2012 and I can't even recall the name at the moment. Could make it compatible with FEP-3b86 in a few days by just renaming (or adding) the new parameter names, depending on the legacy impact. Then our "wall-to-wall" posts/comments/likes could be signed correctly, which presents a minor federation issue otherwise. And it would work great with OpenWebAuth to auto-identify the remote actor and ascertain their permissions, so it would still be a single click.
That's a long way of saying "I'm in".
(And this fedi UX thing makes your toot seem like a top post in mastodon web UI, not showing further up the thread. Luckily there's 'Open original page' if one is aware of that)
@ just small circles 🕊 It's not Fedi UX. It's Mastodon UX. Big difference.
Here on Hubzilla, I see the whole thread as one right away, all the way to the start post, without having to look at it at its origin.
The only improvement that I'm waiting for is the tree-style view that'll soon be rolled out with Hubzilla 10.4 (Friendica, (streams) and Forte already have tree-style views whereas Hubzilla had a strictly chronological thread view until the recent RCs).
# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla # Conversations # ThreadedConversations
Yes, if browsers understood ActivityPub then the whole world would change. I’d love that.
We’d need everyone on board, but Ms, Apple, and Google might follow if Mozilla and Vivaldi proved it would work.
That would require a working C2S API.
And all of that is years away 😩
I think we get there with incremental, evolutionary steps that prove the Fediverse is viable, and attract more non techies to the community.
@ Ben Pate 🤘🏻 In the words of a diaspora* developer, if Mozilla and Vivaldi "implemented ActivityPub", they'd actually "implement Mastodon". That'd mean catching more users with less effort than implementing vanilla ActivityPub and implementing features that Mastodon doesn't have. Besides, both used to have or still have a Mastodon server, but they don't seem to be aware that there's a Fediverse beyond Mastodon, much less what it's like and how it works.
In fact, they wouldn't even implement the ActivityPub C2S API at all. They'd implement the Mastodon client API and only the Mastodon client API.
CC: @rakoo @Tim Chambers
# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Fediverse # ActivityPub # Mastodon # MastodonAPI
FYI, just bumped into the ghost follower UX issue on my own trying to follow @arstechnica folks they follow: 6 followers on the profile, none in the actual link yet. "Followers on this profile may be missing."
As non-federated. Looking forward to fixing this.
@renchap The main problem I was trying to solve for was accurate remote visiblity of users followers and being able to browse and manually pick and choose one at a time those one would wish to follow. In that use case if this FEP implemented does the same resource hogging dynamic you describe still have to occur under the hood so to speak?
As always thank you for this discussion! cc: @silverpill
Or something like that, much like how followers list is only followers that your instance knows about, not all followers listed by the actor.
So instead of:
• You → requesting all 600 followers
• Server → refusing or returning just an empty collection
It would work like:
1. When you follow someone, your server sends an Add activity to add you to their followers collection.
2. Their server replies (or updates) the original activity with a proof: “Yes, this person was added to my followers.”
3. Anyone (including remote servers) can then verify that proof without needing the full follower list.
Great read, thanks for thinking this through and writing it up!
Your points are absolutely valid, and I would certainly hope, that somebody finds the time to implement your suggestions. Very nice to know, that Mastodon is already at some.
The thing is, I think right now, #Bluesky is just hotter than #Mastodon & the #Fediverse. But that will change again, and it would be really great, when this stuff is fixed by the time an new wave of incoming people arrives. If we like it or not, many people were thrown away by exactly what you're describing.
What you were just touching a bit, but what is maybe also more important, than many think: The lingo is not helping. (And certainly not the people, who are always quick to correct anyone not using it 100% correctly 😉)
Cheers Tim for a good post again. I see you're getting pushback on the onboarding server idea. I would argue that had we a good account portability model that solved also post history, there would be no need for a centralized onboarding. Don't like your local community or service provider? Migrate somewhere else. Bluesky does have this slightly better thought out, if not yet practically proven.
@tchambers
Once that idea sinks in I bet pushback lessens. But I do think you are 100 percent on track that better user portablity makes this whole thing better.
Yeah - while I'm not entirely a fan of the "fedi is like email" argument (due to public vs private, identity and spam control differences), the migration question, I think, compares to number portability, which is basically 100% transparent across most markets today (though only within countries) and has improved mobile networks for both consumers and operators. Fedi should be less like email, more like mobile networks.
@tchambers
The UX (and guides) for this whole thing feels like 2010. When most people are used to modern UX.
I think there is a deeper layer of 'identity management' that could address a lot of the issues.
I think I deeply disagree with this on a fundamental level: as I understand it, you think about decentralization as an engineering strong point, but as a product/UX problem. For me, what is important is the polar opposite: decentralization is key on a product level. I don't support the Fedi because I want a world with a single community-run social network. I support the Fedi because I want a world without any single social network with more than a few thousand uses. I don't want a new, better Twitter. I want an internet that's wild and truly decentralized again. You can't wild the internet by asking people to own their homes but then imposing an HOA that defines how those homes should look like. As Gabbo said, that's just the bluesky model. I don't want bluesky. I want weird platforms developed by a Peruvian teenager where you can't upload any picture that is not of a cat and have three dozen users being as first class Fedi citizens as the flagship mastodon instance. Actually, I want no flagship mastodon instance to exist as the flagship anything.
If we want people to change their mindset about what internet should be, we can't mold ourselves to what they already expect internet to be.
my problem with #1 is that it fails to take the power structure of a decentralised system into account. there is no topdown actor who can decide this. Even in a hypothetical scenario where a new platform software comes along, this does not actually solve the problem. You cannot coordinate all platforms and instances to implement this.
/1
@laurenshof Love this discussion! 👍 Will reply more during lunch work break.
But in short response now to the objection that there is no top down actor or actors who can decide to implement this or system and curate the round robin set of other servers:
Wouldn’t https://joinmastodon.org/
https://joinpeertube.org/
https://pixelfed.org/how-to-join and
https://joinbookwyrm.com/
(To use just a few examples)
…all be such current top down actor who each are big on-ramps now who could do this?
for people who now want to join the fediverse the situation got even more confusing: their choice set simply got expanded from 25k fediverse servers to 25k servers plus a special onboarding instance
/2
You missed the deadliest sin of them all - not enough cute animal pictures!
This is a really really great piece Tim. I hope we can follow some of your suggestions as we continue to develop things under the Newsmast umbrella.
That is the bluesky appview model basically with extra steps
#There-is-so-much-discourse-about-this #I-already-had-my-fights-with-this-and-i-have-decided-to-use-my-energy-in-wafrn-instead
And btw love what you have built at Warfn and will go edit this to include you in the mentioned Fedi platforms that might implement some of these ideas 👍
Also: i talk up the idea of #Lemmy and #Mbin and #Piefed and the #Threadiverse in the idea on surfacing content...
Much of that idea was spurred by this from Piefed on it's potential feed format that can pull in multiple other community fediverse acocunts into one feed:
https://join.piefed.social/2025/04/30/how-piefed-federates-feeds-aka-multi-reddits-or-multi-comms/
And would love to hear what @rimu thinks of my riffing on this for discovery fedi wide, and if he had notes.
1. A lot of what you're describing is mastodon behavior, not universal properties of the fediverse.
2. This is more or less the same list of problems that I've been reading about for 3 years now. Listing the problems doesn't solve them. What would really help would be sustained support for one or more fedi backend projects. Research, docs, marketing, triage and prioritization, community management, and eventually design and implementation.
Just a note that the threads problem has been a solved problem for GoToSocial for a while now, too.
@oli Great note - I love @gotosocial work. And was honored that they chose to put one of their accounts on the server i started.
And in terms of feeds standards for the web. This article talks up #Surffeeds from @surf but also @newsmast community feeds, and @Flipboard federated magazines.
I could imagine the same might work with Top WordPress or Ghost content publishers as well, but I'm still understanding the mechanisms for discovering surfacing such content from top federated wordpress blogs or sites, and top Ghost authors. cc'ing @johnonolan and @pfefferle
Right now I could see doing this idea for top Medium.com authors on Me.dm but that is via their http://me.dm server, and @coachtony just for fun I'm making a Surffeed now of top me.dm accounts to play with that idea.
cc: @mike
So for the Protocol hander discussion, I was particularly influenced by @timbray in articles such as this one: https://www.tbray.org/ongoing/When/202x/2025/04/16/Decentralized-Schemes
Curious both if TIm thinks I took the right lessons from his writing....
And very much interested in @evan and his thoughts on the idea as describe in the post. And @jenniferplusplus
As well as what browser tech folks like @jon and @jensimmons would think of my rendition of the state of play and how to move forward on web protocol handler support.
i'm starting to get a little incredulous at the sheer number of times people suggest new protocol schemes and handlers for what is still fundamentally an HTTP resource
if we switched to serving web+activity: or fedi: or whatever, that'd be a horrific regression in UX because clicking/copying links would *break* for most people
the problem is most "fedi" apps are building a web browser inside a web browser. that's the fundamental ux sin. all else stems from that.
I guess that isn't how they work in reality. But wouldn't it be useful if they did?
Wouldn’t this plus a JavaScript backup greatly reduce the remote engagement current UX issue?
I’m not sure the nature of your objections here are is: I think you may be saying if implemented that this new UX with basically only one prompt and then everything works, isn’t as much an improvement as I’m selling it to be?
the root cause of the ux issue is the double-browser pattern, inspired by silos.
Better still I propose that each server have a Servebot that boost the public posts of the public feed (with moderation etc)
https://boffosocko.com/2023/01/10/full-rss-feeds-for-mastodon-instances-with-openrss/
In small part this does that for the user when prefs are set.
And this app, absolutely fantastic ability to make a curated list.
Personally, I'm not a fan of the idea that the server, however curated, push feeds to me.
I wouldn't like pushing either: In what I describe, no one pushes anything, they'd just be activitypub actors you could follow, or ignore.
Still halfway reading, great effort!
And finished the article... A lot to unpack, thanks a lot and sorry for nitpicking!
A space for Bonfire maintainers and contributors to communicate
