firefox
this post was submitted on 29 Aug 2024
74 points (97.4% liked)
Fediverse
28223 readers
364 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
Unpopular Opinion:
Fuck apps.
Use web browsers.
I would be glad if a unified web client exists. Mobile app is not necessary.
I'm not actually super familiar with the unified web clients, but you could be right that one is out there, or perhaps we're just asking too soon in the general Fediverse development cycle. In a year or two, someone might have designed something like that, perhaps with a post like this as inspiration.
But where would a unified Web client run in the first place? It would have to be installed on a Web server and, from there, access the Web servers of the various different server apps which would still be entirely different and independent installations.
For a Web client with no actual server backend, the same would go as for a mobile app: It would have to cover pretty much all features of everything. If uniting Lemmy and Mastodon in one UI seems tricky already, try adding Hubzilla and (streams) to the mix.
If you're actually looking for a unified Web server and client, i.e. one Fediverse project that literally covers everything the Fediverse can do with one login on one server and one identity: This won't happen.
This would be way too much for one Fediverse project to tackle. You'd basically have to start with (streams), add back all functionality that has been removed since the first fork from Hubzilla (and that's a whole lot), make all kinds of non-nomadic protocols compatible with nomadic identity via Nomad and ActivityPub, and then gradually add all kinds of features from all over the place, from PeerTube to Funkwhale, from PieFed to Owncast, from Mobilizon to BookWyrm. And you'd have to soft-fork everything and keep them in-sync with their respective upstreams.
The outcome would be too complex for most. People would have to deal with their account/their login not being their identity because their identity is containerised in a channel. They would have to wrap their minds around nomadic identity. They would have to deal with fine-grained permissions settings. They would have a post editor that's every bit as powerful as those on big blogging platforms when all they want to do is tweet and retweet and occasionally watch a video. And they would have tons of features on top.
The whole thing would be an utter nightmare for its developers as well, seeing as they'd constantly have to track over 100 Fediverse projects and implement any upgrades which they've rolled out.
But where would a unified Web client run in the first place? It would have to be installed on a Web server and, from there, access the Web servers of the various different server apps which would still be entirely different and independent installations.
There are already web clients for the fediverse, like Photon for Lemmy
For one specific Fediverse project each, yes.
But what the OP is looking for is a Web client that lets you log into Mastodon and Lemmy and PeerTube all the same. Probably one that unifies your Mastodon, Lemmy and PeerTube timelines into one, rather than listing your Mastodon timeline next to your Lemmy timeline next to your PeerTube timeline in three separate columns, TweetDeck-style.
Or maybe what the OP is looking for is a Web server and client that unites all features of Mastodon and Lemmy and PeerTube in one Fediverse project so that only one single login is needed for everything.
Neither of these exists.
I know, I was just replying to the part I was quoting. Point is, hosting that web client wouldn't be an issue.
It would just either have to be on a server that also offers all server applications covered by the Web client so that everything has the same domain.
Or you would have to tell people to register accounts on foo.social, bar.social and/or baz.social, but the Web UI is on qux.social. Bit confusing for newbies who only knew centralised silos five minutes ago.
But wasn't the point of the post that it should, in theory, be possible to use a single account for all the different services by having a client that supports them all, since these different services federate with each other? I don't know if that's currently possible without making changes on the backend but if you need different accounts for each service, even if it's handled on the back-end, that kinda goes against the whole point of the post, no?
That would basically require all Fediverse servers of all types to grant full-blown user access to Fediverse users with their login credentials stored anywhere in the Fediverse.
I'm not sure if OAuth could do that. Hubzilla supports both OAuth and OAuth2, both as a server and as a client. But for this to work, everything in the Fediverse would require both server-side and client-side OAuth support.
Also, for convenience, OAuth support would basically have to be combined with OpenWebAuth-style magic single sign-on. With bare-bone OAuth, a user would first have to authenticate with a remote server or client or whatever. This is inconvenient. It would have to happen magically on the fly without the user even noticing anything, much less having to act in any way.
If Lemmy had client-side OpenWebAuth support, and you visit a Hubzilla hub, that Hubzilla hub would automagically grant you certain guest privileges because it recognises you.
If it was a combination of OAuth credential transfer and OpenWebAuth magic single sign-on, and you visit a Hubzilla hub, you could create a new, full-blown Hubzilla channel residing on that hub, just as if you had a local account, and you could do everything with that channel that you could do with a channel on a local account.
In general, this would create the issue of things being stored in the local server database, like posts or even local settings, but not associated to any one local account in the same database. It's bad enough with content, e.g. posts. It's even worse with technical stuff like settings. I mean, if you drive-by magic-log-in to Mastodon with a Lemmy account, you want all the Mastodon settings, to customise your Mastodon experience, now, don't you?
Now imagine you want to delete your Lemmy account. All of a sudden, discuss.tchncs.de would have to go around to 239 instances of a dozen different projects, because that's how many you've used to do stuff, and wipe stuff from databases on remote servers. Alternative: It stays there, but the user account on discuss.tchncs.de that it's associated with doesn't exist anymore.
Or imagine you'd done that not on discuss.tchncs.de, but on kbin.social which infamously is dead. You'd have stuff in the databases of 239 Fediverse instances that's associated with login credentials on a dead server. No feckin' chance to ever get rid of that stuff unless all Fediverse projects implement some CPU-heavy sanitiser that regularly checks whether the servers and login accounts behind all remote stuff in the databases are still there.
It'd be even worse with server applications that support nomadic identity. Hubzilla and (streams). There, your identity is not your account. They're separate already. Your account is only your login, your access to your identity. Your identity is containerised in something called a "channel" that can be cloned to other servers.
You can't just drive-by magic-log-in to a Hubzilla hub and start posting away and, what, create a wiki or something. Your posts and wikis and whatnot aren't stored in your account. They have to be stored in a channel. So you'll first need a channel. You'll have to create it. By the logic, you'll have a Hubzilla channel and thus a nomadic Hubzilla identity named [email protected] based on your login credentials. If in this case Hubzilla supports naming channels after login credentials rather than the hub, the server instance they're created on, that is.
Technically speaking, however, since the domain in the ID of the channel differs from the server domain, it's a clone. It is not a main instance. The main instance of a Hubzilla channel always has the same domain in its ID as the hub it resides on. But discuss.tchncs.de is not Hubzilla, nor does it support Hubzilla channels, so Hubzilla channels can't reside on discuss.tchncs.de.
Other connections from Hubzilla and (streams) that understand nomadic identity will relentlessly try to connect to a channel on a Hubzilla hub on discuss.tchncs.de. But there is no Hubzilla hub on discuss.tchncs.de because it's a Lemmy server and not a Hubzilla hub. So your precious Hubzilla channel will be broken from the beginning because the Hubzilla hub that defines its identity does not exist.
But where would a unified Web client run in the first place?
Man, I already run like 10 different microservices that all have their own web portal and they're all locally hosted.
What's one more?
I literally connect to every IRC instance through The Lounge, a locally hosted web interface for multiple concurrent IRC connections.
You could definitely do the same for a web UI for the fediverse.
Just split the difference and give me PWAs. Let The matrix tell my brain the steak is chewy and delicious.
Hubzilla and (streams) can be installed as PWAs.
So maybe an inelegantly hacked together startpage that shows all your feeds in one for the morning coffee?
ngl web apps are even worse, they're so bloated and janky, I wish everything had a native app
I don't think so. The closest might be fedilab. They support masto+ forks, pleroma, friendica, pixelfed, peertube, and many of the misskey forks partially (with fuller support promised). No Lemmy/mbin though and I haven't seen anything saying that support is on the roadmap.
Even Fedilab is limited.
Sure, most "Fediverse apps" are Mastodon apps which allow you to use anything that supports the Mastodon API, but which only offer you Mastodon's feature set, maybe even only the feature set of Mastodon 3 if the app is old enough.
Fedilab has specific features of other projects coded in. After all, it's made by Pixelfed's creator and developer, so it has to support as many Pixelfed features as possible, even if Mastodon doesn't have them.
But Fedilab doesn't have all features of all supported projects. For example, Fedilab does not have the necessary extra entry field for post titles on Friendica.
For sure, support isn't always complete and the Masto API is doing a lot of heavy lifting. I think that Fedilab really wants to be a Fediverse app though. I'm pretty sure their development has slowed a lot in the last year too because their dev has had some health issues. Although it's "tom79," not Dansup (who makes Pixelfed and a million other things).
I don't think it supports Pixelfed-exclusive features either. I don't think there's even an app that supports stories right now - even the official one.
It's a hard user experience design problem to create an interface that presents all possible types of posts, content and interactions in a sensible way. This "kitchen sink" approach is kind of what Facebook does and as a result its interface is messy and cluttered. That's not to say it's impossible or wrong to do things that way, just difficult and unpopular.
On the technical side, it's really hard to make a client app that works with multiple server softwares, because they all have different sets of features.
In the current world of fedi software development, it would be a single dev or a small, likely unpaid team that would have to make the equivalent of several different client apps combined into one. I don't anticipate such a large and complicated project being completed until the devs can make a decent living doing the work.
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.
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 protocol 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.
If you really need it to be a proper mobile app then it's unlikely you'll find one - this would be quite a lot of work as every platform has implemented it's own API for talking with client apps, rather than using ActivityPub. The app would need to talk to several different APIs.
You're better off choosing a platform that can talk with as many different types of other platforms as possible. And when I say 'talk with' there will be gradients of talking with differing amounts of problems. For example PieFed is great with Lemmy, good with PeerTube and Ok with Mastodon. Then use the client app for your chosen platform.
Choosing the platform will be a process of just trying them all. Check out friendica, they cast a wide net.