Babfree: the research, architecture, and first implementation plan
Babfree is a planned social network made up of independently operated communities. A neighborhood, city, makerspace or club would run its own space for discussions, local news and events. People would use one identity across the communities they belong to, while each community controls its data, membership and moderation.
I want joining and participating to feel like using an ordinary website. Members should be able to find their communities, follow conversations and see what is happening nearby without learning how servers connect. Operators should have a choice of managed hosting or running the software themselves.
The technical direction is a small TypeScript application built on established open-source libraries. Existing forums and social networks offer useful components and examples, but Babfree needs a foundation organized around communities and their relationships. Here is what that means for the software and the first release.
A community owns its space
Think of a traditional forum with its own members, moderators, categories and rules. Now connect it to other forums so people can participate across them with one identity. The community’s server holds its posts, events and membership records, and decides who can access them.
A community can publish information for everyone, restrict it to its own members, or share it with members of specific trusted communities. A neighborhood might make its cleanup schedule public, keep internal discussions for neighborhood members, and open a workshop discussion to members of a nearby makerspace.
Those relationships are explicit and directional. Accepting makerspace members into one neighborhood discussion does not give neighborhood members access to the makerspace. It also does not admit everyone from every group the makerspace trusts. Reading and contributing can have different permissions.
A person may belong to hundreds of communities. Their identity should remain stable when they change their name, recover an account or move to another host. That continuity must preserve memberships and active moderation decisions without making their complete membership list or contact information public.
Accounts and sign-in
Babfree will be the default home for accounts and the main place people access their communities. Members can sign in at babfree.com for a combined dashboard or visit a community directly and choose “Continue with Babfree.” After sign-in, the community maintains its own session and applies its own membership rules.
Each community decides which identity providers it accepts. An identity provider is the server responsible for authenticating an account. The default configuration accepts Babfree accounts. Independent communities can also host local accounts or accept accounts from other explicitly trusted servers, forming their own networks. Babfree itself will accept only Babfree-issued identities.
Identity trust is directional and does not extend automatically through other servers. A club could accept accounts issued by a makerspace without accepting accounts from every server the makerspace trusts. Recognizing an identity establishes who someone is; it does not grant membership or access to private content. Identity-provider trust, membership-based access and acceptance of moderation decisions are separate choices.
A community can accept Babfree accounts alongside accounts from other providers. Its decision to accept additional providers does not prevent Babfree members from participating there.
Locally hosted accounts let members sign in to a community while it is disconnected from the internet. Signing in through Babfree requires connectivity to Babfree. Existing community sessions can remain usable until they expire, subject to local permissions. Remote membership and moderation changes reach a disconnected community when connectivity returns.
Membership and accountability
Joining starts with an in-person introduction. An existing member generates a short-lived, single-use code, the newcomer enters or scans it, and the sponsor confirms the exchange. Communities need accessible ways for people to meet a sponsor, including people who cannot attend a regular gathering.
Sponsorship carries responsibility. Communities can limit invitation privileges, and deliberately helping someone evade a ban can itself lead to enforcement.
Communities can also agree to honor one another’s suspensions and bans. Accepting enforcement is the default when establishing a link, with explicit exceptions available. Permission to read content, permission to share content and acceptance of moderation decisions remain separate settings.
A shared suspension retains its original issuer, scope, reason and expiration. Appeals, reversals and expirations must reach every community honoring it, including communities that were temporarily offline. A receiving community must preserve the original decision’s identity so it does not circulate as a new, independently issued ban.
Hosting that communities can choose
Babfree should run directly on Cloudflare Workers and independently on a Raspberry Pi. Workers provides a managed environment for running application code. A Pi offers a small computer that a community can operate itself, with its own database, files and background jobs.
Supporting both means keeping the community rules separate from the hosting services. The same membership and permission logic should work in either installation. Storage and background delivery can use different implementations underneath it.
This also shapes the performance goals. A small community should not need an elaborate server setup, and a person belonging to many groups should still have a responsive interface. The prototype will measure ordinary tasks such as loading discussions, uploading attachments and receiving updates across communities on both hosting options.
What existing software provides
Established forums
Discourse already provides discussions, moderation, category permissions and a large plugin ecosystem. It is built with Ruby on Rails, a JavaScript frontend, PostgreSQL and Redis, under GPL v2 or later. It would save considerable product work for a conventional server deployment, but its server architecture does not fit direct deployment to Workers. Discourse
NodeBB provides an established JavaScript forum with federation features. Hubzilla offers relevant approaches to remote authentication and permissions. PieFed and Lemmy organize federated discussion around communities. These are useful examples for forum structure, administration and participation across servers. Babfree’s combination of community trust and two hosting environments still calls for its own application design. NodeBB, Hubzilla, PieFed, Lemmy
Matrix focuses on federated rooms and communication. Its room architecture would introduce a substantial additional system for the first release, which centers on durable discussions, news and events. Community-wide chat can follow later. Matrix
Social networking protocols
A federation protocol describes how independently operated servers exchange information. Adopting one can save work on communication while leaving the application responsible for its own permissions and behavior.
Bluesky uses AT Protocol, which provides identity, signed data repositories and synchronization between services. Its personal data server model starts with repositories belonging to individual actors. Babfree’s discussions instead belong to the community hosting them. Adapting that ownership model would add substantial work, and compatibility with Bluesky clients is not a project requirement. AT Protocol
ActivityPub is the federation standard used by Mastodon and other applications. It is a candidate for exchanging public posts and events without adopting Mastodon’s entire server or interface. Babfree would still define how communities recognize remote memberships, authorize private content and exchange moderation decisions. ActivityPub
CForum
CForum is a compact public forum built with TypeScript Workers, React, Cloudflare’s D1 database and R2 file storage. It includes categories, posts, threaded comments, likes and administrative screens. That makes it a useful reference for a simple forum interface. CForum
Its authentication and file delivery would need substantial changes for Babfree. The password implementation uses a fast, unsalted hash, and uploaded files are served publicly. Babfree needs established password protection and permission checks that cover attachments as well as their containing posts. Community membership, trusted access and federation would also need to be added. I would use CForum for interface ideas rather than adopt its backend. Authentication and file-serving code
SiliconBeest
SiliconBeest is a more extensive social server that supports Mastodon-compatible applications. It uses TypeScript, Hono for handling web requests, Fedify for federation, and Nuxt/Vue for its interface. It includes authentication, notifications, moderation, sponsor-linked invitations, registration approval and scheduled advertisements. The invitation and advertisement workflows are particularly relevant to Babfree. SiliconBeest
Its permissions revolve around authors and followers. A private post can be available to people who follow its author or are mentioned in it. Babfree needs access based on membership in the community owning the post, including membership accepted from another community. SiliconBeest also serves uploaded media publicly, so private community attachments would require a different delivery system. Permission rules, media delivery
Cloudflare services run throughout SiliconBeest’s backend. Supporting a standalone Pi would mean adapting database access, file storage, queues and other background work alongside the changes to its community model. Extracting large pieces would bring those dependencies with them.
SiliconBeest will therefore be a reference for invitations, moderation, federation delivery and operator tools. Small, self-contained components may be worth reusing, but building the application around its existing services would create a large conversion project.
Both SiliconBeest and CForum contain AGPL v3 license files. CForum’s README also claims MIT, so its licensing information needs clarification before treating any of its code as permissively licensed. SiliconBeest license, CForum license
The application I plan to build
Babfree’s own code will define communities, memberships, sponsorship, trusted access, moderation records, discussions and events. Maintained libraries will handle common infrastructure such as web requests, authentication, passkeys and cryptography. The account integration will support Babfree sign-in, community-local sessions, configurable identity-provider trust and optional locally hosted accounts.
Hono is the candidate web framework. Fedify is the candidate library if ActivityPub is selected for federation. Using those libraries directly allows the application to organize its data and permissions around communities from the start. Hono, Fedify
Cloudflare installations can use D1 for structured data, R2 for files and managed services for background delivery. Standalone installations can use local SQLite, local file storage and durable background jobs. These will sit behind explicit interfaces so the community logic does not depend on a particular host.
The owning community must authorize every request for restricted content, including attachments. When someone leaves a community or a trust relationship ends, that change must remove access within a defined period. Servers also need a way to catch up after missed updates without allowing an old cached membership to grant indefinite access.
For people in many communities, the interface will load a paginated activity feed and retrieve discussions as needed. It should not require a live connection to every group. Private activity must respect the same access rules as the underlying posts. A clear community switcher, unread state and manageable notifications are part of making the network usable at that scale.
The first implementation milestones
1. Two communities with working private access
The first prototype will connect two independently operated communities, one on Workers and one on a Pi. The same Babfree account will sign in to both, with each community maintaining its own session and membership. A locally issued account will be accepted only by communities that explicitly trust its issuer. Each community will support public posts, members-only posts and posts shared through an explicit membership-trust relationship.
The key demonstration is a private post with an attachment: an authorized member can open both, an unauthorized visitor can open neither, and removing membership or trust removes access. Delayed messages and temporarily offline servers must produce predictable behavior.
2. Invitations and shared accountability
The next milestone adds the in-person code exchange and sponsor confirmation. It also adds suspensions with identifiable issuers, expiration and reversal, and demonstrates that accepting communities honor the same decision without creating loops.
Account recovery and moving hosts must preserve identity and active obligations. Before inviting a real community, the project also needs clear rules for establishing its first operators, resolving duplicate accounts and handling appeals.
3. A useful community website
The first member-facing release will include configurable discussion categories, posts and replies, announcements, local news and an event calendar. Members can contribute, while communities can recognize official sources within a defined scope. A library’s verified event listing should be distinguishable from a member’s suggestion or a paid business placement.
Shared events will retain their original source so changes and cancellations can update wherever the event appears. The interface will include accessible mobile flows, community switching, notification controls and practical moderation tools.
There will be no bot members, manufactured engagement, direct messages or private messaging subgroups. Community-wide chat, richer profiles, friends feeds and permission-based contact sharing can follow once the core community experience works.
4. A local pilot
The pilot will start with a small set of communities and committed operators: a city, a few neighborhoods and local interest groups. Recognizable sources such as libraries and venues can help make the calendar and announcements useful from the beginning.
Local businesses will be able to buy clearly labeled placements from the local operator. Operators will need a way to set prices, accept payments and explain which businesses qualify. Revenue belongs to the operator maintaining that community.
Preparing for the pilot includes installation, upgrades, backups, restore, export and real-device performance. The aim is to make operating a community practical for an organizer, with everyday tasks documented and recoverable.
The first engineering milestone is the connection between two communities: shared identity, explicit trust, private content and reliable revocation. Once those relationships work, the forum and publishing features can grow around them.
Follow progress on the Babfree project page. The full project proposal describes the community experience and operating principles in more detail.