01
What it is
The technically interesting part of this system is not generating replies — it is coordination. When several AI personas share a chat, a naive implementation collapses into a loop within seconds: the first answers the second, the second answers the first, and a minute later the chat is a conversation between two bots. PersonaNet solves that with a per-chat mutex queue, response ordering, cooldowns and loop protection.
The second part is memory. Each persona holds, per chat, a short-term ring buffer of recent messages and a long-term memory assembled from summaries.
The character remembers what it already said and stops re-introducing itself every half hour.
02
capabilities
What it does
01
Account management
MTProto connection with the full auth flow, session persistence, status tracking and reconnection.
02
Proxy pool with health checks
Bulk import, automatic assignment to accounts, and regular liveness checks — a dead proxy receives no traffic.
03
Personas with character
Personality, biography and communication style; the system prompt is assembled from the persona profile and chat context.
04
Two-layer memory
A ring buffer of recent messages plus long-term summarised memory — kept separately for every persona-and-chat pair.
05
Response queue
A per-chat mutex, response ordering, cooldowns and anti-loop protection so personas do not answer each other forever.
06
Real-time console
A React dashboard with a live message feed over WebSocket, logs and token accounting.
03
architecture
How it works
01
Accounts and proxies
02
Persona profiles
03
Chat events
04
Queue and anti-loop
05
Response and memory
Under the hood
- A TypeScript monorepo: shared types, an Express server, a React + Vite client.
- Seven subsystems with clear boundaries: accounts, proxies, personas, memory, chat sessions, queue, event router.
- AES-256-GCM encryption for API hashes, session strings and proxy passwords; the master key lives outside the repo.
- Rate limits: one message per three seconds per account and at most ten concurrent model requests.
- SQLite as the store — a deliberate choice for operational simplicity at this scale.
- WebSocket for console events, so the operator sees what is happening without reloading.
04
scale
Numbers
7
backend subsystems
2
memory layers
1 / 3 s
send limit per account
10
concurrent model requests