**Migrated from GitHub issue icub3d/decentcom#66** **Original Author:** @icub3d **Original Date:** 2026-04-17T00:12:41Z --- # Feature: Bot System — Identity, SDK, API Docs, and Management UI ## Overview Enable automated bot accounts to connect to decentcom servers, interact with channels, and respond to events. Bots are treated as regular identities using Ed25519 challenge-response auth but with a `bot: true` flag for UI and permission purposes. ## Background decentcom's identity model is built on Ed25519 key pairs. Bots are technically identities that can sign challenges. This feature formalizes their role in the system, providing a `bot` flag for UI badges and specialized rate limits. ## Requirements - [x] Bots are first-class identities with a `bot: true` flag (Self-declared by users for now) - [x] Bots authenticate via the same Ed25519 challenge-response flow as human users - [ ] An OpenAPI 3.x spec is generated or maintained for all REST endpoints using `utoipa` - [ ] A Rust SDK crate (`decentcom-bot-sdk`) wraps the REST + WebSocket gateway in a bot-friendly interface - [ ] A simple CLI tool (`decentcom-bot`) that handles the auth handshake and pipes events to scripts - [ ] Bots appear in the member list and on messages with a visible "BOT" badge ## Design ### API / Interface Changes - `User` objects gain an `is_bot: bool` field in profiles and message author objects. - Any user can set `is_bot: true` in their profile update. ### Data Model Changes - `users` table: Add `bot` (INTEGER/BOOLEAN) column. ### Related Research - Abuse protection and performance: #67 - Identity verification for open servers: #68 ### Component Changes **Server (`server/`):** - `server/src/storage/models.rs`: Add `bot: bool` to `User`. - `server/src/messages/handlers.rs`: Include `is_bot` in author metadata. **Bot SDK (`bot-sdk/` — new crate):** - Simple Rust function to perform the 3-step auth flow. - WebSocket heartbeat and event dispatch loop. **Client (`client/`):** - `client/src/components/members/MemberItem.tsx`: add BOT badge. - `client/src/components/messages/MessageItem.tsx`: add BOT badge on author. ## Task List ### Phase A — Identity and UI - [ ] Migration: Add `bot` column to `users` table - [ ] Server: Update `User` storage model and Profile update handler to support the flag - [ ] Client: Display "BOT" badge in member list and message author headers ### Phase B — SDK and Tooling - [ ] Shared: Implement a helper for the Ed25519 3-step handshake - [ ] Bot-SDK: Create the crate and implement a basic WebSocket event loop - [ ] Tooling: Create a simple CLI that uses the SDK to respond to events via shell scripts ### Phase C — Documentation - [ ] Annotate handlers with `utoipa` for OpenAPI generation - [ ] Add `/openapi.json` endpoint to the server ## Test List - [ ] Unit test: setting `is_bot: true` persists in the database - [ ] Integration test: `GET /api/v1/members` includes `bot` field - [ ] SDK test: bot can successfully authenticate and join the gateway - [ ] Manual: verify BOT badge is visible in the client UI

icub3d commented

2026-04-26 16:46:05 +00:00

Owner

Migrated from GitHub issue icub3d/decentcom#66
Original Author: @icub3d
Original Date: 2026-04-17T00:12:41Z

Feature: Bot System — Identity, SDK, API Docs, and Management UI

Overview

Enable automated bot accounts to connect to decentcom servers, interact with channels, and respond to events. Bots are treated as regular identities using Ed25519 challenge-response auth but with a bot: true flag for UI and permission purposes.

Background

decentcom's identity model is built on Ed25519 key pairs. Bots are technically identities that can sign challenges. This feature formalizes their role in the system, providing a bot flag for UI badges and specialized rate limits.

Requirements

Bots are first-class identities with a bot: true flag (Self-declared by users for now)
Bots authenticate via the same Ed25519 challenge-response flow as human users
An OpenAPI 3.x spec is generated or maintained for all REST endpoints using utoipa
A Rust SDK crate (decentcom-bot-sdk) wraps the REST + WebSocket gateway in a bot-friendly interface
A simple CLI tool (decentcom-bot) that handles the auth handshake and pipes events to scripts
Bots appear in the member list and on messages with a visible "BOT" badge

Design

API / Interface Changes

User objects gain an is_bot: bool field in profiles and message author objects.
Any user can set is_bot: true in their profile update.

Data Model Changes

users table: Add bot (INTEGER/BOOLEAN) column.

Abuse protection and performance: #67
Identity verification for open servers: #68

Component Changes

Server (server/):

server/src/storage/models.rs: Add bot: bool to User.
server/src/messages/handlers.rs: Include is_bot in author metadata.

Bot SDK (bot-sdk/ — new crate):

Simple Rust function to perform the 3-step auth flow.
WebSocket heartbeat and event dispatch loop.

Client (client/):

client/src/components/members/MemberItem.tsx: add BOT badge.
client/src/components/messages/MessageItem.tsx: add BOT badge on author.

Task List

Phase A — Identity and UI

Migration: Add bot column to users table
Server: Update User storage model and Profile update handler to support the flag
Client: Display "BOT" badge in member list and message author headers

Phase B — SDK and Tooling

Shared: Implement a helper for the Ed25519 3-step handshake
Bot-SDK: Create the crate and implement a basic WebSocket event loop
Tooling: Create a simple CLI that uses the SDK to respond to events via shell scripts