Background
We started developing RustChat because the self-hosted team communication space had relatively few modern alternatives to Slack, with Mattermost being the main established option.
RustChat currently provides a Rust backend and web client with channels, threads, direct messages, file sharing, calls, push notifications, OIDC, role-based access control, Mattermost-compatible client APIs, AI agents, RAG, and S3-compatible storage.
After evaluating Buzz, we believe its event-oriented architecture, signed identities, agent model, workflows, Git integration, and human-agent collaboration model provide a very promising long-term foundation.
Rather than continuing to develop a competing messaging core—or maintaining a heavily modified Buzz fork—we would prefer to explore building integrations and a downstream distribution around upstream Buzz.
Proposal
Would the maintainers be open to defining stable extension points for capabilities that operators and downstream projects may need to integrate without modifying the core relay extensively?
Possible extension areas include:
- identity and account provisioning;
- OIDC and enterprise identity mapping;
- notification providers;
- message auditing for enterprise purposes;
- permission structures—for example, in a school environment, preventing a parent from sending direct messages to students;
- structured onboarding and automatic channel membership;
- extending existing huddle capabilities with optional external voice/video or SFU providers;
- object-storage deployment profiles, including RustFS as an Apache-2.0 Rust-based S3-compatible backend;
- search and knowledge providers;
- MCP tools and agent lifecycle integrations;
- administration integrations;
- external audit and retention services;
- optional frontend or administration extension surfaces.
The goal would not be to introduce a large plugin framework immediately. A smaller collection of stable interfaces, event contracts, hooks, and external-service APIs could provide most of the necessary value.
Concrete use case
Our intended deployment would combine:
- Buzz as the collaboration, event, workflow, and agent foundation;
- RustShare as a durable document and company-memory layer;
- RustFS as the S3-compatible object-storage backend;
- Keycloak or another OIDC provider for organizational identity;
- an external media service for scalable voice/video calls;
- permission-aware company RAG exposed through MCP tools;
- Kubedo deployment, migration, administration, and managed-operation tooling.
Most of these components could remain external services. We would like to avoid modifying Buzz’s core messaging model or maintaining a permanently divergent fork.
Initial contributions we could make
We would be interested in contributing work incrementally, potentially starting with:
- A tested RustFS deployment profile and documentation.
- A RustShare MCP connector for permission-aware document retrieval.
- An architecture proposal for OIDC-to-Buzz identity enrollment and recovery.
- An external media/SFU provider boundary for huddles.
- A notification-provider interface that can support self-hosted push infrastructure.
- Documentation for downstream distributions and external integrations.
Each item would be proposed and reviewed separately before implementation.
Non-goals
This proposal is not intended to:
- replace Buzz’s signed-event architecture;
- add the complete Mattermost API to Buzz;
- move RustChat-specific product code into the Buzz core;
- require maintainers to support a Kubedo-specific distribution;
- create a private or proprietary fork;
- introduce a large plugin marketplace before the necessary boundaries are understood.
Questions
- Does this downstream-distribution model align with the intended direction of Buzz?
- Which extension boundaries would maintainers prefer to keep inside the relay, and which should remain external services?
- Is the existing combination of Nostr events, REST APIs, MCP tools, persona packs, and workflows considered the intended integration surface?
- Would maintainers be open to an RFC for identity-provider and external-media interfaces?
- Is there an existing roadmap or design discussion that this proposal should build upon?
We are happy to contribute code, tests, documentation, and deployment validation rather than only requesting the features.
Background
We started developing RustChat because the self-hosted team communication space had relatively few modern alternatives to Slack, with Mattermost being the main established option.
RustChat currently provides a Rust backend and web client with channels, threads, direct messages, file sharing, calls, push notifications, OIDC, role-based access control, Mattermost-compatible client APIs, AI agents, RAG, and S3-compatible storage.
After evaluating Buzz, we believe its event-oriented architecture, signed identities, agent model, workflows, Git integration, and human-agent collaboration model provide a very promising long-term foundation.
Rather than continuing to develop a competing messaging core—or maintaining a heavily modified Buzz fork—we would prefer to explore building integrations and a downstream distribution around upstream Buzz.
Proposal
Would the maintainers be open to defining stable extension points for capabilities that operators and downstream projects may need to integrate without modifying the core relay extensively?
Possible extension areas include:
The goal would not be to introduce a large plugin framework immediately. A smaller collection of stable interfaces, event contracts, hooks, and external-service APIs could provide most of the necessary value.
Concrete use case
Our intended deployment would combine:
Most of these components could remain external services. We would like to avoid modifying Buzz’s core messaging model or maintaining a permanently divergent fork.
Initial contributions we could make
We would be interested in contributing work incrementally, potentially starting with:
Each item would be proposed and reviewed separately before implementation.
Non-goals
This proposal is not intended to:
Questions
We are happy to contribute code, tests, documentation, and deployment validation rather than only requesting the features.