kcode-telegram-native-media 0.1.0

Telegram native-media classification, metadata fallbacks, and native send-method selection
Documentation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Direct dependency audit for 0.1.0

This crate classifies Telegram message media and sends caller-supplied bytes through a caller-supplied Teloxide bot client. Its production dependencies are exact-pinned so compatible-range resolution cannot silently change this media and credential-adjacent boundary.

The production validation set is:

- kcode-telegram-request-policy 0.1.0;
- teloxide 0.17.0 with default features disabled and rustls, rustls-native-roots, and tracing enabled.

Teloxide and its HTTP stack receive the supplied bot client, chat identifier, media bytes, filename, caption, and reply parameters used for native Telegram sends. The crate neither constructs nor stores a bot token. `kcode-telegram-request-policy` receives operation closures and Telegram request errors and owns the existing five-total-attempt finite retry behavior and safe retry diagnostics; it owns no client, token, media classification, persistence, identity, session, group, or transport state.

Axum 0.8.9, serde_json 1.0.151, and Tokio 1.53.1 are development-only dependencies for provider fixture decoding and local Telegram Bot API mock-server tests. They do not add a production listener or runtime boundary.

Exact pins are change control, not proof of safety. Any dependency version or feature change requires a fresh source, license, and security review plus the complete managed validation workflow. Cargo's lockfile is not a downstream security boundary for a published library because consumers resolve their own transitive graph. Exact direct requirements are therefore the durable package constraint; each release validation must also inspect the complete resolved graph selected by Cargo.