Is there any fediverse client out there (mobile or pc or web) that has support for multiple types of content, rather than just for one?
Most apps I find are only mastodon-like (including pleroma etc.), or only lemmy-like, or only peertube-like. One of the main benefits of the fediverse is that I could theoretically access all of those from one platform. But the clients I saw don’t seem to support it too well.
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.