A community platform is software that lets a group talk, share and organise in one place. Its reach depends on the protocols underneath: open ones such as ActivityPub, Matrix and AT Protocol let separate servers interoperate, while closed ones keep members inside one product.
This hub maps those protocols and the tools built on them. The detailed explainers branch out from it, starting with the open source community platform overview for readers who want to compare software.
What a community platform actually does
Strip away branding and a community platform performs a short list of jobs. It holds identities, so people can be recognised from one visit to the next. It stores conversations in a durable form, whether as threads, chat rooms or feeds. It applies rules, which means moderation, permissions and bans. Finally, it connects the group to the wider internet through notifications, search and links.
The architecture behind those jobs varies widely. A single-site forum keeps everything on one database. A federated system splits the work across many independently run servers that exchange messages by agreed rules. Those rules are the protocols, and they decide whether a member of one server can follow, message or reply to a member of another.
That distinction matters because it determines who holds power over a community. On a centralised service, the operator controls the rules, the data and the continued existence of the space. On a federated one, a group can pick its own host, move to another, and still talk to people elsewhere. Neither model is automatically better. Federation trades simplicity for portability, and it asks community operators to take on moderation and upkeep that a hosted product would otherwise absorb.
Readers who want the wider landscape of tools built on these ideas can start with the guide to the open source social network category, which covers the software side in more depth than this hub does.
Three protocol families, three design philosophies
Three open protocols dominate modern discussion of decentralised community software, and they were designed for different jobs. ActivityPub models social activity such as following, liking and replying. Matrix models shared rooms with synchronised history. AT Protocol models portable accounts and repositories of signed data. Each can power a community, but each pushes the community toward a different shape.
| Protocol | Core unit | Main transport | Typical community shape |
|---|---|---|---|
| ActivityPub | Actor with inbox and outbox | HTTP POST between servers | Feeds, forums, link aggregators |
| Matrix | Room of synchronised events | Signed JSON over HTTPS | Chat rooms, spaces, bridged channels |
| AT Protocol | Account repository with a permanent DID | HTTP and WebSockets | Large public feeds, custom algorithms |
Table basis: the transport and core-unit details come from the Matrix specification and the AT Protocol overview, alongside the ActivityPub project documentation.
The table simplifies. Software authors regularly stretch each protocol beyond its first use, and chat, forums and feeds increasingly overlap. Still, the core unit tends to predict what a platform does well. A protocol built around an actor and an inbox suits following people. One built around a shared room suits sustained group conversation.
ActivityPub: the protocol behind most of the fediverse
The project site describes ActivityPub as a decentralized social networking protocol based on the ActivityStreams 2.0 data format. The same page calls it an official W3C recommended standard published by the W3C Social Web Working Group. According to the encyclopedia entry, the standard was first published as a W3C Recommendation in January 2018, and further development later moved to a community group.
The specification defines two interfaces. A client-to-server API handles creating, updating and deleting content, and a federated server-to-server API handles delivering notifications and subscribing to content. Most users never see either layer. They meet it as the ability to follow an account on a different server and see its posts appear in their own timeline.
Actors, inboxes and outboxes
The data model is compact. Every actor has an inbox and an outbox, which receive and send activities for that user. To publish something, such as liking an article, a user creates an activity and places it in the outbox. The server then delivers it by a POST request to the inboxes named in the activity’s addressing fields. That is the whole federation mechanism in outline: a message addressed to people, delivered to the servers where those people have inboxes.
The full explainer on activitypub walks through the objects, addressing and delivery in more detail, including where real implementations diverge from the written specification.
Why ActivityPub defines the fediverse
The encyclopedia entry calls ActivityPub the defining standard of the Fediverse, a decentralised social network made of independently managed instances. The shared protocol is what lets microblogging, link aggregation, video and blogging software exchange content, even though the applications look quite different. The broader picture of those networks sits in the guide to the fediverse.
The protocol has limits that community builders should know about. The specification leaves a lot to implementers, so two ActivityPub servers can both be compliant and still handle replies, quotes or private groups differently. The project’s own documentation points developers to companion reading on ActivityPub and WebFinger, ActivityPub and HTTP Signatures, and data portability, which signals that the base specification alone does not cover everything a working stack needs.
WebFinger: finding people across servers
Federation raises a practical question: given only a handle such as a username at a domain, how does a server find the matching account? WebFinger answers it. RFC 7033 states that the specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. The document is dated September 2013 and is an Internet Standards Track document.
A client asks the server at the handle’s domain for a well-known path, passing the account as a resource parameter in an acct: form. The RFC’s own example is a request to /.well-known/webfinger with a resource of acct:[email protected]. The server replies with a JSON Resource Descriptor, a JSON object listing links for that subject. The sample response in the RFC carries the header Access-Control-Allow-Origin: * and the content type application/jrd+json, so that browser-based apps can read it. This design keeps discovery simple: any site that can serve a small JSON file at a fixed address can make its accounts findable, with no central directory involved.
The RFC also defines an optional “rel” parameter. A client that cares about one kind of link, such as an OpenID Connect issuer in the RFC’s example, can filter the response instead of receiving every link the server knows. In fediverse software, the link a server most wants is the one pointing at the actor document that ActivityPub then uses.
The dedicated webfinger page covers the request flow, common failure modes and how to test a handle by hand.
Matrix: rooms that synchronise across servers
Matrix takes a different approach. Instead of following accounts, users join rooms, and a room is replicated on every server that has a participant in it. The official concepts page describes a case where the clients are all participating in the same Matrix room, which is synchronised across the three participating servers.
The same page walks through a message. A user sends a JSON message to a room on their own homeserver. That server adds it to its graph of history, then sends the signed JSON over HTTPS to the other servers in the room. Destination clients receive the message through a long-lived GET request to a sync endpoint. Because every server holds a copy of the room history, no single server is the room’s owner in the way a forum host owns a thread.
The specification and its goals
The Matrix specification states the aim plainly: an open decentralised pubsub layer for the internet for securely persisting and publishing/subscribing JSON objects. It lists the principles as fully open federation, where anyone should be able to participate, and a fully open standard, publicly documented with no IP or patent licensing encumbrances. The specification page checked for this article was labelled version v1.19.
The specification is split into parts: the Client-Server API, Server-Server API, Application Service API, Identity Service API, Push Gateway API, room versions, and the Olm and Megolm encryption material. The Application Service API is what lets bridges connect Matrix rooms to other chat networks, which is a major reason communities adopt it. A group can keep members on an older chat tool while moving its main space onto open infrastructure.
The matrix chat guide covers clients, hosting choices and moderation tools for running a room. Readers weighing it against a mainstream product can read the comparison of matrix vs discord, which sets out the trade-offs in features, cost of operation and control.
AT Protocol: portable accounts and shared schemas
AT Protocol, the basis of the Bluesky network, begins from identity rather than from servers or rooms. Its overview states that users have permanent decentralized identifiers (DIDs) for their accounts, plus a configurable domain name that acts as a human-readable handle. Because the DID never changes, a user can change the handle, or the server that stores their data, without losing followers or history.
Repository data is synchronised between servers over standard web technologies, specifically HTTP and WebSockets. The overview names three core services in the network: Personal Data Servers, Relays and App Views. A Personal Data Server hosts a user’s repository. Relays aggregate data from many of those servers into a stream. App Views build the feeds and interfaces that people read. Splitting those roles lets different operators run different layers.
A global schema network called Lexicon unifies the names and behaviours of calls across servers. Servers implement lexicons to support feature sets, including the core com.atproto.* lexicons for syncing user repositories and the app.bsky.* lexicons for basic social behaviour. For a community builder, this means a new kind of application can define its own lexicon and still reuse the identity and storage layers.
The practical contrast with ActivityPub lies in where the weight sits. ActivityPub puts identity on the home server, so moving an account is a migration task. AT Protocol puts identity in a DID, so moving is closer to a configuration change. The full side-by-side treatment appears in the comparison of activitypub vs atproto.
Older standards that community platforms still lean on
New federation protocols did not replace the standards underneath them. Email remains the universal fallback for notifications and account recovery. RFC 5321, dated October 2008, specifies the Simple Mail Transfer Protocol and says that it specifies an Internet standards track protocol for the Internet community. Its text covers relaying and mail routing, which is the same store-and-forward federation idea that later social protocols reuse in new forms.
Login is the other long-standing dependency. RFC 6749, from October 2012, describes the OAuth 2.0 framework, which enables a third-party application to obtain limited access to an HTTP service. It defines four grant types: authorization code, implicit, resource owner password credentials and client credentials. Community platforms often use OAuth to let mobile apps and bots act for a member without handing over the member’s password. AT Protocol has its own OAuth profile in its specification list, which shows how the older framework is being adapted to new systems.
Understanding these layers helps when diagnosing problems. A failed follow may be a WebFinger lookup that did not resolve. A missing notification may be an email delivery issue. A bot that cannot post may have the wrong OAuth scope. Each belongs to a different standard and a different fix.
Choosing and running a community platform
Protocol choice should follow the community’s needs, not fashion. A few questions narrow the field quickly:
- Is conversation live or asynchronous? Real-time groups usually fit Matrix rooms. Slower discussion with long threads usually fits forum or feed software built on ActivityPub.
- Does the group need to reach outsiders? If members want to be followed from other servers, a federated protocol matters. A closed team may not need federation at all.
- Who will operate it? Self-hosting gives control but brings updates, backups and abuse handling. A managed host reduces the work but adds a dependency.
- How portable must identities be? Communities that expect to switch hosts should weigh account migration support, which differs sharply between protocols.
- What must be moderated? Federated spaces receive content from servers the operators do not control, so blocklists and per-server rules need planning.
Running the software yourself is a distinct decision from choosing a protocol. The guide to a self-hosted community covers hardware, backups, updates and the moderation load that falls on operators.
Operational habits matter as much as protocol. Communities that last tend to write down their moderation policy before the first dispute, name more than one administrator so access never depends on a single person, and schedule backups and software updates rather than leaving them to memory. They also tell members plainly which data is public. On federated systems a post may be copied to servers the operator does not run, and deleting it locally does not always remove every copy. Setting that expectation early avoids hard conversations later.
Growth brings its own questions. A small group can moderate by conversation, but a larger one needs reporting tools, rate limits and a clear escalation path. Federated communities add a further layer: deciding which other servers to trust, limit or block. Matrix operators manage room permissions and server access, ActivityPub operators manage instance-level blocks, and AT Protocol communities rely on labelling and shared moderation services. Reading how each handles abuse before choosing is worth the time, because moderation is the work that never ends.
Before committing, test the exit path. Export a sample of data, try moving an account, and confirm that members can leave with their content. A platform that is open in name but hard to leave offers less than its protocol suggests. The same goes for bridges: they are valuable for migration, but a bridged room depends on the bridge staying maintained.
This site is independent and non-commercial. It is not affiliated with, endorsed by or sponsored by any project, platform or company it covers, including the former Barnraiser project, and it sells no hosting or software and carries no affiliate links or paid placements.
Frequently asked questions
What is a community platform?
A community platform is software that gives a group identities, a place to hold conversations, moderation tools and links to the wider web. It may be a forum, a chat system or a federated social server.
Do all these protocols work together?
No. ActivityPub, Matrix and AT Protocol are separate standards with different data models. Bridges and gateways can connect some of them, but the connections are partial and depend on the maintainers of each bridge.
Which protocol is a standard from a recognised body?
ActivityPub is a W3C Recommendation, published in January 2018 according to its encyclopedia entry. WebFinger, SMTP and OAuth 2.0 are IETF documents: RFC 7033 from September 2013, RFC 5321 from October 2008 and RFC 6749 from October 2012.
Does a community need federation?
Not necessarily. Federation helps groups that want to reach people on other servers or keep the freedom to change hosts. A small private team may be better served by a single well-run server.
