Hubzilla KnowledgeDB

Understanding Hubzilla's permission system

Hubzilla has an access authorisation system that may initially seem unmanageable for beginners. However, if you realise a few basic principles, it is ultimately understandable and comprehensible.

Identity = channel

With Hubzilla, you need an account with a hub (Hubzilla instance/Hubzilla server). However, unlike most other Fediverse services, this account is not your own identity. Whereas with Mastodon, for example, your account also creates the Fediverse identity with which you appear in the Fediverse, the Hubzilla account only authorises you to log in to the corresponding hub. If you have registered a new account, you do not yet have a Fediverse identity and cannot participate in the Fediverse.

The Hubzilla identity is called a channel. If you have an account with a hub, you can create such a channel. And with this identity, i.e. the channel, you can then also participate in the Fediverse.

A special feature of Hubzilla is that you can create as many channels as you like. However, you only need one account for this. Different channels can now be used for different purposes. For example, you can set up a ‘classic’ Fediverse identity as a channel, as you would with other services. However, you can also create another channel, for example, which is not as public as the ‘classic’ channel. This can be used, for example, to only interact with certain people. Or you can choose to set up a community forum as a channel. Such a channel behaves in much the same way as a classic forum and offers a kind of community page on which the members (connections to the channel) can exchange information.

The possibilities are manifold. You can create a channel for any purpose and thus an additional identity.

Important: The principle of the whitelist

Hubzilla's authorisation system is based on a kind of whitelist system. In principle, everything is initially forbidden to other people (Fediverse users or even pure Internet users without a Fediverse account).

Permission and access

What is generally referred to as ‘permission’ in this article can be further differentiated: Permission and access system. Access permissions, or access for short, regulate which content other people can access and what they can see, i.e. they relate to the object/content. The permissions regulate what others can do in and with our channel and our content (e.g. comment, repeat, share, like, etc., possibly also edit, modify or even add content) and what they can generally see.

The first level of the permission system: the channel role

When creating a channel, you must select the so-called channel role. You can choose between ‘Public’, ‘Personal’, ‘Community Forum’ and ‘Custom’.

In order to be able to interact with your channel with other people, they must be granted certain permissions (unless you really want to use Hubzilla as a completely private space without any contact to the outside world... that is also possible).

Hubzilla provides three channel roles with a set of specific permissions to choose from when creating a channel:

1. Public: This channel role is in principle the closest to the ‘classic’ social network profile as known from other services. A wide range of interactions is possible.
2. Personal: This channel role is also close to the ‘classic’ social network profile. However, it initially restricts certain personal interactions (they are not on the whitelist, so to speak).
3. Community Forum: This channel role is a special feature. The permissions are very similar to those of the "Personal" channel role. However, the ability to behave like a forum is also activated. This means that members (i.e. connections) of this forum channel can post directly to the ‘wall’ of the forum, which means that such a post ends up in the channel stream and can be seen by all other members (connections), who are also notified about it. In addition to the ‘Personal’ channel role, users are granted the right to view the channel's connections (i.e. the member list).

The fourth selection option is ‘Custom’. Here you can define the permissions for each individual case yourself after creating the channel. However, the settings for the permissions are not found in the channel settings, where you select the channel role, but in the privacy settings. Here there is an additional button ‘Advanced configuration’, which takes you to the editor for the permissions of the channel role. When you open this editor, you are first warned: ‘Proceed with caution - Changing advanced configuration settings can impact your, and your contact channels functionality and security.’

If you decide to accept the ‘risk’, click on the corresponding button and you will finally be taken to the permission settings for the channel.

The warning may scare some people a little. It also sounds almost threatening. But if you have read and understood this article, there is little risk of creating an "unusable" channel. In addition, if the channel does not work as expected, you can change the channel role back to one of the three preset variants at a later date and have a channel that works accordingly. Here are the permissions for the channel roles:

The permissions listed here for the three preset roles cannot be changed.

With the user-defined authorisations, you have the option in the editor to choose between

• Only me
• Only those you spezifically allow
• Approved connections
• Any connections
• Anybody on this website
• Anybody in this network
• Anybody authenticated
• Anybody on the internet

The second level of the permission system: the contact roles

The channel roles apply to everyone who visits our channel. This includes guests without a Fediverse account and users of other Fediverse services (but also Hubzilla users) to whom we are not connected.

And of course they apply to users with whom we are connected.

However, with the second level of the permission system, the contact roles, we now have the option of granting further rights to certain connections.

Please pay attention to the wording here: ‘to grant further rights’!

With the contact roles, we can grant users options that are not granted in the channel role. However, we cannot remove permissions that have been granted by the channel role. The contact roles are also a positive list. Another positive list that supplements and extends the positive list of the channel role if necessary.

There is a ‘standard’ contact role that expands the permissions of the predefined channel roles. This standard role means that the channel actually behaves like a ‘classic’ social network account:

This default role is assigned to all new contacts by default. If we have not configured our channel under Privacy settings so that all contact requests are automatically approved, we can also change the contact role directly when approving the connection (if there are other channel roles). The contact role of each connection can be changed retrospectively.

With the ‘Contact Roles’ app, we can view the permissions of the default contact role (the default role cannot be changed) and create new contact roles of our own.

As already mentioned, the channel role of your own channel has top priority. Each contact role inherits the authorisations specified by the channel role. You cannot revoke these permissions in the contact role; you can only add further permissions.

The inherited permissions are displayed in red in the "Contact Roles" app. The new contact roles created here can now be assigned to new and existing contacts. When creating a contact role, we can also specify that this role is to be assigned to new contacts as the default in future. Of course, this only works for one role.

The third level of the permission system: permission settings (access / access permission)

While the channel role and the contact roles define the basic permissions, the permission settings for individual content offer the option of explicitly defining access. Here we are in the access (access permission) system layer. This system basically determines whether a user can see our content.

The permission settings can be accessed via a button with a padlock symbol in connection with the respective content (posting, files and file folders, appointments, articles, websites, etc.). With these access permissions, in addition to the permissions granted by channel roles and contact roles, you can specify who can see the content.

You have the choice between

• Public
• Only me
• Privacy Groups
• Custom selection

With the customised selection, we have the option of granting each individual contact, user group and guest access permission to view the content.

The settings for the access permissions can be used to override the permissions granted with the channel and contact roles to a certain extent. If you select ‘Public’ for both access authorisations, the rules for the channel and those for contacts remain unaffected and access to the content/object is granted as provided for by these permissions.

If you select ‘Only me’, the permissions assigned for the content/object no longer apply. The content is only made available to the channel owner. They can always see their own content anyway.

If you select a privacy group or individual contacts and groups from the ‘User-defined’ area, the permissions granted for the channel roles and contact roles are no longer taken into account directly, but only for the contacts and/or contact groups to whom we grant access to the object/content. This means that contacts who have been granted certain permissions, i.e. who have been given the ability to see objects/content, for example, can be granted this right for a specific object/content with the access permissions, while all others are denied this right in this individual case. It is important to note that this mechanism cannot be used to grant access permissions if they have not been granted via the channel role or contact role. If, for example, the channel role does not allow users to view the channel's websites and this is also not permitted via a contact role, the contact cannot be allowed to view the website using the permission settings (access).

If you grant users who do not have an account on your own hub, but on a third-party Hubzilla hub, rights to content / objects, they must authenticate themselves on their own hub. It is best to send them the link to the content using the tags [zrl][/zrl] or [zrl=][/zrl], as this automatically authenticates them. For more information, see the article Authentication.

Fediverse users who are using other services in the Fediverse can see posts with the appropriate access permission because these are federated and distributed to the stream/timeline and are therefore visible to the recipient. Other content / objects, such as files or file folders, or even articles, websites etc. are not federated and remain exclusively on the owner's hub. You can now share a link to such content, for example. The recipient then receives the link in their timeline. However, clicking on it then leads to the original hub. However, if the object behind the link is access-restricted, the recipient cannot see it, even if they have been specified as authorised in the access permissions. This only works within the Hubzilla network (grid) because only one Hubzilla channel can log in remotely to the target hub via ‘magic authentication’. This capability is a speciality of the Zot protocol and is not available with ActivityPub. In order to make such content / objects accessible to users of other services or users without any Fediverse account, the guest access mechanism must be used.

Using the permission settings also makes it possible to send direct messages. If we select one or more contacts, a posting will only be distributed to these contacts. The post will also appear in their filter for direct messages. Such posts cannot be forwarded or shared. Comments, i.e. replies to these direct messages, are also only distributed to those contacts who were specified as authorised in the original post.

Individual contacts can also be selected for such direct messages by bypassing the authorisation setting using a private mention (@!<HANDLE>).

Another type of permission system: privacy groups

The ‘Privacy Groups’ app makes it possible to assign contacts to privacy groups. These groups are collections of contacts and are used to filter the stream, but also for simple communication that is restricted to certain contacts.

You can create privacy groups with the app. You assign a name to the group and specify whether the members of the group are visible to other channels, whether posts should be made to this group by default and whether new contacts should be assigned to this group by default.

f we have created such a privacy group and now call it up in the ‘Privacy groups’ app, the above-mentioned settings are displayed again. Below this we find two columns:

• Not in this group All connections that have not been assigned to the group are displayed here
• Group members All connections that have already been assigned to the group are listed here.

By clicking on one of the connections, it is moved to the other column. This means that we can assign contacts to a group and remove contacts from a group.

However, it is also possible to edit a contact in the ‘Connections’ app and assign it to a privacy group there.

Privacy groups fulfil two basic tasks. Firstly, they serve as a filter for the stream. This has nothing to do with ‘’permissions‘’. If you select a specific privacy group in the stream view in the sidebar, only content from the group members will be displayed in the stream.

And then they are also used for group communication in the form of direct messages.

If you select a privacy group in the permission settings when writing a post, the post will only be distributed to the members of the group.

You can also assign a specific contact role to a privacy group in the ‘Contact roles’ app. This means that the corresponding contact role is assigned to all group members. However, the assignment only takes place at that moment. Contacts that are added to the group later do not inherit this assignment, but retain the default contact role.

Another type of permission system: profiles

The channel, i.e. our identity in the Fediverse, has a standard profile. In this profile, we can enter details about ourselves. It is possible to specify a profile photo and a cover picture, a channel name, information about the channel itself and other, sometimes personal, details.

However, we have the option of creating several profiles for one channel... with different information and data. And for each profile, we can specify which contacts it is shown to.

This makes it possible to disclose different information about ourselves to different contacts and thus determine which information each contact receives.

Considerations regarding authorisations - What makes sense? What is not useful?

If you simply want to use Hubzilla as a social media system, like many others, you don't need to worry too much about the permission system. Simply select a sensible channel role (usually ‘Public’) and that's it. Direct messages are handled via tagging or the permission settings... but that's it for the permission system.

If you only want to make content accessible to certain contacts from time to time, you can also do this using the permission settings.

If you want less public interaction, select the ‘Private’ channel role.

However, if you want to specify who is allowed to do and see what in the channel, you should proceed differently and select a very private and therefore restricted channel role. ‘User-defined’ is a good choice here. When making the settings, you should really think about what permissions or restrictions will have in practice and what basic functionality you want. And then only grant the permissions that you really want to grant in each case.

Remember: The permissions in Hubzilla follow the principle of a whitelist. And the channel roles have the highest priority. What is permitted there cannot be prohibited again in the contact role.

It is also important to realise that the channel roles really do apply to everyone(!). This includes guests without a Fediverse account (‘Anyone on the Internet’) and users to whom we have no connection.

These functions can also be used to realise a follow/don't follow functionality.

If we specify in the channel role that people cannot send us posts and cannot comment on our posts, we could, for example, create contact roles that still allow certain contacts to do so. If we receive a connection request but do not want to see any posts from this contact, but still want to allow them to ‘follow’ us, i.e. receive our content in their stream, we create a contact role that still prohibits them from sending posts to our stream and commenting on our posts, but allows them to see our posts and comments. And we create another contact role in which sending posts to our stream and making comments is permitted. We then assign this contact role to all contacts with whom we want to interact in both directions.

We also think about other possible interactions in the same way and create suitable contact roles for them, which we then assign to the corresponding contacts.

This makes it possible to define exactly what we allow and to whom, and we can keep our stream free of unwanted content. The possibilities are really diverse.

If we want to be on the Fediverse for different reasons or with different interests, it makes sense to create several channels for this. However, if we only want to disclose different information to different users, it is sufficient to create several profiles for one channel and assign them accordingly. You should bear in mind that - unless you generally prohibit it with the channel role - everyone on the Internet can see the standard profile. You should only enter the really necessary information here and create profiles with further or other information for friends, colleagues or other contacts.

tl;dr

Hubzilla's permission system is very fine-grained and, due to its multi-layered form, really well suited to determining how you want to interact with whom on the Internet. It may seem confusing at first, but once you have familiarised yourself with the system, it is easy to understand.

The outermost limit for our ‘I’ on Hubzilla is the channel role. It defines what is generally permitted for others in relation to your own channel. These permissions cannot be revoked at lower levels. The permissions defined in the channel role to do or see something apply to everyone, regardless of their status (guest, Fedi user, etc.) when they access our channel. It is therefore important to think about the channel roles for your own channel and to carefully consider what you would like to grant to Internet users who are complete strangers.

The Fediverse thrives on interaction and making connections (i.e. having ‘followers’ or being ‘followed’ on other services). If you have created or selected a fairly restrictive channel role so as not to allow complete strangers too many options, you can now assign further permissions to contacts with the next limit, the contact roles. These add to the permissions specified by the channel role, but cannot revoke the permissions granted by the channel role.

Each channel can have exactly one channel role, but any number of contact roles. This makes it possible to grant different permissions to different contacts.

Regardless of the contact roles, users can also restrict access when creating content (posts, images and files, appointments in the calendar, etc.). The contact role rules still apply, but we can use the access permissions to restrict access to selected contacts for individual content/objects. This is done using the permission settings for the content, which can be used to specify who exactly should have access to the content.

Each channel can also have several profiles. Profiles are used to provide Internet users with information about the channel (including personal information).

If you have selected or created a channel role that allows everyone on the Internet to see the channel profile, you should carefully consider how much information you want to make available in the standard profile that each channel has. You should be ‘economical’ here, but still provide enough information to generate interest in your channel so that Fediverse users may connect to (or ‘follow’) your channel.

In order to display further information to certain contacts, you then create additional profiles with different information and assign these to the corresponding contacts. These contacts can then view the other, extended information. However, information from other profiles remains hidden from them.

You can create privacy groups to filter your own stream for content from certain users and to hide other content, but also to enable communication limited to certain connections. If you select them in the stream view in the filter area, only content from the users in the group will be displayed. If you define such a privacy group as the recipient for a post or the sharing of data (images, websites, articles, etc.) using the permission settings, only the members of this group will see the content.