Expose per-transport server metadata (relay capabilities) to clients

Chiusa
  • Qualcosa non va?
#8,857 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
api, backend

Direzione di ricerca

Start with ServerMetadata in imap.rs and trace how the scheduler caches per-transport metadata in Context::metadata. Then inspect list_transports and the JSON-RPC wrappers for desktop and wasm clients to map where a read-only API would fit. Done means exposing the listed fields keyed by transport email, preserving the distinction between real TURN entries and fallback STUN, and representing transports without recent metadata as absent.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Feature request: expose per-transport server metadata (relay capabilities) to clients

The IMAP scheduler already fetches per-transport server metadata on every connect and caches it in Context::metadata (ServerMetadata in imap.rs): the /shared/vendor/deltachat/turn TURN credentials for calls, the advertised iroh relay URL, supports_push (any /shared/vendor/deltachat/ entry marks a chatmail relay), max_smtp_rcpt_to, /shared/comment, /shared/admin, and the relay's app_versions. This is the same behavioral signal tools like cmcall rely on to detect call capability (TURN over IMAP METADATA).

None of it reaches clients: list_transports returns only the entered login parameters, and the metadata map is pub(crate). A UI therefore cannot show which of a multi-transport profile's relays supports calls, push notifications, iroh, or how stale that knowledge is — users pick a "sending relay" blind to what it can do.

Proposal

A small read-only API, e.g.:

pub struct TransportServerMetadata {
    pub addr: String,
    pub iroh_relay: Option<String>,
    pub supports_push: bool,
    pub has_turn: bool,          // true only for real TURN entries, not fallback STUN
    pub max_smtp_rcpt_to: Option<u32>,
    pub comment: Option<String>,
    pub admin: Option<String>,
    pub app_versions: Option<String>,
}

impl Context {
    /// Keyed by the transport's email address; transports the scheduler has
    /// not connected to yet are absent.
    pub async fn get_server_metadata(&self) -> Result<BTreeMap<String, TransportServerMetadata>>;
}

plus a JSON-RPC wrapper for the desktop/wasm clients.

Key semantics we found important while prototyping this in a vendored patch:

  • has_turn must distinguish a real /shared/vendor/deltachat/turn entry from the fallback STUN servers the core fabricates when metadata is missing — the fallback is not call support.
  • Keying by transport address (not the numeric transport id) is what client UIs already hold from list_transports.
  • Absence (transport never connected recently) is a meaningful third state clients want to surface as "unknown", distinct from "relay does not offer this".

Our client (Velta) currently ships this as a vendored patch and would happily drop it for an upstream API.

Lingua principale
Rust
Stelle
944
Fork
151
Merge medio
2g 12h
PR unite (30g)
60

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di chatmail/core

Tutte le issue di chatmail/core

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.