Notices by Strypey (strypey@mastodon.nzoss.nz), page 2

(6/?)

Not for the first time, reading the section on protocol handlers made me think about extended, future fediverse apps as a potential *replacement* for existing corporate-enshittified web browsers (and yes, I'm including Mozilla in this). Social web browsers, if you will.

It would be trippy to live through 2 complete media navigation transitions in one lifetime (broadcast>web, web>social web). But with enough UX tweaking and a critical mass of adoption, it could happen.

(7/?)

Totally agree about DMs. In fact, I'd go further; make private messaging a totally separate app, that I can login to with the same account. Like @dansup's proposed Sup Messenger.

Even better, if folks could sign in to a Matrix app as @strypey(at)mastodon.nzoss.nz or into a fediverse app as @strypey:matrix.iridescent.nz, rather than needing to creating and managing 2 sets of credentials, arguably there would be no need to shoehorn E2EE DMs into fediverse apps at all.

(8/?)

Love the ideas about search, especially;

"... let server admins choose the default search opt-in state appropriate for their community ."

Again I think our goal here is best served by more speciation of fediverse apps. In apps for publishing social media (FunkWhale, PeerTube, WriteFreely, Ghost, WP), opt-out makes sense. In apps for quiet social networking (eg Bonfire Social), opt-in makes more sense. Mastodon et al might need to choose a lane and set defaults accordingly.

(9/?)

Nothing much to add to the section on backfilling threads etc. Except to say that your suggestions here are a good example of evolving fedi-apps towards being social web browsers. Rather than just dumb clients, slavishly parroting what one server (the one your account is on) sees as the whole verse.

Also, curious to know if what @jonny worked up for Mastodon works anything like this;

https://codeberg.org/fediverse/fediverse-ideas/issues/92

@jonny
> collections of replies should get serialized as plain collections of URLs so it's much cheaper to paginate them, and then the posts could be fetched in a second step

@silverpill do you know of any FEPs relevant to this?

@jonny
> The spec change would be to add more methods to collections: get a subset by requesting a set of URLs, check for presence (is this set of URLs in your collection, true/false) so the host server wouldn't have to serialize the whole thing, etc.

@silverpill do you know of any FEPs relevant to this?

(Tried to mention you in my last post to Jonny, but somehow left the server part of your address)

@tchambers
> Has anyone even got an alpha version of a C2S app running?

There's over a dozen implementations now;

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

#HatTip to @smallcircles for compiling this list, and @benpate for reminding me where he keeps it : )

@rakoo @jupiter_rowland

@tchambers
> LLM’s might assist human curation

With what benefit, at what cost?

@silverpill

@silverpill
> But first, an automated implementation counting will be added

That sounds useful for sure. But note I specified 3 *unrelated* implementations. If 3 soft forks of a popular codebase (eg 3 *keys), that doesn't tell us nearly as much about whether this FEP is suitable for general use.

So either that needs to be factored in to automated counts, or we'd still need a human admin marking an FEP as IMPLEMENTED, based on their assessment of the independence of those counted.

@tchambers

@benpate
> It’s all speculation in the absence of a C2S API that developers want to use

The main reason devs haven't wanted to use the C2S API in the AP spec is network effect. Clients devs don't want to use it because Mastodon doesn't, and servers devs don't want to use it because their services wouldn't work with all the clients following the Mastodon API.

But there are a bunch of projects now implementing AP C2S. I'm sure I've seen a list somewhere.

EDIT: here;
https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

@jupiter_rowland
> The ActivityPub C2S API is just as untested

That was absolutely true 5 years ago. But it's getting less true all the time. As I say, there are a number of server and app projects with implementations now. Which is producing a lot of feedback about how to improve it for a future iteration of the AP spec.

People keep pointing out the UX fail of expecting people to have multiple accounts to use all the different fedi services. But that wouldn't be true if every #AP app and server used a general purpose #C2S API, defined in the AP spec (whether the existing one or not).

Then we could, for example, use a Mastodon account to login to a PeerTube service to browse and post videos. Or use a PT account to login to a Mastodon service to browse and post Notes.

@tchambers @rakoo @benpate @jupiter_rowland

"... I believe we could really ramp up the momentum of user migrations if people could join together at the same time.

... One careful consideration to make: check server blocks, and do some logic to make sure they all end up on servers that don't block each other."

@deadsuperhero

https://deadsuperhero.com/mitigating-the-7-deadly-fediverse-ux-sins/

I love this idea! It's a way of operationalising some of the suggestions I made here;

https://bridgeseat.substack.com/p/into-the-woods-we-go

@tchambers

@silverpill
> The measure of success for a FEP is not the FINAL status, but the number of implementations

Maybe there needs to be an IMPLEMENTED status, that comes after FINAL? Perhaps when at least 3 (unrelated) implementions are tested as compliant with that FEP spec?

@tchambers

(2/?)

We're used to an onboarding norm of signing up for random online services, even though we have no idea who runs them. Or what their motives are, or how competent they are. Or how long the services might exist, or how likely it is to enshittify, or how quickly.

That norm suited the rapid prototyping stage of the web. When it was a fun toy, or maybe a supplement to existing workflows. But maybe it's time it changed to reflect the new reality that we come to depend on these things?

(1/?)

A few late night thoughts off the top of my head @tchambers. You've done a great job laying out technical solutions (mostly). Some of these problems may also have social solutions.

For a start, I've already mentioned "service" as a replacement for "instance". The "instance" (of Software A) is what it runs on, but "service" describes what it's there for (hopefully). If it's not there to be of service, maybe it's best newbies don't join?

@moshidon @apps

Hey @moshidon and @apps devs, have you come across this piece on fediverse UX fixes by @tchambers?

https://www.timothychambers.net/2025/06/24/the-seven-deadly-fediverse-ux.html

It's the follow-up to a very thorough piece on our biggest UX fails. Some great diagnosis in the first one, and some very actionable suggestions in this one. Well worth a read.

@tchambers
> I have nothing but love for the FEP process!

I figured as much, but good to know for sure : )

> if there is one final or near final #FEP I should point to for each UX fix happy to go back and add them!

That's a bit above my paygrade, but @silverpill might have some suggestions?

> And part 2 is live now

All my Christmases come at once! : P Will devour this now.

(2/2)

Those of us who've been here since GNU social was the dominant software, remember him shoehorning DMs into OStatus so Mastodon would be more like Titter. Without even making sure they wouldn't display publicly in other software. Spoilers: they did.

So the other projects had to scramble to reverse engineer Mastodon's posting scopes to avoid that. As did AP editors. Even though it would have been better to hold off on DMs, and work towards a protocol-level consensus on doing them right.

Just some idle thoughts @tchambers. I love that you've put all this in one place, I love the tongue-in-cheek way you explain it all, and I'm really excited to see part II, with the potential solutions you have to offer.

I'm especially hoping to see some love for the FEP process, given the way you seem to casually dismiss it towards the end of the piece. Some of these UX fixes do need protocol-level support, and FEPs are a community-driven process for filling AP potholes.