Conversation

Notices

1. Embed this notice
   Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 19:13:20 JST Strypey

   • Tim Chambers

   (1/2)

   "And even our terms 'Server' Or 'Instance' make sense in an engineering flowchart but why in all that is holy would we foist those onto users to pretend to understand? At the very least we should talk about new folks joining a 'server community' of fellow users."

   @tchambers, 2025

   https://www.timothychambers.net/2025/06/18/113327.html

   So much for "server" making more sense to newbies than "instance". I followed the herd on this usage, even though I questioned the wisdom, given how overloaded the term "server" is.

   • Tim Chambers repeated this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 19:36:08 JST Strypey

     in reply to

     (1/2)

     "Worse? There’s no encryption [on DMs]. So it’s not just accidentally public—it’s intentionally insecure. It’s plaintext dressed up as a secret. There is some fine print warning you, But let’s be real: nobody reads fine print mid-conversation."

     @tchambers, 2025

     https://www.timothychambers.net/2025/06/18/113327.html

     Gargron is squarely to blame for this.

     Tim Chambers repeated this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 19:36:12 JST Strypey

     in reply to

     (2/2)

     I'm hesitant to add yet another meaning to "community" for the same reason. Also because not all instances *are* communities, in any meaningful sense of the word.

     What about just "service"? Eg example.social is a service connected to the fediverse. Just like it's a service connected to the net, and presuming it has an https portal, it's a service connected to the web.

     I'll admit "service" has a lot of existing meanings too, but most of them apply in this usage.

     Tim Chambers repeated this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 19:36:37 JST Strypey

     in reply to

     • Tim Chambers

     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.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 19:36:38 JST Strypey

     in reply to

     (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.

     Tim Chambers repeated this.
   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Wednesday, 25-Jun-2025 19:41:29 JST Tim Chambers

     in reply to

     @strypey Thank you!

     I’ll go back and edit that a bit to show that I have nothing but love for the FEP process!

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

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Wednesday, 25-Jun-2025 19:43:14 JST Tim Chambers

     in reply to

     @strypey And part 2 is live now: https://indieweb.social/@tchambers/114739709799083596

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Wednesday, 25-Jun-2025 19:51:48 JST Tim Chambers

     in reply to

     • silverpill

     @strypey @silverpill Am very much looking forward to your thoughts! ✊

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 19:51:50 JST Strypey

     in reply to

     • Tim Chambers
     • silverpill

     @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.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 20:59:18 JST Strypey

     in reply to

     • Tim Chambers
     • Fedilab 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.

     Tim Chambers repeated this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 21:16:00 JST Strypey

     in reply to

     • Tim Chambers
     • Fedilab Apps
     • Lucas @Moshidon 🇺🇦 🇵🇸

     (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

     Tim Chambers repeated this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Wednesday, 25-Jun-2025 21:18:24 JST Strypey

     in reply to

     (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?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Thursday, 26-Jun-2025 07:49:57 JST silverpill

     in reply to

     • Tim Chambers

     @tchambers @strypey

     Indeed, we have FEPs that either directly address the UX issues mentioned in your post, or could be parts of final solutions:

     The Sin of Overwhelming Complexity: Instance Selection Paralysis

     - https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md

     The Sin of Remote Interaction Purgatory: Federation Gymnastics

     - https://codeberg.org/fediverse/fep/src/branch/main/fep/07d7/fep-07d7.md (withdrawn; https://fedilinks.org is a similar proposal)
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/3b86/fep-3b86.md

     The Sin of DM Disasters Waiting to Happen

     Some FEPs talk about limited visibility posts and private groups:

     - https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/db0e/fep-db0e.md

     The Sin of Ghost Conversations and Phantom Follower Counts

     Synced conversations:

     - https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/76ea/fep-76ea.md
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/f228/fep-f228.md

     The Sin of Invisible Discovery: The Content Mirage
     The Sin of User Discovery Hell

     I think ActivityPub relays could be used to solve those problems:

     - https://codeberg.org/fediverse/fep/src/branch/main/fep/ae0c/fep-ae0c.md

     Tim Chambers repeated this.
   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Thursday, 26-Jun-2025 08:27:22 JST Tim Chambers

     in reply to

     • silverpill

     @silverpill @strypey

     Love these. When there re two or more #FEPS for a fix for a UX Sin, is that because they are both competing with each other for final support? Or are those cases where they are both complimentary FEP's that both answer part?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Thursday, 26-Jun-2025 08:56:30 JST silverpill

     in reply to

     • Tim Chambers

     @tchambers @strypey Proposals often compete with each other. But they are not curated, and all competing proposals may reach the FINAL status (which simply means that proposal is reviewed by the community and no further changes will be made).

     The measure of success for a FEP is not the FINAL status, but the number of implementations. We're currently trying to figure out how to properly gather and present this information to the readers.

     Tim Chambers repeated this.
   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Thursday, 26-Jun-2025 09:12:14 JST Tim Chambers

     in reply to

     • silverpill

     @silverpill @strypey Got that: thanks you!

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Thursday, 26-Jun-2025 09:13:54 JST Tim Chambers

     in reply to

     • silverpill

     @silverpill @strypey And as I look through these, do any one of the relate to the issue of seeing remote accounts with say 10 followers but when you click to view those followers they are "ghosted" and invisible to you as they hadn't federated your way yet?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Friday, 27-Jun-2025 03:00:20 JST silverpill

     in reply to

     • Tim Chambers

     @tchambers @strypey

     This may happen if the server reads the total number of items in the followers collection, but doesn't retrieve individual items -- for performance reasons or because it doesn't trust the publisher.

     A possible solution to the latter problem is described in FEP-0391, but there are no implementations yet.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Friday, 27-Jun-2025 10:46:37 JST Strypey

     in reply to

     • Tim Chambers
     • silverpill

     @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

     Tim Chambers repeated this.
   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Friday, 27-Jun-2025 10:48:10 JST Tim Chambers

     in reply to

     • silverpill

     @strypey @silverpill That would be of great value I think. ✅

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Friday, 27-Jun-2025 10:56:49 JST Tim Chambers

     in reply to

     • silverpill

     @silverpill @strypey Thank you!

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Friday, 27-Jun-2025 18:53:07 JST silverpill

     in reply to

     • Tim Chambers

     @strypey @tchambers

     Maybe. But first, an automated implementation counting will be added:

     https://codeberg.org/fediverse/fep/pulls/634
     https://socialhub.activitypub.rocks/t/implemented-fep-type/5048

     Tim Chambers repeated this.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Saturday, 28-Jun-2025 05:14:01 JST silverpill

     in reply to

     • Tim Chambers
     • Adam Dalliance
     • jonny (nonvenomous)
     • Lucas @Moshidon 🇺🇦 🇵🇸
     • Mayel

     @mayel Conversation containers (FEP-171b) might be relevant to your work on circles in Bonfire. That mechanism is used for circles and private groups in Streams and Hubzilla.

     @strypey @jonny @tchambers @moshidon @pre

   • Embed this notice
     Mayel (mayel@bonfire.cafe)'s status on Saturday, 28-Jun-2025 05:14:02 JST Mayel

     in reply to

     • Tim Chambers
     • Adam Dalliance
     • silverpill
     • jonny (nonvenomous)
     • Lucas @Moshidon 🇺🇦 🇵🇸

     @silverpill@mitra.social

     
     

     Thanks for compiling that list! We've opened a few issues with FEPs to investigate: github.com/bonfire-networks/...

     
     

     @jonny@neuromatch.social @strypey@mastodon.nzoss.nz @tchambers@indieweb.social @moshidon@floss.social @pre@boing.world

     Tim Chambers repeated this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Saturday, 28-Jun-2025 22:48:07 JST Strypey

     in reply to

     • Tim Chambers
     • 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

     Tim Chambers repeated this.
   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Saturday, 28-Jun-2025 22:48:21 JST Tim Chambers

     in reply to

     • silverpill

     @strypey @silverpill +1 to this idea

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Saturday, 28-Jun-2025 23:28:49 JST silverpill

     in reply to

     • Tim Chambers

     @strypey Pull requests submitted to FEP repository are reviewed by facilitators, who should verify that implementations actually exist and are independent. Of course, this will be done on a best effort basis, but I think the result will be accurate enough.

     @tchambers

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Sunday, 29-Jun-2025 03:33:16 JST Tim Chambers

     in reply to

     • silverpill

     @silverpill @strypey I am as cautious about AI as anyone but here I think LLM’s might assist human curation.

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Sunday, 29-Jun-2025 08:33:44 JST Tim Chambers

     in reply to

     • silverpill

     @strypey @silverpill was thinking you could have Gemini 2.5 or Claude opus 4 do some early grunt work base level lifting just to see which FEPs have been implemented by which fedi platforms at scale. Benefit: likely more comple inventory than human alone. Cost: in compute resources not too much this is what LLM’s are good enough at.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:33:45 JST Strypey

     in reply to

     • Tim Chambers
     • silverpill

     @tchambers
     > LLM’s might assist human curation

     With what benefit, at what cost?

     @silverpill

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 29-Jun-2025 08:52:14 JST silverpill

     in reply to

     • marius
     • jonny (nonvenomous)

     @strypey @jonny

     Two FEPs are related to filtering:

     - https://codeberg.org/fediverse/fep/src/branch/main/fep/5bf0/fep-5bf0.md
     - https://codeberg.org/fediverse/fep/src/branch/main/fep/6606/fep-6606.md (cc @mariusor)

     And there is one about synchronization: https://codeberg.org/fediverse/fep/src/branch/main/fep/8fcf/fep-8fcf.md

     Nothing has been proposed for inclusion check yet, but I heard that Lemmy devs plan to implement it, see this discussion: https://socialhub.activitypub.rocks/t/fep-db0e-authentication-mechanism-for-non-public-groups/4197/5

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:16 JST Strypey

     in reply to

     • silverpill
     • jonny (nonvenomous)

     @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)

   • Embed this notice
     jonny (nonvenomous) (jonny@neuromatch.social)'s status on Sunday, 29-Jun-2025 08:52:18 JST jonny (nonvenomous)

     in reply to

     @strypey
     Both are legal by virtue of how a URL is treated as equivalent to an object in linked data, so it's not so much a spec thing as an implementation thing. 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.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:20 JST Strypey

     in reply to

     • jonny (nonvenomous)

     @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?

   • Embed this notice
     jonny (nonvenomous) (jonny@neuromatch.social)'s status on Sunday, 29-Jun-2025 08:52:21 JST jonny (nonvenomous)

     in reply to

     @strypey
     I'd like to have diff-aware collections that you could send the last timestamp to and it gets you everything that has changed since then, but no such mechanism in AP and it would be pretty hard to do. Doing per-post update denouncing has worked fine so far, though imo 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

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:22 JST Strypey

     in reply to

     • jonny (nonvenomous)

     (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

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:24 JST Strypey

     in reply to

     (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.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:25 JST Strypey

     in reply to

     • Daniel Supernault

     (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.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:26 JST Strypey

     in reply to

     (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.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:27 JST Strypey

     in reply to

     (5/?)

     Progressive disclosure of feeds, absolutely. I agree that the wilderness of Federated feeds comes last ; )

     But I wonder if it would be better to start with Local rather than Home. Which is just tumbleweeds until Alice follows someone, and still pretty quiet even then. Although starter packs would help with this, eg;

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

     Maybe Home could be disclosed the first time Alice follows an account? Then she can flip back to Local to find more people she wants to follow.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:29 JST Strypey

     in reply to

     (4/?)

     You kind of cover this here;

     "It already exists for Mastodon just to share a link like this - rather than sending them to some more global sign up."

     I guess I'm arguing for this as a general norm. But I definitely see the logic of your 'service roulette' concept. I agree that would break us out of the false entrance of entrance exam vs. dumped onto the flagship and handed an oar.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Jun-2025 08:52:30 JST Strypey

     in reply to

     (3/?)

     Maybe as technologists, we need to discourage people from signing up to random stuff they find online (especially given the ubiquity of VC-driven DataFarming, #MOLE slop, etc)?

     We could encourage them instead to find reliable online services the same way you'd find a trustworthy mechanic or a good coffee; web'o'trust style, through social connections. So instead of joining the fediverse, people join a fedi-enabled service run by someone they can get to know (like that local mechanic).

   • Embed this notice
     Tim Chambers (tchambers@indieweb.social)'s status on Sunday, 29-Jun-2025 13:44:44 JST Tim Chambers

     in reply to

     • silverpill

     @strypey @silverpill

     Example - https://docs.google.com/document/d/162zajNYqHzvWeIeDMd9iIHzo--RYCFiuQJUNO07Hjs0/edit?usp=drivesdk