# Known Limitations

This page tracks current Potable limitations so integrators can make explicit
tradeoffs.

## Signature Interop Plumbing

Status:

- Potable supports `:ed25519`, `:es256k`, and `:es256` commit signatures.
- Server integration now stores per-repo key algorithm metadata (`key_type`).
- Cross-node federation still depends on external DID/key resolution and trust
  policy integration.

Impact:

- Potable commits are internally consistent and verifiable with algorithm-aware
  verification.
- Federation deployments still need explicit resolver/policy wiring at service
  boundaries.

## Signature Interop Vectors

Status:

- Potable uses compact 64-byte low-S output for ES256K/ES256 signatures and
  defaults to strict compact low-S verification.
- Optional compatibility mode accepts DER/high-S via
  `allow_malleable_sig: true` when needed.
- Additional cross-implementation vector coverage is still recommended as
  upstream implementations evolve.

Impact:

- Runtime behavior is interoperable by design for common ECDSA formats.
- Continuous vector checks remain important to guard future regressions.

## MST Mutation Complexity

`Potable.MST.put/4` and `Potable.MST.delete/3` currently:

- flatten existing pairs
- apply mutation
- rebuild deterministically

Impact:

- simple and predictable behavior
- higher CPU/memory overhead than incremental rebalancing for very large trees

## No Streaming CAR API

Current CAR API operates on full binary payloads in memory.

Impact:

- large repos may incur high memory usage during export/import

## No Networked Identity Resolution

Potable identifier modules (`DID`, `Handle`, etc.) provide parsing/format checks,
but do not perform:

- HTTP DID doc resolution
- DNS/PLC lookups
- trust policy evaluation

Impact:

- host app must implement resolution and policy verification separately

## No Built-In Wire Transport

Potable ships firehose primitives (`EventLog`, cursors, commit envelopes, CAR
packaging), but does not run a `subscribeRepos` transport endpoint itself.

Impact:

- host app must implement websocket or HTTP chunked transport
- host app must enforce auth, filtering, and subscriber backpressure policy

## Record Validation Scope

`Potable.Repository` enforces value-type constraints (including float rejection),
but does not enforce full lexicon schema constraints for each record type.

Impact:

- host app should apply schema validation at API boundaries

## Key Management Is Out Of Scope

`Potable.Signing` offers primitives only:

- generate keypair
- sign
- verify

No built-in support for:

- secure key storage
- key rotation policy
- HSM/KMS integration

## Backend Semantics Depend On Adapter

Potable depends on storage backends for durability and consistency guarantees.
For example, delete/stat behavior can vary by adapter.

Impact:

- production adapters should document and test exact semantics
- verify methods remain the final integrity guard

## Recommended Mitigations

For production integrations:

1. Keep `verify_repo/3` in import/migration safety workflows.
2. Add app-level lexicon/schema validation before `apply_writes/5`.
3. Enforce CAR size limits and I/O timeouts at service boundaries.
4. Benchmark MST operations for expected record volume.
5. Keep key rotation + DID resolver policy explicit in host application design.