DEV Community: Vishwas V Pandey

I built an open-source team chat that writes your daily standup (and lets you bring your own Claude)

Vishwas V Pandey — Wed, 21 Oct 2026 10:50:43 +0000

Most teams pay per seat for chat. Then they pay again for a standup bot. Then again for an AI add-on.

I wanted one thing I could run myself that did all three, so I built Forma Chat: open-source (Apache-2.0) team chat that runs on your own server, as one Go binary with a SQLite file.

📺 Watch the 74-second video · 💻 Code on GitHub

What works today

Public and private channels, DMs and group DMs, threads, reactions, edits with history, pins, mentions, drafts that follow you across devices
Full-text search (SQLite FTS5), filtered by what you can read before any result, snippet or count exists
Turn any message into a task; My work ranks your own tasks and shows why each one is near the top
Daily standups that draft themselves
Optional AI agents with your own key, or your own Claude Code connected over MCP

It's an early release. Files, huddles and mobile apps aren't there yet, and the repo keeps a feature status page that says exactly what works.

Standups that write themselves, without an AI bill

Every task change is recorded as an event: created, started, finished, blocked, commented. At the time you choose, Forma builds each person's draft from their own events that day:

Done: what they finished, started or worked on
Next: their top open tasks by priority and due date
Blockers: blocked tasks, with the reason they wrote

No model is involved, so it's free, fast and explainable. The privacy rules mattered more to me than the drafting:

A draft is visible only to its author until they submit it.
Work in personal tasks or private channels the team channel can't see shows up only as a private suggestion ("Only you can see this"). It is never put in the summary automatically.
One summary posts per day. People who didn't submit are listed as "No update yet", never guessed at.
No keystrokes, no screenshots, no activity scores, no ranking of people.

AI agents: your key, or your own Claude

An admin creates an agent, gives it the workspace's own Anthropic API key (or any OpenAI-compatible key) and adds it to channels. Mention it and it answers live in a thread, streaming, with a Stop button. It can search messages and create or list tasks, always with the asking person's permissions.

The rule I spent the most time on: an answer may only use what the channel it's answering in can already see. If you ask in #general, it won't quote a private channel you happen to be in.

Or skip the API key and connect the Claude you already use. Create an external agent, add it to channels, make a token, then:

claude mcp add --transport http forma \
  https://chat.example.com/api/v1/mcp \
  --header "Authorization: Bearer fma_..."

Claude Code can then list its channels, read and post messages, search, and list or create tasks, only where that agent was added.

How it's built

Go modular monolith + SQLite in WAL mode, with embedded migrations. The React/TypeScript client is built by Vite and embedded in the binary, so deploying is copying one file.
One read policy. A single Authorize function decides whether a person can read a conversation. Search, threads, realtime and agents all go through it, or through its SQL set form, and a test checks the two always agree. Denied and missing look the same (404).
Messages are never silently lost. A message is stored before it is acknowledged. A transactional outbox feeds realtime, and WebSocket events are only wake-ups. Clients catch up from a per-conversation change counter, so a reconnect replays what was missed and retries never duplicate.
Agent keys are sealed with AES-256-GCM, bound to the agent, and never shown again. Message text and tool results are treated as data for the model, never as instructions.

Try it

You need Go 1.26+ and Node.js 22+:

git clone https://github.com/pandeyvishwas51-oss/forma-chat && cd forma-chat
make setup build
./bin/forma serve

The server prints a one-time link to create the owner account. For a populated demo workspace, run node scripts/demo.mjs.

I'd love feedback, especially on the standup privacy model and the agent audience rule. Issues and PRs are welcome: https://github.com/pandeyvishwas51-oss/forma-chat

Making two Claude Codes talk over HyperDHT

Vishwas V Pandey — Tue, 20 Oct 2026 12:35:25 +0000

My friend and I were building two halves of one app: my agent wrote the frontend, his wrote the backend. Every API question meant copying text out of one Claude Code session, pasting it into a chat, and pasting the answer back. The agents were the ones with the questions. Why couldn't they ask each other?

So I built WokiToki, an open-source tool that gives each developer's coding agent a walkie-talkie. This post explains how it works, without a server anywhere.

The constraint: nothing to host

The obvious design is a relay server both agents connect to. I built that first, and it works, but it means someone runs a server, keeps it up and is trusted with metadata. I wanted two people to be able to start in one minute with nothing but their laptops.

Finding each other: HyperDHT

HyperDHT is the distributed hash table behind Holepunch's Keet messenger. Any node can announce itself under an Ed25519 public key, and anyone who knows that key can look it up and connect.

Each WokiToki daemon listens on the DHT under its own identity key. When the other side connects, HyperDHT hole-punches through both home routers and wraps the connection in a mutually authenticated Noise handshake, so each side knows exactly which key it is talking to.

const server = dht.createServer(
  { firewall: (remoteKey) => !isPairedOrInviteOpen(remoteKey) },
  onConnection,
)
await server.listen(identityKeyPair)

(Simplified from p2p-transport.ts.) The firewall runs before any data flows. A key that is not a paired peer is dropped, unless you have an invite open, and then it gets five tries.

Pairing: an invite and a 6-digit code

wokitoki pair create prints a one-time invite containing your public key and an invite secret. Your friend joins with it, and both screens show a 6-digit verify code derived from the pairing id and both fingerprints. You compare the codes on a call, and each of you approves. Someone who intercepts the invite can't pass this step without the codes differing.

Messages: encrypted twice, delivered once

Noise already encrypts the connection, but WokiToki also encrypts each message end to end with libsodium: X25519 key exchange, a per-pairing key derived with BLAKE2b, and XChaCha20-Poly1305 with the message header as associated data. If you later use the optional relay, it only ever sees ciphertext.

Messages land in a SQLite outbox first. Each one carries a per-peer sequence number, so delivery is at-least-once on the wire and exactly-once in your inbox. If your friend's laptop is closed, the message goes into a mailbox on the DHT, described next.

Offline friends: a mailbox on the DHT

The hard part of serverless messaging is the friend whose laptop is closed. HyperDHT nodes can store small signed records for up to 48 hours, so each WokiToki daemon publishes one record per pairing: its acknowledgement plus any messages still waiting for that peer, sealed with keys derived from the pair's session key. Only the two peers can find, write or read it.

The public DHT drops values much over about 1.2 KB, because they ride UDP, so each sealed message is split into 1 KB immutable chunks plus a manifest of their hashes. The receiving daemon polls the record while the peer is away, fetches the chunks and processes them in order through the same idempotent path as a direct delivery. Its receipt and ack travel back the same way. In a test on the public DHT, a receiver that started after the sender had already gone offline had the message 2 seconds after coming online.

The agent side: MCP

The daemon exposes a local Unix socket, and wokitoki mcp turns it into an MCP server with five tools: wokitoki_send_message, wokitoki_read_inbox, wokitoki_list_messages, wokitoki_list_peers and wokitoki_get_status. wokitoki setup registers it with Claude Code, Codex, Cursor, Windsurf and VS Code.

Two rules keep this safe. Agents get no pairing tools: pairing, approving and revoking need you at the terminal. And incoming text is returned labelled untrusted, so an agent treats it as information, never as instructions.

The Claude Code plugin adds one more thing, a hook: at session start and on your next prompt, your agent is told how many unread messages are waiting and from whom, never their text.

What it doesn't do yet

The DHT mailbox is best effort: nodes may drop records early, and mail older than 48 hours waits for a direct connection.
Networks that block UDP need the optional self-hosted relay.
Message keys are static per pairing (no ratchet), and there has been no external audit.

Try it

npm install -g wokitoki
wokitoki setup --name "You"
wokitoki pair create

Or in Claude Code: /plugin install wokitoki --marketplace pandeyvishwas51-oss/wokitoki.

The code, threat model and protocol docs are at https://github.com/pandeyvishwas51-oss/wokitoki (Apache-2.0). I'd love to hear what breaks.