Most online community tools begin by asking a group to enter a platform. Its events, updates, relationships, and attention become material for one shared feed. The platform becomes the place where community life is stored, ranked, and made legible.
Our FED work begins from the opposite direction. A community is already a place: a venue, a town, a neighborhood, a trusted , or a group that has found a reason to work together. Its tools should help it keep that center. Connection outward can be valuable, but it should be a deliberate route—not the cost of having useful software.
The work: a local center with chosen routes.
FED is our shorthand for a family of tools that make community information useful without treating it as a platform-owned social graph. The work has three connected parts:
The : identity, invitations, Circles, trust paths, people and place context, permissioned sharing, and local operations.
A focused public-information layer: local publishers can agree what event information may travel between places without giving up their own calendars or local presence.
A starting posture in which a community’s workspace and records can remain close to its operator, with export and later sharing designed in rather than bolted on.
Offline-first is the first move, not the finish line.
means the local work remains useful when a network is unreliable or absent. More importantly, it changes the ownership relationship: a person or local operator can begin with their own records and tools before asking an outside service to hold them.
The current build sequence is intentionally modest. First, a local workspace with and prototype testing. Then, when a real community needs it, a managed hub with explicit invitations and operator controls. Only after that, an approved public route—for example, selected EventFed updates exchanged through a compatible adapter. Private records do not become public simply because a community has a public presence.
Sharing gets a purpose.
A public event should be easy to publish where it is relevant. A neighboring organization may be a good place for that invitation to travel. A private Circle’s planning notes are something else entirely. FED work is meant to make these different kinds of sharing clear: what is moving, who agreed to it, where it may go, and how that decision can change.
That is a different model from one universal profile or a stream that mixes every role, topic, and relationship together. It makes room for people to be collaborators, hosts, neighbors, organizers, or friends in the context that actually matters—without turning one connection into automatic access to everything else.
This is a working case study, not a victory lap.
HubFed and EventFed are early product directions. We are not claiming a finished federated community system. The next evidence has to come from real, consented use.
- Can a local operator maintain a useful shared context without becoming dependent on a central platform?
- Can public event information move between willing local publishers while each keeps control of its own source and rules?
- Do people understand what is private, what is shared, and why?
- Does the local-first starting point make the work more durable and easier to trust?