Forem: kijmoshi

Big Companies steal your data, so I made a secure chat for you.

kijmoshi — Sat, 14 Mar 2026 19:03:46 +0000

Every team has this moment. Someone shares something sensitive in Slack. Someone else says "we shouldn't use this for that." Then comes the mass migration to a different app — one with a privacy policy nobody reads, on servers nobody controls, with an encryption model nobody has verified.

Your options? Signal (great, but mobile-first and phone-number-tied). Telegram (not E2EE by default). Matrix/Element (self-hostable, but the setup is an afternoon project and the UI is a lot). Discord (no). A team email thread (no).

All of them are either closed-source, require a phone number, live on someone else's server, or need a UI that feels like a full-time job to operate.

I wanted something simpler:

$ zypher work alice

That's it. Terminal. Encrypted. Your server or mine.

That's Zypher.

The 30-Second Version

Install it:

npm i -g zypher-chat

Spin up a server — one command clones, configures, and daemonizes it:

zypher server quickstart

zypher new

Open a conversation:

$ zypher work alice

  ╭─ alice ──────────────────────────────────╮
  │  alice  🟢 online                        │
  ╰──────────────────────────────────────────╯

  you › hey
  alice › hey! how's the project going?
  you › encrypting everything, obviously

No phone number. No app store. No browser extension. Just a terminal.

Why Not Just Use Signal / Telegram / Matrix?

You can. But:

Signal needs a phone number. You can't register without a real mobile number. If your phone dies or you change numbers, you lose access. For a dev tool or internal team chat, that's an unnecessary external dependency.
Matrix/Element is powerful but heavy. Spinning up a Synapse server is a real infrastructure project. The client is feature-rich but not CLI-native.
Discord is a product, not a protocol. Not self-hostable, not open-source, not private.
It lives on someone else's server. All of these options require trusting a third party with your data. Even if the app is open-source, the deployment isn't. Zypher is self-hosted by design — you control the infrastructure and the data.

Zypher is for when you want a terminal, a server you control, and actual end-to-end encryption — not a SaaS product that happens to call itself private.

How It Actually Works

Registration and Key Generation

When you register on a server, Zypher generates two keypairs locally — before anything touches the network:

An Ed25519 identity key — your permanent signing key. Every message you send is signed with it. Recipients verify the signature. The server cannot forge a message from you without your private key.
An X25519 pre-key — a Diffie-Hellman key for key exchange. Other clients use it to compute a shared secret without ever transmitting one.

The private keys never leave your machine. They're stored in ~/.zypher/config.json, mode 0600. The server only receives your public keys.

DM Encryption — per-message ephemeral ratchet

When you send a DM to Alice:

Zypher generates a fresh ephemeral X25519 keypair for this message only.
It performs ECDH between your ephemeral private key and Alice's public pre-key, then runs the result through HKDF-SHA256 to derive a 256-bit AES key.
The message is encrypted with AES-256-GCM using a random IV.
The ephemeral public key (the "ratchet key") ships alongside the ciphertext so Alice can reproduce the same ECDH and decrypt.

The ratchet key is unique per message. Every message gets a fresh keypair. The server sees only ciphertext, nonces, and public keys — never plaintext. Even if a session key were ever compromised, past messages stay safe.

Group Encryption — shared key, individually wrapped

Groups use a shared symmetric key, but that key is never sent in the clear. When you create a group or invite someone:

A random 256-bit group key is generated on your machine.
For each member, that group key is encrypted separately using their X25519 pre-key (same ECDH → AES-256-GCM flow as DMs).
Each member receives their own encrypted bundle. The server stores these bundles but cannot read the group key inside any of them.

Group messages are then encrypted with the shared group key + AES-256-GCM. Admin operations — kick, promote, rename — trigger a re-key: a new group key is generated and re-encrypted for each remaining member.

What the Server Actually Stores

The server is a dumb relay with a mailbox. It stores:

Usernames, bcrypt password hashes, and public keys (identity + pre-key)
Encrypted ciphertext for offline delivery — it cannot read any of it
Group membership and role metadata

It never sees plaintext. It never sees private keys. It never stores session keys.

Client A                    Server                  Client B
   │                           │                         │
   │── ECDH(ephemeral,         │                         │
   │      B's pre-key)         │                         │
   │── AES-256-GCM(msg) ──────▶│── store ciphertext ────▶│
   │                           │                         │── ECDH(my pre-key,
   │                           │                         │      ratchet_key)
   │                           │                         │── AES-256-GCM decrypt

Things I Deliberately Didn't Build

No phone numbers. Registration is username + password. Nothing else required.
No centralized server. zypher server quickstart clones the server repo, configures it, and runs it as a local daemon. You own the infrastructure.
No cloud accounts. There's no "Zypher cloud." Every deployment is independent.
No browser client. It's a CLI. The terminal is the UI. If you want a GUI chat app, you're looking for Signal.
No multi-device key sync. Keys live on the device that generated them. Offline messages are queued on the server and delivered once — then gone from the queue.
No metadata minimization theater. The server knows who is messaging whom (routing requires it). What it doesn't know is what they're saying.

Ghost Mode

Type /ghost in any chat session:

  !! GHOST MODE !!  This erases everything.

  Type GHOST to confirm: █

Confirm with the word GHOST, and Zypher deletes ~/.zypher/ entirely — config, private keys, account data, everything. The process exits immediately. Nothing remains on disk.

One command, scorched-earth wipe. Useful when you need it.

Offline Messaging

If Alice is offline when you send her a message, the server queues the encrypted ciphertext. When Alice reconnects, all queued messages are delivered in order and the queue is cleared. The server holds them only as long as it has to — it cannot read them, and they're deleted once delivered.

The Stack

The server is ~600 lines of JavaScript:

Component	What it does
`express` + `helmet`	HTTP API with security headers and rate limiting
`socket.io`	Real-time message delivery
`node:sqlite`	User accounts, offline queues, group metadata
`bcrypt`	Password hashing
`jsonwebtoken`	Session authentication

The client is a single index.js (~1,600 lines). No UI framework. One runtime dependency: socket.io-client. All crypto — X25519, Ed25519, AES-256-GCM, HKDF — is Node.js built-in (node:crypto). Nothing custom, nothing exotic.

Try It

# Install
npm i -g zypher-chat

# Quickstart: clones, configures, and launches a local server as a daemon
zypher server quickstart

# Register on it
zypher new

# Open a chat
zypher <servername> <username>

Requires Node.js 22+. Works on Linux, macOS, and Windows.

Source code: github.com/real-kijmoshi/zypher

npm: npmjs.com/package/zypher-chat

Website: zypher.kijmoshi.xyz

I Got Tired of "How Do I Send You This File?" So I Built QuickDrop

kijmoshi — Fri, 13 Mar 2026 21:03:06 +0000

I Got Tired of "How Do I Send You This File?" So I Built QuickDrop

Every developer has been there. You need to send a folder to someone. Maybe it's a build artifact, a dataset, some photos from your phone, or a project directory.

Your options? Upload to Google Drive and wait. Zip it and email it (if it's under 25 MB). Set up an S3 bucket. Use WeTransfer. Bluetooth. AirDrop (Apple only). USB stick.

All of them require either an account, a cloud service, a size limit, or the same ecosystem.

I wanted something dumber and faster:

machine-a$ quickdrop receive
machine-b$ quickdrop send ./photos --to AB3C4E7E:X9K2

Done. Files transferred. No accounts. No uploads. Encrypted end-to-end.

That's QuickDrop.

The 30-Second Version

Install it:

npm install -g quickdrop

On the receiving machine, run:

$ quickdrop receive ./downloads

 quickdrop - receive
--------------------------------------------
  LAN code       AB3C4E7E:X9K2  <- same network
  Tunnel code    quick-fox-42:X9K2  <- anywhere
  Password       X9K2  <- new every session
--------------------------------------------
  Waiting for sender...  (Ctrl+C to stop)

On the sending machine, paste the code:

$ quickdrop send ./photos --to AB3C4E7E:X9K2

  ✓ DSC_001.jpg  (4.20 MB, 11.3 MB/s)
  ✓ DSC_002.jpg  (3.85 MB, 12.1 MB/s)
  ✓ raw/DSC_003.cr2  (18.40 MB, 11.8 MB/s)
--------------------------------------------
  ✓ 3 files  -  26.4 MB  -  2.3s  -  11.7 MB/s

That's it. One command on each side. The combined code AB3C4E7E:X9K2 encodes both the address and a one-time password, so the sender has zero prompts.

Why Not Just Use scp/rsync?

You absolutely can. But:

scp/rsync need SSH access. The receiver needs an SSH server running, a user account, firewall rules, open ports. QuickDrop needs nothing pre-configured.
scp doesn't work across NATs. If you and your friend are on different WiFi networks, you can't scp to them without port forwarding or a VPN. QuickDrop automatically tunnels through NAT when needed.
scp requires knowing the IP. QuickDrop encodes the address into a short alphanumeric code you can read over the phone or paste into Slack.

QuickDrop is for the use case where you want to send files to a person, not deploy to a server.

How It Actually Works

There's no relay server storing your files. Here's what happens under the hood:

On the Same Network (LAN) -- direct, peer-to-peer

QuickDrop opens a TCP server on the receiver and encodes its local IP + port into an 8-character base-36 code. The sender decodes the code, connects directly via TCP, and streams files at full LAN speed. No internet involved. This is true peer-to-peer -- nothing between the two machines.

Across the Internet -- relayed, but end-to-end encrypted

When sender and receiver are on different networks, QuickDrop spins up a localtunnel WebSocket bridge. The receiver gets a public *.loca.lt subdomain. The sender connects to that subdomain over WSS. Traffic is relayed through localtunnel infrastructure, but every byte is AES-256-GCM encrypted before it enters the tunnel -- the relay sees only ciphertext and never stores anything.

This is not peer-to-peer in the strict sense (there's no NAT hole-punching), but your files are never readable by the relay, and nothing is persisted on any server.

Both codes (LAN and tunnel) are displayed automatically. Use whichever one works.

Encryption

All file data is encrypted with AES-256-GCM before it hits the wire. The 4-character session password is never transmitted -- both sides independently derive a 256-bit key using scrypt (N=16384, r=8, p=1), then prove they have the same key via an HMAC-SHA256 handshake.

Each message uses a fresh random IV, so identical files produce different ciphertext every transfer. GCM's authentication tag means any tampering or corruption is detected and the transfer aborts.

Wire format per message:
[4-byte length prefix][12-byte IV][16-byte auth tag][ciphertext]

Is a 4-character password breakable? In theory, yes -- there are ~1.7 million possible 4-char alphanumeric passwords. But scrypt with these parameters takes ~100ms per attempt, making brute-force cost ~47 hours of CPU time. And the password changes every session. For a file transfer tool (not a bank vault), this is a practical tradeoff between security and usability.

Things I Deliberately Didn't Build

No accounts. No signup, no login, no API keys.
No cloud storage. On LAN, files go directly between machines. Over the internet, traffic is relayed through an encrypted tunnel -- but nothing is stored on the relay, and the relay can't decrypt your data.
No GUI. It's a CLI tool. If you want a GUI, you're looking for AirDrop.
No configuration files. It works out of the box. The only persistent state is an optional contacts file at ~/.quickdrop/contacts.json.
No file size limits. It streams in 64 KB chunks. Send 10 bytes or 10 GB.

Contacts: The One Piece of State

After a transfer, the sender is prompted to save the receiver as a named contact:

Save "192.168.1.42" as a contact? Name (Enter to skip): workpc
  ✓ Saved! Next time: quickdrop send ./folder --to workpc

Next time:

quickdrop send ./logs --to workpc --password X9K2

That's it. Contacts are a flat JSON file. You can manage them:

quickdrop contacts              # list
quickdrop contacts rename workpc office
quickdrop contacts remove office

The Stack

The entire thing is ~500 lines of JavaScript across 7 files:

File	What it does
`cli.js`	Arg parsing, subcommand dispatch
`src/sender.js`	Connect, authenticate, stream files
`src/receiver.js`	TCP server, WS bridge, auth, write files
`utils/framing.js`	Length-prefixed message framing
`utils/crypto.js`	AES-256-GCM, scrypt, HMAC
`utils/codes.js`	IP-to-base36 encoding
`utils/contacts.js`	Contact book persistence

Two runtime dependencies: ws for WebSocket support and localtunnel for NAT traversal. Everything else is Node.js built-in (net, crypto, fs, path).

Try It

# Install
npm install -g quickdrop

# Or just run it once
npx quickdrop help

Requires Node.js 18+. Works on Linux, macOS, and Windows.

Test it on your own machine with two terminals:

# Terminal 1
quickdrop receive ./test-output

# Terminal 2 (paste the code from terminal 1)
quickdrop send ./some-folder --to <CODE>

Source code: github.com/real-kijmoshi/quickdrop
npm: npmjs.com/package/quickdrop
Website: quickdrop.kijmoshi.xyz

QuickDrop is ISC licensed. It scratches a very specific itch: sending files to someone without ceremony. If that itch is yours too, give it a shot.

[Boost]

kijmoshi — Sat, 14 Feb 2026 19:27:24 +0000

whiteboard made in 2 hours for GitHub Copilot CLI Challenge

kijmoshi ・ Feb 14

#devchallenge #githubchallenge #cli #githubcopilot

whiteboard made in 2 hours for GitHub Copilot CLI Challenge

kijmoshi — Sat, 14 Feb 2026 18:42:45 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built a real-time multi-user whiteboard web app that allows multiple users to draw on the same canvas simultaneously. The app uses a shared online database so every stroke is synchronized instantly across all connected clients.

The goal of this project was to explore real-time collaboration and see how quickly I could go from an idea to a working prototype using modern tooling. It's designed to be simple, lightweight, and easy to extend with features like rooms, undo, or AI-generated drawings in the future.

Github Repo https://github.com/real-kijmoshi/whiteboard/tree/main

Demo

🔗 Live Demo: https://coop-whiteboard.netlify.app

The demo shows multiple users drawing at the same time, with brush color and size controls. Strokes appear live for everyone without refreshing the page.

My Experience with GitHub Copilot CLI

Using GitHub Copilot CLI made development significantly faster and smoother. I used it to:

Generate boilerplate project setup with Vite
Help write Firebase configuration and real-time sync logic
Quickly prototype canvas drawing functions

Instead of constantly searching for syntax or examples, I could describe what I wanted in natural language and get usable code immediately. This helped me stay focused on the project idea rather than getting stuck on implementation details. It allowed me to polish UI and UX without constantly worrying about pixel-perfect CSS.

Copilot CLI felt like having a coding partner in the terminal that was especially useful when working with unfamiliar APIs like real-time database listeners and canvas rendering.

Overall, it made experimentation faster and encouraged me to try features I might not have attempted otherwise. I was able to build this entire project in approximately 2 hours.