Sign In

@mosadd/bridges

Package Overview
Dependencies
Maintainers
1
Versions
10
Alerts
File Explorer

Advanced tools

License
Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@mosadd/bridges - npm Package Compare versions

Comparing version
3.0.0-alpha.4
 to
3.0.0-alpha.5
+4
-4
package.json
{
"name": "@mosadd/bridges",
"version": "3.0.0-alpha.4",
"description": "Bridge modules — reach existing networks (Telegram, Discord, Matrix, Signal, WhatsApp, Slack, iMessage) from mosadd. Derived from Hermes Agent gateway/platforms/ (MIT).",
"homepage": "https://github.com/Hei33enberg/mosADD-OS/tree/main/packages/bridges",
"version": "3.0.0-alpha.5",
"description": "EXPERIMENTAL scaffold (not functional yet) — bridge adapter interfaces (Matrix/Discord/Telegram) intended to reach existing networks from mosadd. Every method currently throws BridgeNotImplementedError until real protocol wiring lands. Not for production. Derived from Hermes Agent gateway/platforms/ (MIT).",
"homepage": "https://github.com/Hei33enberg/mosadd-os/tree/main/packages/bridges",
"repository": {
"type": "git",
"url": "https://github.com/Hei33enberg/mosADD-OS.git",
"url": "https://github.com/Hei33enberg/mosadd-os.git",
"directory": "packages/bridges"

@@ -10,0 +10,0 @@ },

+14
-50
README.md
# @mosadd/bridges
Bridge Provider Pack — let mosadd users reach contacts on existing networks (Matrix, Discord, Telegram, Slack, Signal, WhatsApp, iMessage) **without forcing those contacts to sign up for mosadd**.
> **Experimental scaffold — NOT shipped, not part of the mosadd product surface.**
> This package is an internal interface stub. The adapters throw
> `BridgeNotImplementedError` from every handler — the TypeScript shape is locked,
> no network is wired, and bridges are **not** advertised as a mosadd feature.
> Do not depend on this package. The shipped product is the 6 live `m*` modules in
> [`@mosadd/mcp`](../mcp).
> Phase 1 alpha: TypeScript interface + 3 scaffold adapters (Matrix, Discord, Telegram). Real protocol wiring lands per-bridge in follow-ups to [LINEAR-2168](https://linear.app/ip-ra/issue/LINEAR-2168). Adapters currently throw `BridgeNotImplementedError` from their handlers — the shape is locked, the wires are not.
## What this is
## Why bridges
A uniform `BridgeProvider` interface (`verifyConfig`, `sendMessage`, `listMessages`,
`resolveHandle`) kept here so a future contributor has a stable seam to build against.
Design-adopted from the [Hermes Agent](https://github.com/NousResearch/Hermes-Agent)
(MIT, Nous Research) `gateway/platforms/` pattern — see the project
[NOTICE](../../NOTICE) for attribution.
Every new messenger fights "but all my friends are on WhatsApp/Telegram". mosadd's OS framing turns that into a feature: `add mTELEGRAM` and the user can reach Telegram contacts from a single mosadd MCP call — no fork in their network.
This package is design-adopted from the [Hermes Agent](https://github.com/NousResearch/Hermes-Agent) (MIT, Nous Research) `gateway/platforms/` pattern. See the project [NOTICE](../../NOTICE) for full attribution.
## Shape
```ts
import { getBridge, type BridgeProvider } from "@mosadd/bridges";
const matrix: BridgeProvider = getBridge("matrix");
await matrix.verifyConfig({ homeserver: "...", access_token: "...", user_id: "@bot:..." });
await matrix.sendMessage(config, { to: "!roomId:server", text: "hi from mosadd" });
// every handler currently throws BridgeNotImplementedError
```
`BridgeProvider` is uniform across networks — every bridge implements `verifyConfig`, `sendMessage`, `listMessages`, and `resolveHandle`. Network-specific config shape (token, session, homeserver, …) is validated inside each adapter.
Adding a real provider requires an accepted RFC (see [GOVERNANCE.md](../../GOVERNANCE.md)).
## Bridges in this package
| Bridge | Status | Upstream license | Notes |
|---|---|---|---|
| `MatrixBridge` | scaffold | Apache-2.0 (matrix-bot-sdk planned) | First-class — federation reaches the whole Matrix network with one bot account |
| `DiscordBridge` | scaffold | MIT (discord.js / discord-api-types planned) | Bot token, channel + DM scope |
| `TelegramBridge` | scaffold | MIT (telegraf / gram.js planned) | Two modes — Bot API and MTProto user session |
Coming next (per [LINEAR-2168](https://linear.app/ip-ra/issue/LINEAR-2168)):
- `SlackBridge` — workspace bots (Phase 1 P1)
- `SignalBridge` — linked device, signal-cli-rest-api (Phase 1 P1)
- `WhatsAppBridge` — Business Cloud API (Phase 2, legal review)
- `iMessageBridge` — Mac-only via Blue Bubbles or BlueBubbles-Server (Phase 2, legal review)
## BYOK config
Every bridge takes a network-specific config object — see each adapter's TypeScript types for the exact shape. Adapters validate eagerly: `verifyConfig({})` throws with an actionable error.
Env-var convention (for the MCP server to surface):
| Bridge | Env vars |
|---|---|
| Matrix | `MOSADD_MATRIX_HOMESERVER`, `MOSADD_MATRIX_ACCESS_TOKEN`, `MOSADD_MATRIX_USER_ID` |
| Discord | `MOSADD_DISCORD_TOKEN`, `MOSADD_DISCORD_GUILD` (optional) |
| Telegram (bot) | `MOSADD_TELEGRAM_BOT_TOKEN` |
| Telegram (user) | `MOSADD_TELEGRAM_API_ID`, `MOSADD_TELEGRAM_API_HASH`, `MOSADD_TELEGRAM_SESSION` |
## Contributing a new bridge
1. Open a [module proposal issue](https://github.com/Hei33enberg/mosadd-os/issues/new?template=module_proposal.yml) with the network name and your rationale.
2. After RFC accepts (see [governance](../../GOVERNANCE.md)), implement the `BridgeProvider` interface in `packages/bridges/src/<network>/index.ts`.
3. Add the bridge to the `bridges` registry in `packages/bridges/src/index.ts`.
4. Wire it into the MCP server with a tool surface in `packages/mcp/src/tools/<network>.ts` (see how `mIRC` does it — straight pattern to copy).
5. Add a SKILL for Claude users in `skills/<network>/SKILL.md`.
## License
Apache-2.0. See [LICENSE](../../LICENSE) and [NOTICE](../../NOTICE).