Support and maturity
Softchat is pre-1.0 software. Repository-built artifacts are tested as release candidates, but they are not yet promised as stable public-registry releases. Minor versions may refine source APIs; wire compatibility remains governed by the accepted architecture and executable capability catalog.
Tested surfaces
| Surface | Tested contract |
|---|---|
| Rust | Rust 1.97 or newer on targets continuously checked by CI |
| Kotlin/JVM | JVM 17 with the matching host native library |
| Android | API 33 or newer on arm64-v8a and x86_64 |
| Swift | Swift 6.1/Xcode with the package deployment targets |
| JavaScript | Node.js 22 CommonJS and ESM, browser, and dedicated Worker Wasm loaders |
Android ABIs, Apple deployment targets, JavaScript runtimes, and other distribution shapes become supported only after their packed external-consumer test is green and the release names them explicitly. Artifacts from different Softchat revisions must not be mixed.
Compatibility guarantees
- Stable error codes are additive. Include an unknown-code fallback and never branch on display text.
- Unknown Nostr event kinds remain representable. A capability-specific reader rejects unsupported shapes at its typed boundary.
- Canonical writers change only with an accepted architecture update, fixture updates, cross-language tests, and a changelog entry.
- Compatibility readers are removed only after their documented released-client window expires.
- Platform effects—secure storage, sockets, HTTP, files, durable transactions, background work, notifications, and UI—remain application-owned.
Remaining release gates
The executable capability matrix records implementation, interoperability-evidence, and release status independently. The main cross-cutting gates are:
- physical iOS package validation and archive/dSYM measurements;
- a second production Android device audit beyond the packed-AAR CI device;
- production Room, GRDB, and IndexedDB adapter integration;
- released Android/iOS client and Softrelay round trips;
- package signing, checksums, SBOM, provenance, and registry policy; and
- reversible application cutovers and process-death/migration tests.
The performance-specific calibration queue remains in the performance audit. Performance measurements are descriptive until stable runners and device classes have been calibrated.
Security and maintenance
Report security issues privately to the repository maintainers. Supported releases receive fixes for authentication bypasses, key exposure, memory-safety defects, denial-of-service bounds, and wire-format regressions.
A supported release requires green correctness checks, install tests from packed artifacts, generated API documentation, checksums, dependency review, and the performance evidence required for the affected surface.