Comment on A general fediverse client app, supporting multiple content types? (mastodon, lemmy, peertube, etc)
JupiterRowland@sh.itjust.works 2 months ago
It isn’t just types of content that makes a fully featured, unified Fediverse client nigh-impossible. It’s features in general.
It all starts with having one unified timeline for any arbitrary number of Fediverse identities on any arbitrary number of different Fediverse servers. Nicely convenient. You only open one app, and you’ve got them all. Not even separated timelines within the same app, TweetDeck-style. No, you have posts on your three Mastodon accounts under posts on your Pixelfed account under posts on your Lemmy account under posts on your Friendica account, maybe even under posts on your Hubzilla channel if the app isn’t limited to the Mastodon API, and if it supports multiple identities under one login.
But it doesn’t stop there.
Maybe you want to reply to a post. Or you want to post something yourself.
And, of course, you don’t want to stick with the basics that Mastodon offers. Maybe you want to use text formatting.
So text formatting has to be implemented. But it has to be deactivated if you want to post to one of your Mastodon accounts, but it has to be reactivated if one of them is actually on Glitch.
Next trouble: Not everything that supports text formatting supports standard Markdown. Misskey and its various forks use “Misskey-flavoured Markdown”. On Friendica, Markdown is optional and off by default, and BBcode is the standard. On Hubzilla, Markdown is not available at all, only BBcode is, and it comes with a whole slew of extras specific to Mike Macgirvin’s nomadic projects from Red (2012) to Forte (2024). So yes, you may want support for things like [zmg][/zmg]
, [zrl=][/zrl]
or [observer.baseurl]
.
Of course, if you are on Friendica or Hubzilla or (streams), you’re used to having a post preview. Code-heavy posting like on these three makes it a requirement; pure plain-text posting like on Mastodon doesn’t. But the preview button must be able to faithfully render any post just like its native server application would render it. No matter what it’ll be. Oh, and if you’ve got NSFW activated on your Friendica account or your Hubzilla or (streams) channel, the preview must be hidden behind an automatically generated content warning.
Speaking of which, Mastodon-style CWs aren’t unified either. Depending on the server, they would have to go into the CW field, the summary field, [abstract=apub][/abstract]
(Friendica), [summary][/summary]
(streams) or nowhere at all (e.g. Lemmy, replies on Hubzilla).
The Fediverse has various different ways of quote-posting, and Mastodon doesn’t have quote-posts at all. The Threadiverse has dislikes/downvotes/thumbs-down, Friendica, Hubzilla and (streams) optionally have them, too, but others don’t. Misskey and the Forkeys have emoji reactions. Hubzilla has only twelve emojis, and clicking one creates a whole new comment with only that emoji in it. Friendica lets you hashtag other people’s posts, so does (streams) optionally, but only they themselves even understand this feature.
Friendica, Hubzilla and (streams) also have categories, much like a blog, next to hashtags. At least on Hubzilla and (streams), they’re optional. But they require their own text field which the app must have, too, depending on the availability of this feature.
This goes further and further. After all, you may not just want basic functionality for when you aren’t on your computer. Maybe you don’t have a computer. Maybe your phone is the only digital end-user device you possess. So the app would have to cover not only the bare necessities (read, reply, post etc.), but everything.
For example, someone wants to follow you. On Mastodon, you just confirm it if you’ve set your account up to do so manually, and you’re done.
On Hubzilla with enough optional features activated, you assign a contact role to the new contact to give it the permissions you want to grant it, you add it to one or multiple privacy groups, you choose which profile that contact can see, you adjust the affinity slider, you may even want to pre-fill the per-contact filter lists (one allowlist, one blocklist), and then you confirm the new connection. Upon which Hubzilla automatically follows that connection back. Oh, and then you can still block or ignore or archive a connection or set it to invisible. On (streams), it’s somewhat similar, but since you can grant individual permissions to specific contacts in addition to a pre-defined permission role, you’ve got even more options.
A unified, daily-driver Fediverse app that’s supposed to fully replace Web interfaces would have to offer UI elements for all these settings. And only when they’re actually needed.
Don’t get me started about settings and options. Again, the app would have to mirror all of them. Many people have never touched the Web UI of their Fediverse servers, and they don’t intend to. They do everything on their phones with dedicated apps.
On Hubzilla, this would include access to Hubzilla’s built-in “apps”. “Install”, “uninstall” and configure them. Many important optional features are “apps”. But amongst these “apps”, there are also things like articles, wikis and Web pages. And what would being able to turn these features on and off be worth if you couldn’t use them in the app? And so the app will also have to provide access to Hubzilla’s articles and wikis and Web pages with all bells and whistles.
Of course, whenever a Fediverse server app changes in a way that makes changes in the UI necessary, this unified mobile app would have to follow suit immediately.
ShittyKopper@lemmy.blahaj.zone 2 months ago
Yep, all this ^^^
This is also one of the reasons why I believe ActivityPub client-to-server failed and will likely never gain much traction. It either needs every single client to re-implement all the features it wants from scratch, or the entire ecosystem needs to be dumbed down to fit a single mold. Leave all the unique functionality in “uncommon” software like (streams) and friends, even software like Lemmy or PeerTube would likely be extremely difficult to build in a world where client-to-server actually became a thing.
The only way I can see C2S actually taking off is as IPC between an “app server” (which would be the equivalent of Mastodon or Lemmy or (streams)) and a “federation server” which is just a dumb pipe that distributes and receives objects and activities, and even that has it’s fair share of concerns, both around efficiency and the same “dumbing down” problem.