Naming & UX Direction — Native Rust Telegram Client

Источник: dev/fera/project-design/context/NAMING-UX.md (read-only; сгенерировано scripts/sync-docs.mjs)

Naming & UX Direction — Native Rust Telegram Client

Companion docs: ADR.md, RFC.md, TECHSPEC.md, QA.md, OQ.md (architecture), FUTURE-CHECKS.md (technical “check this later” list — split out separately from this file, don’t mix the two).

1. Naming

Status: main client name decided — Fera.

Fera — the client itself. Short, reads naturally in both EN/RU (“фера”), not tied to the author’s personal anime-adjacent handle (Mitsuki Kagamin), doesn’t read as “just a Telegram clone.” Known namespace conflict: an existing, fairly popular (52M+ downloads) mobile app is also called “fera” — a fintech/prediction app (Interac e-Transfer, lottery/jackpot number prediction). No trademark conflict found in searches at decision time (not a registered mark in the reviewed registries), but it will compete for search/store visibility under the same name. Decision: accepted this tradeoff knowingly rather than switching names.
re:call — reserved for the future pure-Rust reimplementation of the calling stack (ADR-018’s deferred goal), in the “re:zero”-style naming pattern (re: = rewrite/redo). Not the name of the current rstgcalls binding crate — that name stays as-is, since it honestly describes what it is (Rust bindings to tgcalls), and re:call is specifically earmarked for the from-scratch reimplementation once that work actually starts.
Lattice — the plugin container format (OQ-013, spec draft lives at context/LATTICE.md). Names: Lattice Container / Lattice Package Format; short form LTT Container; file extension .lttc. Pronunciation of the extension: L-T-T-C /ˌɛl tiː tiː siː/. Semantics: lattice = решётка — the Merkle DAG is literally one. A separate standalone project (created for Fera, not Fera-internal), plugins/runtimes only — native modules stay out of it (OQ-013 scope decision).
Other individual modules (search fork, storage wrapper, etc.) — named 2026-10-02 (see OQ-025 for the repo topology):
- mikkaj — the milli fork (search engine, ADR-012). Author’s pick over the rejected “srch-milli”.
- fload — the nylon-ring fork (module runtime, OQ-024 fork intent). Author’s pick; “nya-runtime” was rejected.
- grmrs — the grammers fork (protocol layer, ADR-026). Kept from the draft round.
- Repo names in the thefera org: fera, fload, mikkaj, grmrs, lattice, rstgcalls, project-design (private, design docs), site (+ a future teaser site, OQ-026).

Constraints applied when choosing Fera (keep for future module naming too):

Should read fine across EN/RU contexts.
Short, poetic-sounding names in the Rust-ecosystem tradition (serde, tokio, hyper) are preferred over literal/descriptive names (rustcalltg-style) for anything intended to have its own identity.
Keep project branding separate from the author’s personal handle.

1.5. Versioning & release pipeline (2026-10-02)

Version scheme: X.ZZZ.YY-EDITION (author’s scheme, recorded):

X (major) — product epoch: big feature milestones, “new era” releases. Not necessarily breaking — breaking changes are the EDITION’s job, not the major’s.
ZZZ (minor) — features. YY (patch) — fixes.
EDITION — the API edition from ADR-021 (module contract semantics; host supports [N, N-1]). A breaking contract change bumps the EDITION, independent of X. The scheme as a whole mirrors how Rust does it (author’s reference, 2026-10-02): editions are opt-in compatibility contracts with overlap, majors are epochs — not semver-breaking markers.
Relationship to ADR-024 channels (stable/beta/nightly): channels are manifest tags, orthogonal to the version number (to be confirmed when first releases ship).

Release pipeline: ЗАТ (closed alpha) → ЗБТ (closed beta) → ОБТ (open beta) → Release.

ЗАТ (closed alpha) plan (author’s, 2026-10-02):

Participants: the author’s friends (small trusted circle).
An in-app bug-report button ships with the alpha build.
Self-hosted Sentry for crash/telemetry collection — deployed locally (on own infrastructure), not SaaS. Privacy note (recorded as an OQ): crash reports are telemetry; fine for the trusted ЗАТ circle, but the ОБТ/release policy (opt-in? minimized payloads? replace with an in-house mechanism?) is an open question — see OQ-027.
Telemetry is a separate DLL module (author’s decision, 2026-10-02, mid-edit): opt-out by removing/disabling the module — the module system (ADR-001/020) makes telemetry literally unloadable, an explicit architectural answer to the privacy question. See OQ-027.

PR plan (author’s, 2026-10-02):

Teaser site goes live exactly when ЗБТ starts (“we will be there soon” page, OQ-026) — same moment, not before.
At ЗБТ, invite Russian-speaking tech YouTubers/bloggers for an “evaluate this project” look. Two named: AFaGP (Kazakh tech blogger, ~75K YT / ~475K TT) and Chopocompik (RU tech blogger, hardware/power-consumment topics — thematically close to Fera’s power-efficiency story, OQ-024). The author already has a contact with Chopocompik from optimizing DriftWM (a project he uses; its shaders were expensive).

2. Logo / visual identity

Status: direction chosen, no concrete artwork yet.

Explicitly rejected approach: reusing/recoloring Telegram’s paper- plane silhouette (or Rust’s gear/cog mascot) with added details. Both are protected trademarks of their respective projects — recoloring or adding a small element (“cropped ears”, etc.) is still a derivative work of a registered mark, not “inspired by,” and risks a takedown/trademark complaint if the project gains visibility. It also undermines Fera having its own identity rather than reading as “a recolored Telegram.”

Chosen direction:

Primary accent color: copper/rust tone — does double duty: evokes “Rust (the language)” through color rather than through copying Rust’s gear logo, and gives the brand a warm, distinctive palette independent of Telegram’s blue.
Mark: an abstract arrow/wing silhouette with a jagged (gear-tooth-like) trailing edge — smooth, aerodynamic leading edge conveys speed/flight (the feeling Telegram’s paper plane evokes, without copying its form); the jagged trailing edge conveys mechanism/engineering (the feeling Rust’s gear evokes, again without copying its form). The two associations are captured as combined sensation, not as two mascots glued together.
Alternative same-direction sketch considered: a monogram “F” where the lower stroke resolves into the same jagged/gear-tooth edge — not chosen over the arrow/wing concept, but kept as a fallback direction if the arrow/wing doesn’t work well at small sizes.

Still open (unchanged from before):

Whether the logo should visually nod at the three-axis modularity (Engine/Style/Feature) at all — current lean is no, keep it about the product feeling (speed/engineering), not internal architecture, per the explicit “user doesn’t need to know this” stance.
Per-OS icon treatment: one fixed mark across all OSes (current lean), vs. per-platform adaptation — not yet decided deliberately.
No concrete SVG/artwork produced yet — next step when picked up is to actually draft the arrow/wing concept and see how it holds up at favicon/taskbar sizes before committing further.

2.5. Tagline

Fera — an experimental Telegram client focused on ergonomics, speed, and lightweightness.

Author’s own phrasing, deliberately kept — grammatically valid English (“lightweightness” is a real, if uncommon, word), not corrected away from her voice.

2.6. Future website direction

Status: idea stage, not started. If/when a marketing site gets built:

Visual theme: the same copper/rust palette as the logo (§2) — carries the brand identity through consistently, not just the app icon.
Presentation style: Apple-keynote-style scroll-driven animation, borrowing 1-2 well-worn patterns rather than attempting full production polish:
- A synced scroll-driven OS switcher — one client window mockup that morphs between macOS/Windows/Linux chrome and style as the user scrolls, visually demonstrating the Style-module-per-OS concept (ADR-009) as a visual trick rather than explaining it in text (keeping with the “user doesn’t need to know the architecture” stance — this shows the result, not the mechanism).
- A sticky-scroll feature section (visual stays pinned, text beside it changes per scroll position) for walking through features.
- Optionally, a slow zoom/pan over an interface screenshot for an “immersive” opening moment — cheap to implement (CSS transform + scroll listener), no WebGL needed.
Deliberate scope discipline: pick 1-2 patterns and execute them well rather than a showcase of many techniques — a single memorable moment beats a technique demo reel.
Likely implementation: GSAP + ScrollTrigger (framework-agnostic, the standard choice for this kind of scroll-driven animation) or Framer Motion if the site ends up being React-based.

3. UX direction notes

Loose principles gathered from the architecture discussion that should inform UX decisions later, even though no concrete screens have been designed yet:

1:1 visual parity per-OS is a hard goal, not “inspired by” — see ADR-009/OQ-010 (pixel-diff regression against official per-OS clients).
Offline state should never look degraded if the data is cached — the whole point of ADR-010 is that a user shouldn’t be able to tell they’re offline just from scrolling history; the “no network” signal should be a distinct, honest indicator, not an empty/broken history view.
Trust/module management UI needs to be approachable, not security-theater-scary — the trusted-key add/remove UI (name + URL/hex) from ADR-003 should read like adding a contact, not like a certificate manager dialog.
Plugin capability grants (read-only default, ADR-002) should be legible per-capability, not a single “allow this plugin” toggle — the user should see what they’re granting (read messages? send messages? mutate UI?) at the moment they grant it.