-

2024-12-17 01:28:31

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

Prediction: The next new hotness in the Fediverse; CW: Fediverse meta, non-Mastodon Fediverse meta

Artikel ansehen

Fediverse

show all 9 comments

2024-12-17 02:46:45

amd

amd@gts.amd.im

Prediction: The next new hotness in the Fediverse; CW: Fediverse meta, non-Mastodon Fediverse meta

Artikel ansehen

2024-12-17 09:10:03

Luca Sironi

luca@sironi.tk

@jupiter_rowland frontless is definetely a good idea, i hope other software server will follow

2024-12-17 09:58:57

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@Luca Sironi It depends. Not everything works well frontless because not everything works well with a frontend made for Mastodon.

Hubzilla, for example, has a UI that's largely stuck in 2012. Also, it doesn't have the Mastodon client API implemented. But a frontend designed for Mastodon couldn't even cover 5% of Hubzilla's features. It would not grant access to features that are actually critical for operating a Hubzilla channel such as any parts of the permissions system.

And that's actually one of the reasons why Hubzilla doesn't have the Mastodon client API implemented: The only UI that can sufficiently harness Hubzilla's power is Hubzilla's own native Web UI.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #MastodonAPI #Hubzilla

2024-12-17 10:07:47

Luca Sironi

luca@sironi.tk

@jupiter_rowland well, even in the lack of a better client, at least starting to split backend from frontend, seem to me a good suggestion for every project, even the ambitious one !

2024-12-17 12:38:05

aliceif

aliceif@mkultra.x27.one

@jupiter_rowland@hub.netzgemeinde.eu (I was going to reply to this from my hollo account but apparently fedify fails to interpret hubzilla URLs, sadly)
Hollo is a pretty good illustration of how well and not well frontendlessness can work.

For context: Hollo is a very young server whose defining feature is that is for single user instances and very light-weight, minimalist, and built on a standardized backend (fedify). However there is no frontend included, all you get in public is a list of posts on the account and otherwise there is some admin tools when logged in. It does have non-Mastodon features like Quote-Renotes and Emoji Reactions though.
Hollo relies on the Mastodon Client API to actually be used, so you will have to find clients that work:

On Android, there is at least one client, Subway Tooter, that really does it all - quote posts, emote reactions and all the feeds work. It works stably too. Didn't even have to try any others.
For web browser use, Phanpy and Elk both work. Elk is kind of worse because it's very vanilla Mastodon, Phanpy has some quirks due to its "opinionated" nature that can be a bit offputting, buts its quote support and ability to at least recognize (but not send) emoji reacts make it the better choice. There seems to be no way other than Android app emulation to get emoji reacts on Windows.
iOS is where the fun begins. Basically any of the free apps will fail to some degree during use, either the local timeline or the notifications tab will be broken in some way. A bunch of apps won't even let you log in. And some apps that are free actually charge money for the ability to post or renote. Nightfox Dawn however seems to work mostly completely and has the extra non-mastodon features, but it feels somewhat unstable - and costs money.

So overall, if you primarily use iOS you will be in a lot of trouble. But Android has the optimal experience available. Meanwhile in-browser you will lack one of the most fun features on offer 🙁

2024-12-17 15:36:42

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@aliceif That, of course, sounds like trouble. No frontend offers you the full functionality with no problems. But still, it's obvious that Hollo is developed for a Mastodon-dominated Fediverse with a side of *key and little regard for anything else. I wouldn't be surprised if the Hollo dev, like at least three quarters of the Fediverse, had never even heard of Hubzilla.

Hubzilla is a special case in many ways. It wasn't built into a Mastodon-dominated Fediverse because it was initially created some four years before Mastodon. Also, it doesn't have replacing Twitter as any of its goals. You can use it for microblogging, yes, but then, you can use it for almost anything. Even the official Hubzilla website runs on Hubzilla.

Granted, Friendica is even older. After all, Friendica's own creator started Hubzilla as a Friendica fork. But Friendica's new developers decided for Friendica to approach Mastodon in some ways. In Hubzilla's case, in stark contrast, it's an explicit design and development decision not to do that. Part of Hubzilla's philosophy is to remain independent from the rest of the Fediverse.

Hubzilla is also one of the few Fediverse projects whose ActivityPub implementation is not designed for maximum Mastodon compatibility. That's partly because Hubzilla is the only Fediverse project that had ActivityPub before Mastodon. And Mastodon's adoption of ActivityPub caused quite some head-butting between Mike Macgirvin and Eugen Rochko.

That's only some of the reasons why the Mastodon API would never work for Hubzilla, and Hubzilla will always require its own tailor-made frontends.

Beyond that, there are those many, many things neither covered by the Mastodon API nor by any Mastodon-compatible app. And I'm not just talking about CMS or groupware features like articles, cards, wikis, webpages or the two built-in calendar systems. (That is, Hubzilla's CalDAV calendars are edited the best with external apps, but via CalDAV and not via the Mastodon API.)

It actually starts at Hubzilla's handling of identities. Your identity is not tied to your account. Your login is not your identity. You can have as many fully separate identities, called "channels", on the same account with the same login. And thanks to nomadic identity, you can have the same channel, the same identity, on multiple server instances with different accounts and logins.

An app based on Mastodon and its API would only let you access your default channel at best. At worst, it won't let you access anything because it expects your identity and all your stuff directly on your account, and it's completely unaware of the existence of channels. This is already a feature that's essential for using Hubzilla, but that absolutely requires a UI tailor-made for Hubzilla.

Then there is the distinction between posts and comments. Hubzilla does not mimic Twitter. It's closer to Facebook and blogs.

For one, Hubzilla doesn't display content bit by bit like Mastodon does, at least not by default. It's actually an option that nobody ever uses which may be why it's no longer available on (streams). Instead, it always displays conversations as a whole, just like Facebook, just like blogs, just like forms. Post on top with a title, comments below in chronological order. Always. Even when a new comment comes in, or someone has liked or repeated a comment, when you go and look at what happened, you get the whole thread.

Speaking of which, on Hubzilla, you don't usually do as you'd do on 𝕏 or Mastodon and scroll through your feed/timeline until either you hit stuff that you've already read, or you want no more. Instead, Hubzilla, like everything that Mike Macgirvin has made, has a counter for unnoticed actions. If you open it, you get a list of these actions that you haven't paid attention to yet. Click one, and you're taken to the thread where it happened (and only that thread is shown to you), and everything that was unread in this thread is flagged read.

In addition, 𝕏 has only one editor for everything, posts, comments (which are posts), DMs. So does Mastodon. So do all Twitter/𝕏 alternatives in the Fediverse.

But Facebook doesn't. It has a separate entry area for comments. So do blogs. And so forth. And so does Hubzilla. It has a post editor, and it has a separate comment editor with a different set of features right at the bottom of each thread. It's geared towards having these two separate editors. Even using Friendica, which does have the Mastodon client API implemented, with a one-editor app has to be hackish.

All this continues with text formatting. Unlike the *keys and some Mastodon forks, Hubzilla doesn't use Markdown. It uses BBcode with some crazy additions that go way beyond what you can find on bulletin board forums. This goes all the way to integration of OpenWebAuth magic single sign-on and being able to embed any number of images right in your post, basically in-line, with text above and more text below.

Generally, image handling, including alt-text. On Mastodon and its forks, you attach your images to your posts as files, and then you get one dedicated entry field for alt-text for each image.

On Hubzilla, you first go to your Photos app and use it to upload the images you want to add to your post to the WebDAV-enabled file space built into your channel. You have to pay attention to setting the permissions both for the image files and for the subfolder correctly. Then you go to your post editor (not the comment editor which doesn't officially support inserting images) and select the image you want to embed. And then you have to get your hands dirty on raw BBcode image-embedding code to add alt-text. (Notice how I've linked to a Hubzilla support forum instead of the WIP help rewrite because there still is no official documentation on how to add alt-text on Hubzilla.)

Any UI elements geared towards the Mastodon way of adding images to posts are useless on Hubzilla, and nothing on a UI for Mastodon can be used to add images to posts the Hubzilla way. Again, you need a Hubzilla-specific UI for this.

By default, and I guess it's actually recommended, posts and comments are composed in raw BBcode rather than WYSIWYG. The lack of a preview button in your average Mastodon app is actually a lesser issue, although it still is an issue.

Next, posting permissions. Mastodon has "Public", "Unlisted", "Followers only" and "Private". All apps are geared towards this.

Hubzilla, in contrast, has the ACL. It offers you to post in public, to post only to yourself, to post to one of your privacy groups (think Mastodon lists on piles of coke and 'roids), or to post to any individual custom selection of connections of yours. There's no "Followers only", there's no "Unlisted", and there's stuff that's completely unthinkable from a Mastodon POV.

Oh, and if you run your Hubzilla channel on bone-stock standard default settings, you post to a privacy group named "Friends" unless you explicitly choose otherwise. But you have to be able to choose otherwise in order not to only post to that privacy group. An app made for Mastodon won't give you the UI elements to do so.

In fact, an app geared towards the Twitter-style dichotomy of followers on the one side and followed on the other side will clash with Hubzilla because of just this. Again, Hubzilla is not like Twitter. It's like Facebook. It doesn't have one-sided following connections. It only has mutual connections like Facebook friends.

This means that handling connections on Hubzilla, but with a UI made for Mastodon, is next to impossible at worst and very, very limited and much less than optimal at best.

For example, let's suppose someone wants to connect to me. On Mastodon, I'd just simply confirm their follow request if I've chosen to do so. Then I may decide whether or not I follow them back.

Here on my Hubzilla channel, a connection request takes me to the connection editor. There I choose a contact role for the new connection that defines which permissions that contact shall have. I add the connection to one or multiple privacy groups, of which I have a lot. I adjust the affinity slider. I may also assign a different profile than my default one to that connection. I may add lines to one of the two filter lists which I have per connection. Finally, I usually hide the new connection. And then I confirm it which not only grants the permissions in the contact role to the contact, but also establishes a bidirectional connection. It's like automatically following everyone back on Mastodon.

Apart maybe from the confirmation button, not even a single one of these features is available on any of the Twitter replacements in the Fediverse, and thus, not in any of the apps geared towards these either. If I were able to use Hubzilla with a Mastodon app, I'd still have to fire up a browser or a Web app or wait until I'm back home to confirm connection requests.

All this only covers your daily operation. I haven't even talked about configuration yet, including the channel role which defines the basics of Hubzilla's extensive permissions system.

There's exactly one app that works with Hubzilla. It's called Nomad, it's only available on F-Droid, it hasn't been updated in over five years, and it's actually a Web app that works like a specialised browser and embeds Hubzilla's Web UI.

A fully dedicated mobile app for Hubzilla that entirely relies on a native mobile UI would be so complex even for normal operation (disregarding the CMS bits) that it'd be more complex than K-9 Mail. If you want to go all the way, including app management (which controls Hubzilla's optional features, and which of these are available to you can differ from hub to hub) and CMS features and such, it'd be even more complex.

The only realistic way to have different frontends for Hubzilla would be the built-in theming feature. It doesn't mean different colours and button styles. A theme on Hubzilla can be an entirely different UI, but one that you can individually choose for each one of your channels. It's like being on Akkoma and being able to switch between Akkoma-FE, Phanpy and Mangane on your account at any given time.

That is, currently, Hubzilla has only got one built-in theme. It has become quite flexible in terms of colours and background images, and it even as a dark mode which is every bit as configurable as the light mode. More themes are being worked on in the community right now, but I wouldn't count on them coming with all stock Hubzilla installs, much less automatically added to all existing hubs.

So if you want an alternative UI for Hubzilla, you don't install it next to your hub, just like you install Phanpy next to Hollo or GoToSocial. You install it into your hub instead.

And the best way of developing alternative UIs for Hubzilla is not as fully separate external applications that try to latch onto Hubzilla from outside. It rather is as a third-party add-on for Hubzilla itself.

Hubzilla is modular and extendable with third-party repositories.

Lastly, both desktop and mobile use can profit from it because the best way to use Hubzilla on a phone is as a Progressive Web App.

@Luca Sironi, maybe this is interesting for you as well.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hubzilla

2024-12-17 17:01:44

aliceif

aliceif@mkultra.x27.one

@jupiter_rowland@hub.netzgemeinde.eu @luca@sironi.tk (whoops you somehow dropped off the thread)
I ended up seeing that you replied but the reply did not make it to my Misskey, so I'm replying here (sorry):

The main thing I wanted to say is that even things that are rather like Mastodon still struggle to actually work with existing clients - but that there is also quite a lack of options in general.

This is also why I find the western Misskey forks' desire to pander to mobile users by trying to function with existing Mastodon Clients so counterproductive - the Mastodon Clients often just don't care. They really only are for Mastodon and everything else is "good luck have fun".
Frontless servers to me are a bad idea, as things stand - despite the appeal in speeding up initial development.

2024-12-17 17:11:41

Der Pepe (nomád) ⁂ ⚝

pepecyb@nomad.fedi-verse.hu

Hubzilla, for example, has a UI that's largely stuck in 2012.

...but improvement is within reach:

Bild/Foto

2024-12-17 20:57:58

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@aliceif

This is also why I find the western Misskey forks' desire to pander to mobile users by trying to function with existing Mastodon Clients so counterproductive - the Mastodon Clients often just don't care. They really only are for Mastodon and everything else is "good luck have fun".

Or rather, "Wait, you exist?!"

And IIRC, Misskey has its own client API. Aria seems to be the shooting star mobile app for the *keys.

Frontless servers to me are a bad idea, as things stand - despite the appeal in speeding up initial development.

In this regard, Pleroma and Akkoma are the best of both worlds. Headless server, own client API, respective official frontend has its own repository, but you may install third-party frontends instead. And Mangane is actually (also) built against the *omas. "Akkomane" is a thing.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #AriaApp #Pleroma #PleromaFE #Akkoma #AkkomaFE #Mangane #Akkomane