I'm daily-driving Hubzilla, and I have been doing so under various independent identities since it was still fairly new (second half of the 2010s).

By default, Hubzilla doesn't look much different from what Friendica looked like in 2012 when Hubzilla started out as a Friendica fork named Red. However, very very recently, third-party themes have started emerging.

The default UI, the Redbasic theme, is quite convoluted and can be confusing. That's because work done on it over the last 13 years was almost limited to slapping more UI elements to it somewhere. Configuration is split between the Settings page in the channel menu, cogwheel icons towards the left of the navbar on some pages and even a few (partially actually essential) settings exclusive to /settings/features, a page for which there is no link on the UI anywhere (unless you have the newbie links on). And configuration is important; using Hubzilla at default settings makes even less sense than using Friendica at default settings.

On top of this, Hubzilla is highly modular, similarly to Friendica. There are dozens of "apps" which the hub admin can activate or deactivate for everyone, and in addition, some "apps" are on by default on new channels (if they're on for the whole hub), and some are off. This means that some optional features are activated by turning settings on whereas others are activated by "installing" an "app" as a user.

On top of even this, one of the "apps" that are off by default is Pubcrawl, Hubzilla's ActivityPub connector. Hubzilla has to be the only Fediverse server application on which ActivityPub has to be activated manually. That's because Zot6 (Hubzilla's version of the Nomad protocol, formerly known as Zot) doesn't interact as smoothly with non-nomadic protocols as (streams)' more current version of Nomad. Back in 2015, Hubzilla was geared towards purely nomadic operation. Since then, the Fediverse has changed a lot (and not into the direction which was desired in conjunction with Hubzilla's development), but Hubzilla hasn't in this regard.

And "installing" the ActivityPub "app" is only one of the things highly recommended to do before you even only post something or connect to someone.

Even if you're used to Friendica, Hubzilla's learning curve can and probably will be staggering. That's because Hubzilla is even more complex than Friendica. It's Friendica with a content management system, a groupware server, a whole new concept of identity and the second-most powerful permissions system in the whole Fediverse.

The first huge difference between Friendica and Hubzilla: On Friendica, like almost everywhere else in the Fediverse, your account/login is your identity. On Hubzilla, your identity is independent from your account/login.

For starters, you can have multiple independent channels on one account where one channel corresponds to one Friendica account, only without its own login. You can switch back and forth between all channels on one account without logging out. Friendica, Mastodon and everything else that doesn't understand the Nomad protocol (i.e. everything that isn't Hubzilla or (streams)) understands Hubzilla's channels as separate accounts.

This is not to be confused with Friendica's multiple profiles per account. Hubzilla has multiple profiles per channel, too, which can be assigned both to privacy groups (think "lists") and individual contacts. You can have multiple identities, with multiple profiles each if so desired, on one account.

But you cannot only have multiple channels on one account on one hub. You can have the exact same channel on multiple hubs with one account each. This is called "nomadic identity", something that Bluesky claims to be working on pioneering, but that has actually been first implemented by Friendica's and Hubzilla's creator as early as 2012 as the ultimate safety net against unannounced server closure.

Nomadic identity is basically a live, hot, near-real-time backup of an entire channel with almost everything on it ("almost" because the one thing that isn't mirrored is which apps you have installed on your channel) on another server instance. And it's bidirectional. You can actually log onto your clones and use them like the main instance, e.g. if the hub with the main instance is offline. Whatever you do there will be mirrored to your main instance and your other clones if you have more than one clone. And you can declare one of your clones the new main instance and thereby demote your previous main instance to clone status.

Another difference is that permissions are everything on Hubzilla. Hubzilla has the second-most powerful permissions system in the Fediverse, only barely behind (streams) and Forte. Permissions are granted on three levels: for the whole hub, for individual contacts, per conversation.

On a hub level, there are four so-called channel roles which define what the channel generally permits: Public (social networking with a lot of permissions granted right away), Personal (social networking with fewer permissions granted), Community forum (public group) and Custom (adjust all channel-level permissions yourself, one by one).

You can grant permission for others to

• see your channel stream, i.e. what you've posted, including the entire conversations
• send you their posts
• see your default, public profile (all other profiles aren't public anyway because you have to assign them to privacy groups or individual contacts)
• see your contacts
• look onto your file server and see your images and other files (including when they're embedded in a post, comment or PM; this can be overridden with a special setting outside the channel role configuration that allows those to see images embedded in posts, comments or DMs who are also allowed to see the corresponding post/comment/DM)
• upload files to your file server or change existing files on your file server
• see the webpages on your channel (I'm not even kidding, you can optionally have static webpages on your channel; the official Hubzilla website itself is a webpage on a Hubzilla channel)
• see the pages in your wikis (I'm still not kidding, you can have multiple wikis with multiple pages each on your channel)
• create and edit webpages
• edit pages in your wikis
• post directly to your wall (as in open your channel page in their browser, find a post editor on top of the channel stream and write a post there that goes directly to you)
• like, dislike and/or comment on your posts (whether someone is allowed to comment on your comments depends on who is allowed to comment in the thread with your comment in it, and commenting on DMs is always allowed)
• send you DMs
• like or dislike any of your entire profiles or any element in any of your profiles
• chat with you (if you have the Chat app installed; Hubzilla only)
• use your channel as a channel source (most likely Hubzilla/(streams)/Forte only)
• administer your channel (sounds scary, but makes sense if your channel is a forum because that's how you add extra moderators)

You can grant these permissions to

• the general online public (only where this makes sense, of course, namely where this doesn't absolutely require a login anywhere in the Fediverse)
• anyone in the Fediverse
• anyone on Hubzilla (not sure if this extends to (streams))
• anyone on the same hub as you (not sure how this behaves on cloned channels, i.e. whether only those on the same hub as your main instance are permitted or also those on the hubs where you keep your clones)
• your connections (including connections pending approval; not sure if it includes those who request to connect to you, for whom you delete the request, and who then only follow you)
• your approved connections
• only those of your approved connections whom you specifically grant that permission by assigned contact role
• only yourself

The next level is permissions per contact. These are granted by so-called "contact roles" which contain the same permissions as the channel, but only with "yes" or "no" as the options because the contact role defines whether a contact is granted a specific permission or not. Permissions granted by the channel are automatically also granted by all contact roles and cannot be revoked, except on a channel level. Each contact is always assigned one contact role.

Lastly, you can grant permissions on a content level. For example, a new post can be public or restricted to

• one of your privacy groups (again, think "lists"; these are an optional, off-by-default app, by the way)
• those whom you have assigned one specific non-default profile to
• one group/forum
• any selection of individual contacts
• only you yourself

At least on servers that understand these permissions, all those who are permitted to see the post are also permitted to see all comments and comment themselves.

That is, optionally (that's an off-by-default app again), you can disallow comments on specific posts altogether.

For viewing files and folders in your file space, there are the permissions mentioned above which control who in general and which contacts specifically are permitted. In addition, you can define access permissions like those for posts to individual folders or files.

All this ties in with OpenWebAuth, a single sign-on system developed for Zap, a now defunct fork (of a fork?) of Hubzilla, in 2018/2019 and backported to Hubzilla in 2019 or 2020. Friendica has client-side OpenWebAuth support, i.e. Friendica's logins are recognised by OpenWebAuth. Hubzilla has full support, i.e. not only are its logins recognised, but it recognises logins itself.

Speaking of the file space: It can be connected via WebDAV. As if that isn't enough, Hubzilla has two calendar systems. One is Friendica's federated event calendar. One is a CalDAV calendar server that shares the same frontend. And, as another optional app, Hubzilla even offers a CardDAV addressbook server.

As indicated above, Hubzilla has even more to offer:

• (optionally) articles, i.e. long-form, non-federating posts; this can be used for blogging without sending the posts themselves through the Fediverse; same viewing and commenting permissions per article as per post; can be formatted with Hubzilla's extended BBcode
• (optionally) planning cards, basically articles with some extra features; can be formatted with Hubzilla's extended BBcode
• (optionally) wikis, multiple ones per channel with multiple pages each; can be formatted with Hubzilla's extended BBcode or Markdown, but one markup language must be defined for the whole wiki; can be collaborated on
• (optionall) static webpages; can be formatted with Hubzilla's extended BBcode, Markdown or plain HTML; can be collaborated on

As for external federation, Hubzilla is second only to Friendica itself. It does not have Bluesky integration or a WordPress cross-poster, and OStatus support was removed years ago with the release of Hubzilla 6.

How fast it is depends not so much on the software (Hubzilla requires fewer server resources per channel than Mastodon does per account, though) as it does on the underlying server (hardware, configuration, MySQL/MariaDB vs PostgreSQL etc.). Still, the Zot code from 2012 (and what evolved from it) seems to be more optimised than the DFRN code from 2010, so that Hubzilla may actually be quicker than even Friendica.

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