Crate tacenta_client 

The high-level Tacenta client.

One Client wraps everything a caller would otherwise orchestrate by hand — an identity and its provider session store, a directory connection, an authenticated relay connection, and per-peer sessions — behind connect, send, and receive (or inbound, the same one message at a time). This is the surface the platform bindings (UniFFI / wasm) export.

An app starts one layer up, at the tenant handle (decision record 0090): Tacenta::connect takes an API key and a server name, fetches the server’s service document, and hands out signed-in clients through Tacenta::sign_up and Tacenta::sign_in, so no app carries a host or a port. The Config-based constructors below are the layer under that: explicit addresses, for a test or a deployment that already knows them.

use tacenta_client::Tacenta;
let tenant = Tacenta::connect("tct_your_api_key").await?;
tenant.sign_up("alice", "correct horse").await?;
let mut alice = tenant.sign_in("alice", "correct horse").await?;
let to_bob = alice.find("bob").await?.expect("bob signed up");
alice.send(&to_bob.address, b"hello").await?;

With explicit addresses:

use tacenta_client::{Config, DefaultClient, DeviceAddr};
let mut alice = DefaultClient::connect(&Config {
    directory: "127.0.0.1:4720".parse().unwrap(),
    relay: "127.0.0.1:4721".parse().unwrap(),
    user: "+alice".into(),
    device: 1,
})
.await?;
alice.send(&DeviceAddr::new("+bob", 1), b"hello").await?;
for message in alice.receive().await? {
    println!("from {}: {:?}", message.from.user, message.plaintext);
}

Structs

AccountConfig

Where to reach a server’s account endpoints, plus the credentials to sign in with. Used by the account flow (Client::sign_in) — sign in, then provision this device under the account’s handle — in contrast to Config, which registers a device directly under a raw handle (the pre-account path).

Client

A connected client: an identity, a directory connection, an authenticated relay connection, and the peers it has open sessions with.

ClientTls

A client’s TLS trust: which server certificate(s) to accept. Use ClientTls::trusting to pin a specific self-signed server certificate.

Config

Where to reach a Tacenta server, and who to connect as.

Contact

A resolved contact: another user’s addressable handle. Produced by Client::find.

Contacts

A client-local contact list. It lives on the device and is never sent to the server, so the server never learns a user’s contact graph — the metadata-privacy choice for an end-to-end-encrypted messenger. Serialize with to_bytes to persist it across restarts; a user’s contacts do not sync across their devices without doing that deliberately.

DeviceAddr

A device’s routing address: which user, which of their devices. This is the relay’s own routing key — deliberately not libsignal’s ProtocolAddress, since the relay knows nothing of the crypto layer.

Endpoints

The four services, resolved to socket addresses.

MailSignal

The signal a client pings when mail may be waiting; see Client::mail. Cheap to clone and hold apart from the client.

Received

A decrypted inbound message and the device that sent it.

ServiceDocument

The document itself. The four services are host:port strings, resolved by the reader; server_name is the name the TLS certificate presents, which is the host in every deployment so far but is carried separately so that it need not be.

Tacenta

One tenant’s handle on one server: the API key, where the services are, and how the server is trusted. Cheap to clone; hold one per tenant.

Enums

AccountResponse

The account service’s response.

DirResponse

The directory’s response.

Error

What can go wrong talking to a Tacenta server. Error::kind is the contract an app branches on; the variants carry the detail, including the server’s own reply where there was one, and may grow (the enum is non-exhaustive).

ErrorKind

What an app can branch on: the kind of an Error, the same set on every head (decision 0090, the list before the packages). The message carries the detail; the kind is the contract. Non-exhaustive: a kind may be added, so match with a wildcard arm.

ProvisionOutcome

The outcome of a provisioning attempt.

RelayRefusal

Why the relay refused a send.

RestoreOutcome

What the last sign-in or connect found, read with restore_outcome: whether the sessions a restored state carried are in use, or were discarded because the state was older than one already seen. The same three values on every head.

SecureStoreError

Why a SecureStore could not produce a key.

SessionProvider

Which implementation established the sessions in a state blob.

SignupReason

The coarse, wire-serialisable reason a signup was refused. Mirrors the field-level [SignupError] variants; UnknownTenant is not here because the protocol surfaces it as its own response.

Tls

How a client trusts the server behind the four services.

Constants

MAX_MESSAGE_BYTES

The most bytes one send accepts: the relay’s per-message envelope limit less room for the envelope’s own header and the ciphertext’s overhead. Larger is refused as ErrorKind::InvalidArgument before any ratchet step, on every head.

WELL_KNOWN_PATH

Where a server publishes its document.

Traits

ByteStream

A byte stream a service can be spoken over.

Connector

A caller-supplied way of reaching the four services: given a service name (directory, relay, accounts, provisioning), open a byte stream to it. This is how a host that owns the sockets, the browser above all, lends them to the client: the WebAssembly head implements it with a WebSocket per service opened from JavaScript (decision 0090, step 4). The protocol spoken over the stream is unchanged.

SecureStore

Platform secure storage backing rollback-resistant persisted state (export_state_sealed and its restore siblings): a wrapping key and a monotonic counter, both held where an attacker who can rewrite the state file cannot reach them.

Type Aliases

Connecting

The future a Connector returns.

DefaultClient

The client this build establishes sessions with.

Result

A convenience alias for results from this crate.