Forem: FileShot

What actually goes into a production-ready SaaS boilerplate (hint: it's not just auth)

FileShot — Sun, 08 Mar 2026 14:00:03 +0000

Every developer who's shipped a SaaS product has had the same moment: you stare at a blank repo and think "I'll just wire up auth real quick." Three weeks later you're still fighting OAuth redirect URIs, forgetting to hash passwords correctly, and trying to remember if you added rate limiting to the login endpoint.

Auth is the obvious starting point. But it's not the hard part.

What people miss when they think about "production-ready"

Here's a non-exhaustive list of what a real production SaaS needs beyond auth:

Payments that don't break
Stripe webhooks are notoriously tricky. You need idempotency keys, signature verification on every incoming webhook, retry handling, and logic for subscription states: trialing, active, past_due, canceled. Miss any of these and you'll have users who upgraded but still see the free tier — or get double-charged.

API rate limiting
Every public endpoint needs it. Not just "limit to 100 req/minute globally" — per-user, per-endpoint rate limiting with proper 429 responses and Retry-After headers.

Email infrastructure
Transactional emails (password reset, invoice receipt, account confirmation) need to actually deliver. That means a proper SMTP provider, SPF/DKIM records, and templates that render in Outlook circa 2019.

Proper session management
JWTs with sensible expiry, refresh token rotation, revocation on logout. If you're storing sessions in a cookie, make sure it's HttpOnly, Secure, and SameSite=Strict.

API keys for programmatic access
If you're building anything developer-facing, users will want API keys. That's a whole sub-system: key generation (don't store raw keys — hash them), scopes/permissions, revocation, usage tracking.

Two-factor authentication
TOTP-based 2FA (Google Authenticator, Authy) with proper backup codes. Not optional for anything handling real user data.

Database migrations
Not "I'll just alter the table in prod" — a versioned, idempotent migration system that can run on deploy without downtime.

Docker + deployment config
An actual Dockerfile, not just "it works on my machine." Environment variable management, health check endpoints, graceful shutdown handling.

Why this is hard to get right the first time

Each of these subsystems has its own set of edge cases, and they interact with each other. Your rate limiter needs to know who the user is (auth integration). Your Stripe webhooks need to update your database (migration dependency). Your 2FA backup codes need to be hashed (same as API keys).

Getting all of this right from scratch takes weeks and usually results in at least a few security mistakes along the way.

What I've been building

I got tired of rebuilding the same scaffolding for every project, so I built DiggaByte Labs — a SaaS boilerplate marketplace where you pick exactly the stack modules you need and download a production-ready codebase built around those choices.

The idea is: instead of a "starter template" that's just an opinionated file structure, you get code that's actually wired together. Stripe webhooks already talk to your database. Rate limiting is already in the middleware chain. The 2FA flow already works end-to-end.

The current stack selections include: PostgreSQL + Prisma, JWT auth, Google OAuth, GitHub OAuth, Stripe subscriptions, shadcn/ui, rate limiting, API keys, 2FA, and Docker deployment.

The checklist I use before calling anything "production-ready"

Before shipping any SaaS, I go through this:

[ ] All passwords bcrypt-hashed (cost factor 12+)
[ ] JWT secret is 256-bit random, not a dictionary word
[ ] Refresh tokens rotate on use, invalidate on logout
[ ] Stripe webhook signature verified on every event
[ ] Rate limiting on auth endpoints (login, password reset, 2FA)
[ ] API keys hashed in DB (store only the last 4 chars for display)
[ ] 2FA backup codes are one-time-use and hashed
[ ] SQL queries use parameterized statements (no string concatenation)
[ ] Environment variables never logged
[ ] HttpOnly + Secure + SameSite on all auth cookies
[ ] Health check endpoint at /health returns 200 with no sensitive info
[ ] Graceful shutdown: drain connections before process.exit

If any of those are unchecked in your codebase, that's the real work.

Happy to answer questions about any of these in the comments — particularly the Stripe webhook setup and the API key hashing pattern, which I see done incorrectly in the wild constantly.

Why I stopped trusting cloud storage with my client files

FileShot — Tue, 03 Mar 2026 21:41:28 +0000

I work with clients who send me contracts, legal documents, and financial statements. For years I stored them in Google Drive without thinking twice. Then I read their Terms of Service carefully.

"Google's automated systems analyze your content to provide you with personally relevant product features." That's in Drive's ToS. Not hidden — just not something most people actually read.

I'm not claiming Google is doing anything malicious with my client files. But the technical fact is: Google has the encryption keys for every file in Drive. They can read them. Whether they choose to is a policy question, not a technical one. And policies can change, get subpoenaed, or get breached.

The problem with "encrypted at rest"

Most cloud providers advertise encryption. It sounds reassuring. But "encrypted at rest" just means the file is scrambled on disk — and the provider holds the key. It's the digital equivalent of giving your landlord a copy of your front door key and then calling it a locked apartment.

True privacy requires the provider to not have the key. Your device encrypts the data before it ever leaves. The provider receives only ciphertext — random bytes they can't read regardless of whether they want to.

What I switched to

For one-off client file delivery — sending a contract draft, a final invoice, a signed document — I switched to FileShot.io. It's open source, free to start, and works entirely in the browser. You drag in a file, it encrypts it locally using AES-256-GCM (the Web Crypto API handles this before the upload starts), and you get back a link.

The decryption key is in the URL fragment — the part after #. Browsers never send URL fragments to servers. So the FileShot server receives and stores encrypted bytes and has no idea what the file contains or even how large the plaintext is. When the recipient opens the link, their browser downloads the ciphertext and decrypts it locally.

No account needed. No storage limits to worry about for one-off transfers. The file is available for however long you set the expiry.

For ongoing storage I use Proton Drive

FileShot isn't a replacement for cloud storage — it's for point-to-point sharing. For documents I need to keep long-term, I moved to Proton Drive. End-to-end encrypted, provider can't read your files, and it has a proper folder structure and sync client.

Tresorit is the enterprise alternative if you need compliance features and auditing.

The point isn't paranoia

I'm not writing this because I think Google is evil or that your files are being actively read. The point is architectural: if you care about client confidentiality, you should know whether your file storage provider technically can access your files, regardless of whether they will.

The answer for Drive, Dropbox, and OneDrive is: yes, they technically can. For Proton Drive, Tresorit, and FileShot.io: no, they technically can't — by design.

That's a meaningful distinction, especially if you're in law, finance, healthcare, or any field where confidentiality isn't optional.

FileShot.io is MIT-licensed and the source is on GitHub if you want to verify the encryption implementation yourself.

Why You Should Never Trust the Server With Your Encryption Keys

FileShot — Tue, 03 Mar 2026 18:49:43 +0000

When you upload a file to most cloud services, here's what actually happens: your file travels to their servers in plaintext (or gets decrypted on their end), and they hold the encryption keys. That means they can read your data. Whether they do is a different question, but architecturally, you've transferred trust.

There's a better model. It's called zero-knowledge encryption, and it flips the architecture entirely.

The Problem With Server-Side Encryption

Services like Dropbox, Google Drive, and iCloud offer "encryption at rest." This sounds safe, but it means:

Your file is encrypted after reaching their servers
They hold the keys
Any employee, court order, or data breach can expose your files

"Encryption at rest" is really just protection against someone stealing their hard drives. It doesn't protect you from the service itself.

The Zero-Knowledge Alternative

Zero-knowledge means the server mathematically cannot read your data.

Here's the pattern:

Client side:
  1. Generate a random 256-bit AES key
  2. Encrypt the file with AES-256-GCM
  3. Upload the ciphertext to the server
  4. Embed the key in URL fragment: https://yourservice.com/file#KEY_HERE

Server side:
  - Receives: encrypted blob only
  - Stores: encrypted blob only
  - Key: never seen

The URL fragment (the # part) is defined in RFC 3986 as a client-side identifier. Browsers intentionally do not send fragment identifiers in HTTP requests. The key lives in the browser and never touches your server's logs.

Why AES-256-GCM Specifically

GCM (Galois/Counter Mode) is an authenticated encryption mode, meaning it provides:

Confidentiality: data is encrypted
Integrity: any tampering is detectable (the auth tag fails)
Authentication: you know the data hasn't been modified

With AES-GCM, the decryption will fail immediately if the ciphertext was altered. With unauthenticated encryption modes like AES-CBC, you wouldn't know.

Implementing It With the Web Crypto API

The browser's built-in SubtleCrypto API is all you need:

// Generate key
const key = await crypto.subtle.generateKey(
  { name: 'AES-GCM', length: 256 },
  true,
  ['encrypt', 'decrypt']
);

// Generate IV (must be unique per encryption operation)
const iv = crypto.getRandomValues(new Uint8Array(12));

// Encrypt
const encrypted = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv },
  key,
  fileArrayBuffer
);

// Export key for the URL fragment
const exportedKey = await crypto.subtle.exportKey('raw', key);
const keyHex = Array.from(new Uint8Array(exportedKey))
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');

Note: Always generate a fresh IV for every encryption. Reusing an IV with the same key completely breaks AES-GCM security.

The Trust Model Difference

	Server-Side Encryption	Zero-Knowledge
Who holds keys?	Service provider	Only you
Can service read files?	Yes	Never
Breach exposes files?	Yes	Encrypted blobs only
Subpoena risk	High	None

Real-World Example

FileShot.io implements this architecture for file sharing. When you upload:

Your file is encrypted in browser memory using AES-256-GCM
The ciphertext is uploaded
The key and IV are embedded in the share URL fragment
The recipient's browser fetches the ciphertext, extracts the key from the fragment, and decrypts locally

The server's database contains only encrypted blobs. Even with full database access, there's nothing readable.

The Bottom Line

"We encrypt your data" from a service provider means nothing unless you hold the keys. Using a service that implements browser-side encryption means the server's trustworthiness becomes irrelevant.

The Web Crypto API makes this implementable in pure JavaScript with no external dependencies.

Trust math, not promises.

How URL Fragments Solve the Key Distribution Problem in Zero-Knowledge File Sharing

FileShot — Tue, 03 Mar 2026 18:28:25 +0000

One of the core challenges in building a zero-knowledge file sharing service is key distribution: how do you give the recipient the decryption key without the server ever seeing it?

The answer has been embedded in the HTTP spec since 1994. It's called the URL fragment.

The Problem

In most "encrypted" file sharing services, the workflow looks like this:

User uploads file
Service encrypts it server-side (using their own keys)
Service sends recipient a download link
Service decrypts the file when the recipient requests it

This is encryption at rest. The service can read every file whenever they want. The encryption protects against disk theft, not against the service itself or its government.

True zero-knowledge means the server is architecturally prevented from decrypting files — not by policy, but by the fact that it never has the key.

The URL Fragment Solution

The HTTP/1.1 RFC 2396 specifies:

"A fragment identifier is separated from the rest of a URI by a hash (#) character and contains additional resource information."

And critically: HTTP clients (browsers) do not include the fragment in requests to servers. The fragment lives entirely in the browser.

This is why anchor links work without a round-trip: when you navigate to page.html#section-3, the browser fetches page.html and then scrolls to #section-3 locally, without telling the server which anchor you navigated to.

Applying This to Key Transport

When a file is shared with zero-knowledge encryption, the share URL looks like:

https://fileshot.io/d/a1b2c3d4e5#AES_KEY_GOES_HERE

When the recipient visits this URL:

Browser sends GET /d/a1b2c3d4e5 to the server — the fragment is stripped
Server has no idea what AES_KEY_GOES_HERE is
Server returns the encrypted ciphertext
Browser extracts the key from location.hash
Browser decrypts the file locally using the Web Crypto API

You can verify this behavior in your browser's DevTools. Navigate to any URL with a fragment and look at the Network tab — the request URL sent to the server will never include the #... portion.

The Implementation with Web Crypto API

Here's the core of how this works in browser JavaScript:

// Encrypt
async function encryptFile(file) {
  const key = await crypto.subtle.generateKey(
    { name: 'AES-GCM', length: 256 },
    true, // extractable
    ['encrypt', 'decrypt']
  );

  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    key,
    await file.arrayBuffer()
  );

  // Export key as URL-safe base64
  const rawKey = await crypto.subtle.exportKey('raw', key);
  const keyB64 = btoa(String.fromCharCode(...new Uint8Array(rawKey)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');

  return { ciphertext, iv, keyFragment: keyB64 };
}

// Decrypt
async function decryptFile(ciphertext, iv, keyFragment) {
  // Re-pad base64
  const padded = keyFragment.replace(/-/g, '+').replace(/_/g, '/');
  const rawKey = Uint8Array.from(atob(padded), c => c.charCodeAt(0));

  const key = await crypto.subtle.importKey(
    'raw',
    rawKey,
    { name: 'AES-GCM', length: 256 },
    false,
    ['decrypt']
  );

  const plaintext = await crypto.subtle.decrypt(
    { name: 'AES-GCM', iv },
    key,
    ciphertext
  );

  return plaintext;
}

The key extracted from location.hash.substring(1) is passed directly to decryptFile. The server never sees it.

The AES-GCM Tag Provides Authentication Too

A detail worth noting: AES-GCM (Galois/Counter Mode) is an authenticated encryption scheme. The 128-bit authentication tag appended to the ciphertext means:

If the ciphertext is tampered with (even one bit), decryption fails with an integrity error
The recipient knows the file hasn't been modified in transit
No separate HMAC is needed

This is why crypto.subtle.decrypt can throw — it's verifying the tag, not just decrypting.

What Can Go Wrong

Shared URLs over insecure channels

If you paste the share URL (including fragment) into an HTTP URL shortener that logs the full URL, or send it over an unencrypted channel that logs messages, the key is exposed. The fragment is only safe because HTTP requests don't include it — any logging of the full URL string exposes the key.

JavaScript injection on the share page

If an attacker can inject JavaScript into the decryption page, they can read location.hash before decryption. This is why zero-knowledge services need careful CSP headers and subresource integrity.

Key derivation vs. raw keys

Passing raw AES keys in URL fragments is fine for ephemeral file sharing. For longer-lived keys, HKDF derivation from a passphrase gives more flexibility and lets you revoke access without sharing the raw key material.

Try It

The implementation described here is the basis of FileShot.io — a zero-knowledge file sharing service with an MIT-licensed backend you can self-host:

git clone https://github.com/FileShot/FileShotZKE.git
cd FileShotZKE/backend && npm install && node server.js

Open DevTools Network tab while using it and watch the upload/download requests — you'll never see a key.

The URL fragment has been part of the web for 30 years. It remains one of the most underused privacy primitives in browser engineering.

Self-Hosting a Zero-Knowledge File Sharing Server in Under 10 Minutes

FileShot — Tue, 03 Mar 2026 18:03:47 +0000

If you share files with teammates, clients, or anyone outside your network, you’re almost certainly trusting a third-party server with your data. Even “encrypted” services often mean encryption in transit — the server still stores your plaintext.

This guide shows you how to self-host FileShot.io, a zero-knowledge file sharing server where the decryption key never reaches the server — ever.

What “Zero-Knowledge” Actually Means

Most file sharing services encrypt data in transit (TLS) and at rest (disk encryption). But the service still holds your encryption keys. If their servers are breached, subpoenaed, or compromised internally, your files are exposed.

Zero-knowledge means the server handles only ciphertext. The key lives nowhere on the server — not even transiently. FileShot implements this using the URL fragment (the # part of the URL), which browsers strip from HTTP requests by specification. The server receives the file but genuinely cannot read it.

The Architecture

Browser                          Server
│                                │
├─ Generate AES-256-GCM key      │
├─ Encrypt file in memory        │
├─ Upload ciphertext ───────────> Store blob (can’t read it)
├─ Construct share URL           │
│    https://yourserver.com/d/{id}#{key}
│                                │
Recipient opens URL              │
├─ Browser strips # fragment       │
├─ Fetch ciphertext ────────────> Serve blob (still can’t read it)
├─ Decrypt with key from fragment  │
└─ File opens in browser           │

The # fragment is a pure client-side transport mechanism. HTTP requests never include it.

Prerequisites

A Linux server (Ubuntu 22.04+, Debian, or any modern distro)
Node.js 18+ installed
A domain or subdomain pointing at your server
nginx or Caddy for reverse proxy (optional but recommended)

Step 1: Clone and Install

git clone https://github.com/FileShot/FileShotZKE.git
cd FileShotZKE/backend
npm install

Step 2: Configure Environment

cp .env.example .env
nano .env

Key settings:

PORT=3000
UPLOAD_DIR=./uploads
MAX_FILE_SIZE=524288000   # 500MB default
FILE_RETENTION_HOURS=72   # Files auto-delete after 72h

Step 3: Start the Server

node server.js

Or with PM2 for production:

npm install -g pm2
pm2 start server.js --name fileshot
pm2 save
pm2 startup

Step 4: Serve the Frontend

The frontend is a static HTML/JS/CSS site — no build step required. Serve it with nginx:

server {
    listen 80;
    server_name files.yourdomain.com;
    root /path/to/FileShotZKE/public_html/public_html;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Then enable HTTPS with Certbot:

sudo certbot --nginx -d files.yourdomain.com

Step 5: Verify Zero-Knowledge Behavior

Open browser DevTools → Network tab. Upload a file. You’ll see:

POST /api/upload — request body is binary ciphertext, not your file
The share URL fragment (#...) is never sent in any network request
Server-side logs show only blob IDs, no key material

You can confirm this by inspecting the payload in Network tab — it’s AES-256-GCM ciphertext, indistinguishable from random bytes.

Production Hardening

Rate limiting:

# nginx rate limiting
limit_req_zone $binary_remote_addr zone=upload:10m rate=10r/m;
location /api/upload {
    limit_req zone=upload burst=5;
    proxy_pass http://127.0.0.1:3000/upload;
}

Auto-cleanup cron:

# Runs every hour, deletes files older than 72h
0 * * * * find /path/to/uploads -mmin +4320 -delete

Fail2ban to block upload abusers — add a filter for excessive 429 responses.

Why This Is Better Than WeTransfer or Dropbox for Sensitive Files

Feature	FileShot (self-hosted)	WeTransfer	Dropbox
Server sees plaintext	No	Yes	Yes
No account needed	Yes	No	No
Self-hostable	Yes	No	No
Open source	Yes	No	No
Key in URL fragment	Yes	No	N/A

Live Demo and Source

Live instance: https://fileshot.io (free, no account)
Source code: https://github.com/FileShot/FileShotZKE (MIT license)

The live instance is what you’re self-hosting here. If you just need instant sharing without self-hosting, fileshot.io works immediately.

Questions about the encryption implementation? Drop them below — happy to walk through the SubtleCrypto API implementation and how the IV, key derivation, and GCM tag are handled.

The Hidden Risk in Every File Sharing Link (And the Zero-Knowledge Solution)

FileShot — Tue, 03 Mar 2026 17:39:18 +0000

Every time you share a file via Google Drive, Dropbox, or WeTransfer, you're making an implicit trust decision: I trust this server to not read my file.

For most files, that's fine. For sensitive files — contracts, credentials, medical records, source code — it's a significant risk that most developers ignore.

The Problem: Server-Side Trust

When you upload a file to a typical sharing service:

Your file travels over HTTPS to their server
Their server stores it (usually encrypted at rest, but they hold the key)
They give you a share link

The server itself can read your file. So can employees with database access, law enforcement with a subpoena, and attackers who compromise their infrastructure.

What "Zero-Knowledge" Actually Means

Two conditions must both be true:

Client-side encryption — the file is encrypted before leaving your browser
Key never reaches the server — the decryption key is delivered out-of-band

HTTPS alone does not count — the server decrypts on arrival. Server-managed encryption does not count — they still hold the key.

The URL Fragment Solution

The hash fragment (#) part of a URL has a critical property: browsers never include it in HTTP requests. This is specified in RFC 3986.

This makes URL fragments a natural out-of-band channel for key delivery.

How FileShot.io Implements This

FileShot.io uses the Web Crypto API for AES-256-GCM encryption entirely in the browser:

// Generate 256-bit AES-GCM key
const key = await crypto.subtle.generateKey(
  { name: 'AES-GCM', length: 256 },
  true,
  ['encrypt', 'decrypt']
);

// Random 96-bit IV (correct for GCM)
const iv = crypto.getRandomValues(new Uint8Array(12));

// Encrypt the file buffer
const ciphertext = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv },
  key,
  fileBuffer
);

// Export key for fragment delivery
const rawKey = await crypto.subtle.exportKey('raw', key);
const b64Key = btoa(String.fromCharCode(...new Uint8Array(rawKey)));
// Share URL: https://fileshot.io/d/FILE_ID + "#" + b64Key

The server receives only the encrypted file and a random file ID — mathematically incapable of decryption.

Practical Implications

Protected against:

Server compromise — attacker gets ciphertext only
Subpoenas — server has nothing to hand over
Employee access — no plaintext stored

NOT protected against:

Compromised browser/endpoint
Sharing the complete URL to an untrusted party

Try It

fileshot.io — no account needed, free, no file size limit.

Self-hosted: github.com/FileShot/FileShotZKE (MIT)

How Zero-Knowledge File Sharing Works: AES-256-GCM in the Browser

FileShot — Tue, 03 Mar 2026 17:12:48 +0000

When you upload a file to most cloud services — Google Drive, Dropbox, WeTransfer — the server receives your file in plaintext before encrypting it on their end. That means they can read it. They have the key.

Zero-knowledge file sharing is different: the server never receives the plaintext file at all. Encryption happens entirely in the browser before a single byte is transmitted.

Here's exactly how it works, using FileShot.io as a working example (MIT open source, self-hostable).

The Core Concept: URL Fragments

The trick that makes zero-knowledge sharing practical is the URL fragment — the part after the #.

https://fileshot.io/d/abc123#AES_KEY_HERE

Browsers never send the fragment to the server. It is not included in HTTP requests, not logged in server access logs, not sent in Referer headers. The #KEY part stays purely client-side.

This is how the decryption key travels with the share link without the server ever seeing it.

The Encryption Flow

Key generation: crypto.subtle.generateKey({ name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"])
Encrypt before upload: File bytes are encrypted with AES-256-GCM locally; the server receives only ciphertext
Key export and encoding: The key is exported and base64url-encoded into the URL fragment
Share: The recipient gets a link like fileshot.io/d/ID#KEY
Decrypt: Recipient's browser extracts the key from location.hash, fetches the ciphertext, decrypts locally

Why AES-GCM Specifically

AES-GCM is an Authenticated Encryption with Associated Data (AEAD) mode. It provides:

Confidentiality: Ciphertext reveals nothing about plaintext
Integrity: Any tampering with the ciphertext is detectable — the subtle.decrypt call will throw an error
Performance: Hardware-accelerated on modern CPUs (AES-NI)

GCM uses a random 96-bit nonce (IV) per encryption operation, which is stored alongside the ciphertext.

What the Server Sees

The server receives:

An opaque blob of ciphertext
A random file ID
An expiry time

The server cannot decrypt the file even if compelled — it has never seen the key.

Try it

FileShot.io is a production implementation of this pattern, free to use, MIT licensed, and self-hostable at github.com/FileShot/FileShotZKE.

Zero-knowledge encryption is not complicated — it just requires keeping the key out of the server's reach entirely.

How I built zero-knowledge file sharing in the browser (AES-256-GCM, keys never leave the client)

FileShot — Tue, 03 Mar 2026 13:58:32 +0000

Most "end-to-end encrypted" tools still send your key to the server at some point. I wanted to build something where the server is architecturally incapable of decrypting your file — not just policy-based, but mathematically impossible. Here's exactly how I built it for FileShot.io.

The core idea: the URL fragment is your vault

The #fragment part of a URL (everything after the #) is never sent to the server. The browser strips it before making any HTTP request. This is a well-known browser spec behavior, but most developers never exploit it for security.

That single fact powers the entire zero-knowledge model:

Generate a random 256-bit AES key in the browser
Encrypt the file with that key using AES-256-GCM
Upload only the ciphertext — the server gets bytes it cannot read
Put the key in the URL fragment: https://fileshot.io/d/abc123#<base64_key>
Share the full URL — the recipient's browser decrypts locally

The server never sees the key. Not during upload, not during download, not ever.

The encryption code

Here's the actual implementation (simplified from production):

async function encryptFile(file) {
  // Generate a fresh key for every file
  const key = await crypto.subtle.generateKey(
    { name: 'AES-GCM', length: 256 },
    true,        // extractable — we need to put it in the URL
    ['encrypt', 'decrypt']
  );

  // Random 96-bit IV — never reuse an IV with the same key
  const iv = crypto.getRandomValues(new Uint8Array(12));

  const plaintext = await file.arrayBuffer();

  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    key,
    plaintext
  );

  // Export key as raw bytes, then base64url-encode it
  const rawKey = await crypto.subtle.exportKey('raw', key);
  const keyB64 = bufferToBase64url(rawKey);

  // IV is prepended to ciphertext so the recipient can extract it
  const blob = new Uint8Array(iv.byteLength + ciphertext.byteLength);
  blob.set(iv, 0);
  blob.set(new Uint8Array(ciphertext), iv.byteLength);

  return { encryptedBlob: blob, keyB64 };
}

After upload, the share URL is assembled as:

const shareUrl = `https://fileshot.io/d/${fileId}#${keyB64}`;

The decryption code

On the recipient's side, the key is read straight from window.location.hash:

async function decryptDownload(encryptedBuffer) {
  const keyB64 = window.location.hash.slice(1); // strip the '#'

  const rawKey = base64urlToBuffer(keyB64);
  const key = await crypto.subtle.importKey(
    'raw', rawKey,
    { name: 'AES-GCM', length: 256 },
    false,       // non-extractable on the recipient side
    ['decrypt']
  );

  // Extract the 12-byte IV prepended during encryption
  const iv = encryptedBuffer.slice(0, 12);
  const ciphertext = encryptedBuffer.slice(12);

  const plaintext = await crypto.subtle.decrypt(
    { name: 'AES-GCM', iv: new Uint8Array(iv) },
    key,
    ciphertext
  );

  return plaintext;
}

No server calls. No key derivation. Just crypto.subtle doing the work locally.

Why AES-GCM specifically?

AES-GCM gives you authenticated encryption — it detects tampering. If someone on the server modified even one byte of the ciphertext, decryption fails with an error. You get both confidentiality and integrity in one primitive.

GCM also produces a 128-bit authentication tag automatically appended to the ciphertext. crypto.subtle handles all of this transparently.

The alternative (AES-CBC) requires a separate HMAC for integrity, is vulnerable to padding oracle attacks if misimplemented, and doesn't parallelize as well. GCM is the right choice for file encryption in the browser.

What the server actually sees

Here's the full picture of what hits the FileShot backend:

Data	Server sees?
File contents	No — only encrypted bytes
Encryption key	No — never transmitted
Original filename	Optional — can be omitted
File size	Yes — needed for storage
Uploader IP	Yes — standard HTTP
Access count	Yes — for link expiry logic

The server is a dumb storage layer. It stores opaque blobs identified by random IDs.

The attack surface I thought hard about

Link interception: If an attacker intercepts the full URL (including fragment), they get the key. This is the fundamental trade-off of fragment-based ZKE — the link IS the key. Mitigations: burn-after-read links, download limits, short expiry times.

Browser history: The fragment appears in browser history. Users should be aware that the shared link persists locally. Open-source desktop apps or Incognito mode address this.

Server-side JS injection: If I served malicious JavaScript that exfiltrated the fragment, ZKE is broken. This is why Subresource Integrity matters — lock your JS with SRI hashes if you want to be rigorous.

Memory attacks: The plaintext lives briefly in the browser's JS heap during encrypt/decrypt. This is unavoidable with in-browser crypto. It's a much smaller window than traditional server-side encryption where plaintext sits at rest.

Performance

Using the WebCrypto API (crypto.subtle) means the browser runs AES-GCM through native code, not a JS polyfill. On modern hardware this saturates network bandwidth:

1 MB file → encrypted and ready in ~8ms
50 MB file → ~400ms encryption time
Upload is I/O bound, not CPU bound

In practice, FileShot completes a 1 MB upload (encrypt + transfer + link ready) in around 1.6 seconds on a decent connection.

Streaming large files

One limitation: crypto.subtle.encrypt requires the full plaintext in memory before producing ciphertext. For files above ~500 MB this is a concern on constrained devices.

The workaround for truly large files is chunked encryption — split the file into 64 MB chunks, encrypt each independently with the same key but unique IVs, upload chunks in parallel, and on download decrypt and stream chunks to disk as they arrive. This is on the FileShot roadmap.

The UX challenge

Zero-knowledge means no password recovery. If you lose the link containing the key, the file is gone forever — you cannot ask the server to "reset" it. This is the correct behavior, but it's jarring for users arriving from Dropbox or Google Drive.

The solution is clear UI copy: "The download link IS the decryption key. Save it." FileShot shows this prominently before the link disappears.

Try it

Everything described here is live at FileShot.io — no account required, free for files up to 50 GB. The zero-knowledge model applies to every file uploaded.

If you're building something similar, the two things worth emphasizing: use AES-GCM (not CBC), and prepend the IV to the ciphertext so the download side doesn't need a separate round-trip to get it.

Happy to answer questions in the comments — especially if you've run into the streaming large files problem.

Building an agentic AI assistant that runs entirely in your browser with no cloud required

FileShot — Tue, 24 Feb 2026 12:28:35 +0000

"Agentic AI" has become a marketing term that means everything and nothing. Most "agentic" tools are just language models with tool use, where the tools make API calls to cloud services, and the orchestration happens on some company's server.

I wanted to build something genuinely different: an agentic assistant where the entire execution — the model inference, the tool calls, the memory — happens on your device.

That's Pocket guIDE.

What "agentic" actually means here

Pocket guIDE can execute multi-step tasks autonomously. Given a goal, it will:

Break the goal into steps
Execute each step (searching, reading, writing, calculating)
Use the output of each step to inform the next
Return a consolidated result

The key distinction from a chatbot: it doesn't just respond to your message. It acts on it over multiple iterations until the task is done.

What tools does it have access to?

The agent has access to:

Web search — via a local search proxy, not through a cloud AI service
Calculator / code execution — runs JavaScript expressions in a sandboxed worker
Note-taking / memory — persists context between sessions in local storage (E:\pocketguidestorage)
Document reading — can process PDFs and text files you drop in
Conversation mode — standard back-and-forth when you don't need multi-step execution

All this happens in the browser. The model inference runs on your CPU/GPU via WebAssembly-compiled llama.cpp (or via a local llama.cpp server if you want faster responses).

The privacy story

Because inference and tool execution are local:

Your conversations aren't logged anywhere — no company has a history of what you've asked
Your files stay on your machine — documents you analyze never leave your device
No API key exposure — there's no key to leak or rotate
Works offline — no internet required for the AI components

The honest trade-offs

Running everything locally means your model is bounded by your hardware. A WebAssembly-compiled 3B model running in the browser is noticeably slower and less capable than GPT-4 over an API.

For tasks that need frontier model capability — complex reasoning, very long context — local models aren't there yet. For everyday assistant tasks, research summaries, and multi-step workflows on local documents, they're surprisingly capable.

The experience is better when running Pocket guIDE with a local llama.cpp server (accessible at localhost) rather than full WASM inference. The server can use your GPU and the larger quantized models.

The architecture

The frontend is a React application that communicates with a local inference backend (llama.cpp server or WASM). The agent loop is implemented in TypeScript:

async function runAgent(goal: string, maxIterations = 10) {
  let context = { goal, steps: [], result: null };

  for (let i = 0; i < maxIterations; i++) {
    const action = await model.decide(context);
    if (action.type === 'finish') return action.result;
    const output = await tools[action.type].execute(action.params);
    context.steps.push({ action, output });
  }
}

The tool system is pluggable — adding a new tool means implementing a simple interface and registering it with the agent.

Try it

Pocket guIDE runs in any modern browser. For the best experience, run a local llama.cpp server alongside it.

pocket.graysoft.dev

Built with: React, TypeScript, llama.cpp (WASM + local server), WebAssembly, IndexedDB

I built a free technical SEO audit tool that requires no login — here's how it works

FileShot — Tue, 24 Feb 2026 12:27:59 +0000

Most serious SEO audit tools sit behind a login, a trial period, or a monthly subscription. Ahrefs, SEMrush, Moz — all great, all expensive. The tools that are free are usually watered-down or lead-gen for upselling.

I wanted to build something that gives a genuinely useful technical audit to anyone, immediately, for free. No signup, no email address, no credit card.

That's SEODoc.

What it checks

Paste a URL and SEODoc crawls the page and generates a report covering:

Technical health:

HTTP status codes and redirects
Page speed and Core Web Vitals estimates
Mobile-friendliness indicators
HTTPS and security headers
Canonical tags and hreflang

On-page SEO:

Title tag length, uniqueness, keyword presence
Meta description length and quality signals
Heading hierarchy (H1-H6) analysis
Image alt text coverage
Internal/external link audit

Structured data:

Schema.org markup detection and validation
Open Graph and Twitter Card tags
JSON-LD validation

Crawlability:

Robots.txt analysis
Sitemap detection and validation
Noindex/nofollow tag detection

The output is a structured report with pass/fail indicators and specific recommendations for each issue found.

The technical approach

The backend is a Python FastAPI application. The crawling is done with a combination of Playwright (for JavaScript-rendered pages) and BeautifulSoup (for static HTML parsing). This means it handles modern SPAs properly, not just server-rendered HTML.

The Core Web Vitals estimation uses Lighthouse programmatically via headless Chrome. The structured data validation uses Google's structured data testing logic.

@app.post("/audit")
async def run_audit(request: AuditRequest):
    crawler = SEOCrawler(request.url)
    results = await crawler.run_full_audit()
    return AuditResponse(
        technical=results.technical,
        onpage=results.onpage,
        structured_data=results.structured_data,
        recommendations=results.prioritized_recommendations()
    )

Why no login

Every "free SEO tool" I've seen uses the no-login experience as a lead funnel. You get the results and then hit a wall: "Sign up to see the full report." I wanted to do the opposite — give the full report upfront, no strings.

The business model is batch auditing and scheduled monitoring, which is a paid feature for when you want to run audits on 50 pages regularly. The one-off audit is just free.

What I learned building it

JavaScript-rendered pages are a surprisingly large percentage of the modern web. If you only use requests + BeautifulSoup, you miss entire categories of content and issues. Running Playwright for every audit adds latency but is necessary for accuracy.

Core Web Vitals are genuinely hard to estimate without running real browser measurement. The Lighthouse approach is good enough for directional guidance but not as reliable as field data from CrUX.

Try it at seodoc.site.

Built with: Python, FastAPI, Playwright, BeautifulSoup, Lighthouse, Pydantic

Building a marketplace for indie developers to buy and sell projects, domains, and templates

FileShot — Tue, 24 Feb 2026 12:27:24 +0000

Indie developers build a lot of things that don't go anywhere. A side project that got to MVP and stalled. A domain with a good name that never got built out. A template built for one project that would genuinely save someone else weeks of work.

The problem is there's nowhere great to sell these.

Flippa is overkill (and expensive) for anything generating under $1K/month. Reddit's r/entrepreneur has occasional "for sale" posts but no proper listing format, no discovery, no escrow. Most of the time, that domain or side project just sits around gathering dust.

iStack is my answer to that gap.

What you can list

Side projects — Fully working apps and websites, with or without revenue
Domains — Good domain names with or without existing traffic
Templates — Code templates, UI kits, starter projects (like the kind I sell through DiggaByte)
SaaS products — Software businesses at any stage
Code packages — One-off scripts, libraries, components

How it works

Sellers create a listing with description, tech stack, revenue (if any), traffic stats, and asking price. The listing stays up until sold or removed.

Buyers can browse by category, price range, tech stack, or revenue tier. There's no intermediary blocking contact — interested buyers message sellers directly and negotiate terms.

For higher-value transactions, the platform facilitates escrow through a third-party provider so neither party is taking a blind leap of faith.

Built with

The stack is Next.js App Router + Prisma + PostgreSQL. User accounts, listing management, messaging, and escrow integration. Authentication via NextAuth.

One deliberate constraint: no algorithmic feed, no engagement-bait ranking. Listings are sorted by recency and category. The browsing experience is meant to feel like a classifieds board, not a social feed.

Why build this

I've had side projects I wanted to sell and had nowhere to list them. I've had domains I wanted to offload and ended up just letting them expire. The existing platforms are either too focused on big revenue businesses or too informal to give buyers any confidence.

There's a real market for "decent indie thing, reasonable price, no drama" transactions.

Explore listings at istack.site.

Built with: Next.js, Prisma, PostgreSQL, NextAuth, TypeScript, Tailwind

Building automated crypto trading bots with copy trading — what I learned

FileShot — Tue, 24 Feb 2026 12:26:48 +0000

Algorithmic trading is one of those areas where the gap between "sounds simple" and "is actually complex" is enormous.

The basic loop sounds easy: watch prices, detect a signal, place an order. But production-grade algotrading infrastructure needs to handle exchange API rate limits, partial fills, order state reconciliation across disconnects, risk management overrides, and a dozen other edge cases that only show up when real money is on the line.

That's what I spent months building into ZipDex.

What ZipDex does

ZipDex is a crypto trading automation platform with three main features:

1. Strategy bots
Rule-based trading strategies you can configure without writing code. Common strategies like grid trading, DCA (dollar-cost averaging), MACD/RSI signal bots, and more. Set your parameters, connect your exchange API keys, and let it run.

2. Copy trading
Follow other traders' strategies automatically. When a trader you follow opens a position, your account mirrors it proportionally. This is the feature that took the longest to build correctly — the synchronization logic between the source account and all mirror accounts is genuinely tricky.

3. AI-assisted strategies
LLM-powered analysis layered on top of technical indicators. Not autonomous trading — more like a second opinion before entries. The AI component reads market context and sentiment and flags conditions where standard indicators might be misleading.

The hard parts

Exchange connectivity — Crypto exchanges have wildly inconsistent APIs. Rate limits vary, error codes aren't standardized, and WebSocket reliability is a joke on some platforms. I built an abstraction layer over the top of ccxt to normalize this.

Order reconciliation — WebSocket connections drop. When you reconnect, you need to reconcile your local order state with the exchange's actual state. Getting this wrong means missing fills or double-executing orders. This was the most failure-prone part of the system to build.

Risk management — Position size limits, maximum drawdown stops, per-trade risk percentages. These need to run synchronously before any order is placed and cannot be bypassed by any strategy. I built these as a non-negotiable layer that every order passes through.

Copy trading latency — When copying a trader, latency matters. A 500ms delay on a fast-moving entry can mean a significantly different fill price. The copy execution pipeline is one of the most optimized parts of the system.

What it's built with

Node.js backend with a Redis queue for order execution, PostgreSQL for trade history and state, WebSocket connections maintained with exponential backoff reconnection, and a React frontend for configuration and monitoring.

The AI component uses local LLM inference so no trading data leaves the machine.

Check it out at zipdex.io.

Built with: Node.js, Express, Redis, PostgreSQL, WebSockets, ccxt, React