← All Projects

Telegram channel content system

A system that takes one Telegram channel from source material to scheduled publication and records audience response for the next plan.

From source to publication

Topics come from channel history, expert materials, and measured response to earlier posts, not from an isolated idea without context.

What the person approves

Approval covers one exact package: text, visual, destination, and schedule. Those parts do not drift before Telegram publication.

What the next plan receives

Current counters remain separate from fixed measurements at 24 and 48 hours, so the next plan compares like-for-like post data.

From topic to published post

No channel contents, private messages, recipients, or client materials are shown.

  1. EvidenceChannel history, expert materials, and audience response inform the topic.
  2. PostText and visual are prepared as one exact publication version.
  3. PublicationApproval is bound to the exact package; only that version is scheduled and published.
  4. ResponseViews, forwards, reactions, and comments retain their source and measurement window instead of becoming one vague activity number.
01

The channel gets a complete content cycle

The system takes the channel from research and planning through text, visuals, approval, scheduling, publication, and the next content plan from audience response.

The current implementation operates one real channel. Its output is a published post with post-level response data; the system does not stop at a draft.

02

What must stay connected

  • Topic and source context: A plausible idea can repeat the channel, contradict the expert, or ignore what the audience already responded to.
  • Text, visual, and approved version: Text, image, caption, and schedule can change in different chats after approval.
  • Approved package and publication: A finished post still fails if the wrong version, channel, or time reaches Telegram.
  • Published post and response data: Without post-level response data, the next content plan repeats opinions instead of learning from the channel.
03

One post from evidence to response

CHANNEL HISTORY + EXPERT MATERIALS + AUDIENCE SIGNALS
          ↓
CONTENT PLAN
  topic | format | publication date
          ↓
POST
  text + visual + exact version
          ↓
APPROVAL
  exact payload + destination + time
          ↓
TELEGRAM
  schedule | publish | verify
          ↓
RESPONSE
  views | forwards | reactions | comments
04

What is recorded for each post

topic to publication
Content scope
text + visual
Post package
exact version
Approval
scheduled and verified
Publication
post-level signals
Audience response
Rust + Tokio
Runtime
05

Why publication stays a separate decision

Problem
The system can prepare and schedule a complete post, but publication speaks through a real person's channel and reputation.
Solution
Approval is attached to one immutable publication package: exact text, media, destination, and time. Only that version can move to Telegram.
Why not that option
Treating a prepared post as permission to publish removes the distinction between producing content and representing a person publicly.
06

Current boundary

The system currently operates one channel. It is not yet a finished multi-tenant product: shared lifecycle types and several tenant-isolation rules remain in development.

07

Implementation

Core
Rust, Tokio, Axum, PostgreSQL
Telegram
Grammers, MTProto, scheduled publication
AI
model access through Antigravity Gateway
Content
planning, text, visuals, approval, analytics