Post Visibility and Standardizing UX of across the fediverse

Not sure if Fediversity is the appropriate category for this, but…

As Eternal November began, I realized I’d become really confused about what an ‘Unlisted’ post does in Mastodon.

At the start of this month, I thought I could use unlisted posts to have loads of side conversations, without flooding the people following my account. I also though that hashtags still worked in unlisted posts. Which I liked because I thought I could spare the people following me long strings of posts on a niche topic, while still making them available to anyone doing hashtag searches for the kind of stuff in them. I described my confusion in more detail in the Mastodon forum, and some kind person offered some clarification of how things currently stand. Turns out I’d had this completely wrong for years :smile:

But writing out this explanation to seek this clarification, made me realize a number of things. With AP, we currently have a standard for server-to-server communication in the fediverse, and one for client-to-server communication (although nobody uses it). But we don’t really have any UX standards for the fediverse. There is no spec that explains to developers what people ought to be able to expect from any AP app, and no manual that explains it in lay language to those people. For an example of what I’m getting at, have a look at this set of UX standards for the jabberverse; chat apps using XMPP.

To be clear, I’m not talking about trying to standardize UI. One of the strengths of an open standard is that it allows for the development of a multitude of UI that serve different use cases, and different people’s needs. Eg Vanilla Mastodon is there for people who want a Titter-a-like, Lemmy is there for people who want a Reddit-a-Like, or, some people love the TweetDeck-inspired “advanced” UI in Mastodon, some people find it overwhelming and distressing (me!) and prefer a single-column layout. It’s great that both of these can exist, and as many others variations on UI that there’s a need for, or an interest in.

What I’m talking about trying to standardize, sits somewhere beneath the UI, but in parallel to the data model. It’s the set of concepts people have about what the software is supposed to do, that they then seek to find the appropriate controls for in the UI. Some of these concepts; ‘public post’, ‘private post’, ‘follow’, ‘mute’, block’, ‘edit post’, may have a technical definition in the spec. But they also need a lay definition, easily available to people trying to understand how to use fediverse apps, or explain it to their friends. Other concepts may not have an equivalent in the technical substrate;

  • whether and when viewing a profile will show you the account’s posts

  • how to know if an address points to a dead account (eg instance is dead, or user has deleted) while trying to interact with it

  • whether or not hashtags work when placed in a Content Warning

  • how much of the fediverse an instance is blocking on blocked by, to get a sense of whether its the right place for a new account

  • wellness settings, like those in Pinafore, that do things like obscure followers, boost, favourite, and notification counts.

  • delayed posting options, like those in FediLab and some other apps

  • display of server/client used to post, so that someone helping a newbie has information about the software they’re using and can give more helpful advice, with a bonus effect making it clear not everyone is on Mastodon

  • options for migrating acounts/ data between instances

An attempt to standardize some UX expectations for the fediverse would involve studying all the apps that are already out there, separating these concepts out from their implementation in specific UI, and aggregating the best practice from all the existing and proposed UI. This would give app developers a sense of what people expect in a UI and what they’ve found to work.

Perhaps what I’m talking about is exactly what FEPs are for?



As far as ActivityPub is concerned, there are no visibility scopes. There is only recipients for delivery, and there is audience.

ActivityPub clients (and monolithic app-servers too) are free to choose how they display information they receive or are aware of. The concept of “viewing a profile” also doesn’t exist. Things like wellness settings are the responsibility of the client (or monolithic app, again).

If you are interested in “best practices”, then FEPs are nominally equipped to describe this, but the majority of FEPs describe extension behavior that isn’t in the core spec. There is one FEP that attempts to describe “Group federation”, as implemented by Lemmy and authored by the Lemmy dev. Other than that, projects are encouraged to have their own documentation or