unight0/ssrpi

Purpose and Executables

SSRPI is a Go client-server secure chatroom implementation. The server accepts TLS connections, authenticates users, maintains chatroom/admin state, and persists user data in SQLite. The client is an interactive terminal application for login, chat, administration, and file operations.

Entry points:

• Server process: serv/main.go

• Terminal client process: client/main.go

• Protocol contract: PROTOCOL.md

Protocol and Trust Boundary

PROTOCOL.md defines the application wire protocol shared by both independently built binaries. TLS protects transport confidentiality and integrity; protocol-level authentication then establishes user identity and authorization.

The public network boundary is the server listener in serv/main.go. Client input and remote server messages cross separate trust boundaries in client/main.go; server-side command handling must enforce authorization rather than trusting client UI behavior.

Server Runtime and State

serv/main.go is the authoritative service runtime. It is responsible for:

• Loading the TLS certificate/key and listening on the configured TCP port.

• Managing concurrent client sessions and message distribution.

• Registration, login, password changes, admin promotion/revocation, kicks, and shutdown.

• Enforcing the shared server password and per-user privileges.

• Loading and presenting an optional MOTD.

Persistent account state is backed by SQLite, configured through the server’s database-path flag. This requires CGO, as declared by the repository build requirements. TLS material is generated or provisioned outside the binary; serv/makecert.sh is the local certificate-generation entry point.

Client Interaction Layer

client/main.go owns connection setup and the Bubble Tea terminal UI. It obtains connection credentials from flags or interactive prompts, opens the TLS session, performs protocol authentication, and renders incoming chat/system events.

The client maps slash commands into protocol requests, including broadcast/direct chat, user listing, file upload/download, self-service password changes, and privileged administration. It should treat authorization failures and server-originated state as authoritative.

Messaging, Presence, and Administration Flow

The primary control flow is:

1. Client connects over TLS and provides server/user credentials.

2. Server validates the server password and user account state, registering users when applicable.

3. Server tracks the authenticated session and broadcasts presence/chat events to relevant connected clients.

4. Client submits user or admin commands; server validates identity and admin status before mutating shared state.

5. Session disconnect, kick, or shutdown removes/terminates active connections.

The first registered user becomes an administrator, making initial registration a bootstrap boundary. Administrative operations—including server-password changes and remote shutdown—are server-owned actions in serv/main.go, not client-enforced permissions.

File Transfer Boundary

The command surface includes upload and download operations, with recipient targeting for uploads. These operations are protocol-defined in PROTOCOL.md, initiated from client/main.go, and mediated by serv/main.go. The server is the coordination and authorization point for file identifiers, aliases, recipient selection, and retrieval; clients should not assume peer-to-peer transfer.

Build and Deployment Shape

The repository contains two separate Go modules:

• serv/go.mod

• client/go.mod

They are built and deployed as separate executables, enabling the server to run as the long-lived TLS/SQLite service while clients remain disposable terminal sessions. Required operational dependencies are Go 1.21+, CGO/SQLite support, a server certificate/key pair, and optionally an MOTD text file.