Sapphire IPC: protocol and multi-language SDKs for external developers

Goal

Build a stable, versioned and secure Sapphire I.C.D.S. IPC contour that allows external developers to create modules, services and integrations without access to the closed C++ core.

The first SDK line targets C, C++, Go, Rust and Zig. The contract architecture must allow additional languages without changing the base protocol.

Development stages

1. Protocol contract and model. Connection lifecycle, handshake, version negotiation, request/response, events, correlation IDs, timeouts, cancellation, error model and compatibility rules.
2. Transport and framing. Local transport, binary or structured framing, message-size limits, backpressure and recovery after connection loss.
3. Security and isolation. Local client authentication, capability and permission scopes, process impersonation protection, input validation, rate limits, audit and safe handling of untrusted payloads.
4. Reference SDKs. A canonical C ABI plus foundational SDKs for C/C++, Go, Rust and Zig with consistent lifecycle, error, cancellation and event behavior.
5. Developer experience. Headers and packages, build integration, module templates, runnable examples, test server/client, diagnostics, logging and step-by-step documentation.
6. Compatibility and hardening. Contract tests across all SDKs, parser/framing fuzzing, reconnect and version-mismatch tests, resource cleanup and validation with persistent FastCGI/runtime processes.

First-release acceptance criteria

• IPC v1 specification and versioning policy are published.
• A Sapphire-side reference implementation exists.
• Official SDKs or bindings work for at least C, C++, Go, Rust and Zig.
• Error codes, lifecycle and cancellation semantics are consistent across SDKs.
• At least one end-to-end external module works without linking to the closed core.
• Examples, contract tests and basic third-party developer documentation are available.
• The protocol does not expose internal ABI or core implementation details.

Later stages

Additional languages, schema-based code generation, optional secure remote transport, registry/capability discovery, package distribution and a public ecosystem documentation portal.

Target date: 2 August 2026.