More about groups

Fedibook Groups — How They Work

Groups are at the heart of Fedibook. They are the feature that most clearly separates it from platforms like Mastodon, and the one I have spent the most time getting right. This article explains how groups work — both for users on a Fedibook server and for members joining from other Fediverse platforms.

The basic idea

A group in Fedibook is a shared space with its own feed, its own members, and its own administrator. Think of it like an early Facebook group — a place where a community can have conversations that are separate from the public timeline and separate from individual profiles.

Three types of instances

Understanding how groups work across the Fediverse requires understanding the three distinct roles that servers play.

The Group Server is the Fedibook instance that hosts the group. It owns the group's ActivityPub actor — for example @cycling-grp@fedibook.net — and is the authoritative source for everything about the group: its members, its posts, and its settings. All messages addressed to the group arrive at the Group Server first. It is responsible for validating that the sender is an active member, storing the post, and distributing it to everyone else. The Group Server is the hub that all other instances communicate with.

Group Clients are other Fedibook instances that have members in the group. A Group Client does not host the group — it simply has users who participate in it. When Lars on fedibook.dk joins a group hosted on fedibook.net, then fedibook.dk becomes a Group Client for that group. Group Clients receive all group posts from the Group Server and display them to their local members exactly as if the group were hosted locally. To keep membership lists accurate, the Group Server uses a Fedibook-specific implementation of ActivityPub Collections: it sends Add activities to all Group Clients when a new member is approved, and Remove activities when someone leaves. This means every Group Client has a complete and current picture of who is in the group — which matters for correctly attributing posts and displaying the member list to local users.

ActivityPub Clients are instances running other software — Mastodon, Pixelfed, and similar platforms — whose users participate in the group without their server having any group-specific logic. From the Group Server's perspective, an ActivityPub Client is simply a remote server that follows the group actor and receives Announce activities. Mastodon users who are group members see group posts as boosts in their home timeline. They post to the group by sending a Direct Message to the group's address. The Group Server receives the message, validates the sender's membership, and fans it out to all members. ActivityPub Clients are not part of the Collections sync — they have no concept of group membership lists. Their experience is real but limited.

How a post travels through the system

When a member posts in a group the flow depends on where they are posting from.

A Fedibook user on a Group Client writes a post in the group interface. Their local server forwards it to the Group Server as a Create(Note) activity addressed to the group actor. The Group Server validates membership, stores the post, and fans it out: it sends an Announce to all Group Clients and to all ActivityPub Client followers. Group Clients store the post and display it to their local members. Mastodon users see it as a boost from the group account in their home timeline.

A Mastodon user who is a group member composes a Direct Message addressed to the group actor. The message arrives at the Group Server's inbox. The Group Server checks that the sender has an active membership, strips the group mention from the text, stores the post, and fans it out to everyone via Announce — exactly as it would for a post from a Fedibook member.

In both cases the Group Server is the single point of authority. It decides what gets distributed and to whom.

Membership sync via Collections

One of the challenges of federated groups is keeping membership lists consistent. When a new member joins a group on fedibook.net, how does fedibook.dk know about it?

Fedibook solves this with a purpose-built implementation of ActivityPub Collections. The Group Server maintains a members collection for each group and actively pushes changes to all known Group Clients:

• When a member is approved, the Group Server sends an Add(Person) activity to every Group Client
• When a member leaves or is removed, it sends a Remove(Person) activity
• When a new Group Client joins for the first time — because the first member from that instance just joined — the Group Server sends a full batch of Add activities covering all existing members, so the new Group Client starts with a complete picture

This sync is strictly between Fedibook instances. ActivityPub Clients like Mastodon do not participate and are not affected. Mastodon members appear in the group member list on Fedibook servers, fetched directly from the Group Server on demand, but they are not part of the distributed sync.

Joining from Mastodon

There are two ways a Mastodon user can join a group.

A group admin can send an invitation by entering the Mastodon user's Fediverse address. The Group Server sends a Follow request from the group actor to the Mastodon user. In Mastodon this appears as a follow request from an account. The user accepts, the Group Server activates their membership, and group posts begin arriving in their home timeline as boosts.

Alternatively, a Mastodon user can initiate the process themselves by searching for the group's address — for example @cycling-grp@fedibook.net — directly in Mastodon and clicking Follow. This arrives at the Group Server as an incoming Follow activity and is treated as a join request. For a closed group, the request is queued for admin approval exactly like a join request from a Fedibook user. The Mastodon user is not added as a member until an admin approves. For a hidden group, the Follow is automatically rejected — hidden groups cannot be found or joined without a direct invitation.

Posting back requires sending a Direct Message to the group's address with Direct visibility selected in Mastodon. Public or Unlisted posts mentioning the group are silently rejected — a public post on Mastodon is visible to all of the sender's followers regardless, which is not appropriate for a closed or hidden group.

Group types

Fedibook has two group types: closed and hidden.

A closed group is discoverable. Anyone can search for it, see its name and description, and request to join. An admin reviews the request and decides whether to approve it. The content of the group is only visible to approved members — but the group's existence is public.

A hidden group is not listed anywhere on the Group Server — it does not appear in group listings or search results on the instance itself. However, the group's address is known to those who have been told it, and it is technically possible to search for it directly by address on another platform such as Mastodon. If someone does find the address and sends a Follow or join request, that request does not reach the Group Server. It is silently discarded. The only way to become a member is to be actively invited by a group admin.

There is one special case worth noting for ActivityPub Client users such as Mastodon. If a Mastodon user has already sent a Follow to the hidden group's address — perhaps because an admin shared the address with them out of band — their Follow request sits pending on the Mastodon side. When a group admin subsequently sends them a formal invitation, Fedibook recognises the pending Follow and automatically activates their membership without requiring them to take any further action.

What groups are not

Groups are not chat rooms — there is no real-time messaging or threading. They are not public forums — even a closed group keeps its content strictly within the membership. And they are not permanent public archives — when a group is deleted, all its posts are deleted with it, and remote instances are notified to remove their local copies.

Why not get to learn groups by joining the About Fedibook group @fedibook-grp@fedibook.net - From you Mastodon account or by creating an account on https://fedibook.net. Or even better - bring up your own fedebook server from https://codeberg.org/sindum/fedibook

A note on privacy

Within a single Fedibook instance, group posts are genuinely private — visible only to members, stored in a database the instance operator controls.

Across instances, privacy is more nuanced. When the Group Server delivers a post to a Group Client, that server holds a copy. You are trusting the remote instance operator to handle it responsibly. The same applies to ActivityPub Clients: posts delivered to a Mastodon inbox are stored on the Mastodon server.

This is the nature of federation — data moves between servers, and technical controls have limits. The design minimises unnecessary exposure: group posts are never addressed to the public, membership is always gated, and hidden groups are invisible to outsiders. But the trust model is ultimately the same as email: you trust the servers your messages pass through.

Try groups on the showcase instance at fedibook.net. The source code is at codeberg.org/sindum/fedibook.