SHARDWIRE
Advanced

Product boundaries

What Shardwire intentionally is—and adjacent problems you should solve with your own infrastructure instead of expanding the core library.

Shardwire is a split-process Discord bridge: typed events, typed actions, scoped secrets, manifests, strict startup, and diagnostics. It is not a full “Discord platform” or hosted multi-tenant runtime.

This page lists non-goals for core so scope stays sharp as the ecosystem asks for more features.

In scope (core)

  • Bot-side createBotBridge and app-side connectBotBridge over WebSocket (ws loopback, wss remote).
  • Capability negotiation from intents + secret allow lists.
  • Manifests, generateSecretScope, diagnoseShardwireApp, strict startup, workflow helpers on the public API surface.
  • Documentation and recipes for how to compose Shardwire in real systems.

Out of scope (compose externally)

  • Multi-tenant multiplexing of many unrelated bot tokens through one magical bridge process (hosting-scale isolation, billing, routing).
  • Alternative transports inside the library (Redis/RabbitMQ/etc.) as the primary “wire”—use your own queue or bus beside Shardwire when you need cross-datacenter fan-out.
  • Global key/value or cross-shard state — use Redis, a database, or your orchestrator’s primitives.
  • Bundled operator dashboards or long-lived CLIs—optional ecosystem tools may exist, but they are not required to ship core value.
  • Transport-layer policy engines that drop events outside manifest/subscription semantics—keep policy in app or bot code so strict startup and diagnosis stay honest.

Slash commands and REST registration

Discord application command registration (global/guild, autocomplete metadata) is intentionally not hidden magic inside createBotBridge. Prefer:

  1. A documented recipe or small bot-side helper you own, using @discordjs/rest or discord.js builders.
  2. A separate package only if it stays explicit, testable, and small (Slash command sync).

When something feels “missing”

Ask whether the gap is:

  • Contract / capability — likely belongs in Shardwire (docs, diagnosis, or a narrow API).
  • Product / hosting — likely belongs in your deployment (secrets, CI, queues, dashboards).

If you are unsure, start with a recipe before expanding the public API.

Troubleshooting

Work failures from connection and capability negotiation outward; most issues become obvious once you inspect the negotiated surface.

Custom domain contracts (spike)

Architecture notes on app-defined RPC/events alongside Shardwire: why they are not first-class in core today, and what would have to be decided before they could be.

On this page

In scope (core)Out of scope (compose externally)Slash commands and REST registrationWhen something feels “missing”Related