Forem: kiyo-e

Zero Egress Costs: How I Built P2P File Sharing with Cloudflare

kiyo-e — Fri, 09 Jan 2026 05:05:27 +0000

TL;DR

I built a P2P file sharing tool where files transfer directly between browsers. The server only handles WebRTC signaling — actual files never touch it. Transfer a 10GB file? Still zero egress costs. The stack: Hono + Cloudflare Workers + Durable Objects + STUN.

Demo: https://share-files.karakuri-maker.com/

Repo: https://github.com/kiyo-e/p2p-share-files

The Problem: Egress Costs Add Up Fast

Every file sharing service charges you for bandwidth. S3, R2, whatever — you pay for every byte that leaves the server.

I ran the numbers for a simple use case: sharing large video files with a few friends. Even with Cloudflare R2's "generous" free tier, a few 4GB files per month and I'm paying. Scale that to actual users? The bill gets ugly.

I wanted something different: zero transfer costs, regardless of file size.

The answer was obvious in hindsight — don't let files touch the server at all.

The Solution: WebRTC + Cloudflare

WebRTC lets browsers talk directly to each other. No server in the middle. The catch? You still need a server for "signaling" — exchanging connection info so browsers can find each other.

Here's the architecture:

┌─────────────┐         ┌─────────────────────┐         ┌─────────────┐
│   Sender    │◄───────►│   Durable Object    │◄───────►│  Receiver   │
│             │   WS    │   (signaling only)  │   WS    │             │
└─────────────┘         └─────────────────────┘         └─────────────┘
       │                                                       │
       │                                                       │
       └──────────────────── WebRTC P2P ───────────────────────┘
                         (files go here)

Signaling messages are tiny — a few KB. Files flow directly between browsers. The server never sees them.

The Stack

Layer	Tech	Why
Framework	Hono	TypeScript-first, perfect Cloudflare integration
Hosting	Cloudflare Workers	Edge deployment, cheap
State	Durable Objects	WebSocket connections + room state
NAT traversal	Cloudflare STUN	Free, same vendor

Everything stays within Cloudflare. One wrangler deploy and it's live.

Why Durable Objects?

Workers are stateless. That's usually fine, but signaling needs state — you need to track who's in which room, and relay messages between them.

Durable Objects solve this perfectly. Each room gets its own instance:

app.get('/ws/:roomId', (c) => {
  const roomId = c.req.param('roomId')
  const id = c.env.ROOM.idFromName(roomId)
  const stub = c.env.ROOM.get(id)
  return stub.fetch(c.req.raw)
})

The Durable Object handles all WebSocket connections for that room. When someone sends an offer, it relays to the right peer. Simple.

export class Room extends DurableObject {
  async fetch(request: Request): Promise<Response> {
    const clientId = new URL(request.url).searchParams.get('cid') 
      ?? crypto.randomUUID()

    this.closeDuplicateClient(clientId)  // Handle reconnects

    const pair = new WebSocketPair()
    this.ctx.acceptWebSocket(pair[1])

    return new Response(null, { status: 101, webSocket: pair[0] })
  }

  webSocketMessage(ws: WebSocket, message: string) {
    // Relay signaling messages to the right peer
  }
}

The Hard Part: Reconnection

Getting the initial connection working took a day. Making reconnection reliable took a week.

Problem 1: Ghost Connections

User reloads the page. Browser closes WebSocket. But Durable Object doesn't know immediately — there's a delay before webSocketClose fires. New connection comes in, now you have duplicates.

Fix: Client IDs stored in localStorage.

function getClientId() {
  const stored = localStorage.getItem('client-id')
  if (stored) return stored
  const id = crypto.randomUUID()
  localStorage.setItem('client-id', id)
  return id
}

When a new connection arrives with the same client ID, force-close the old one:

private closeDuplicateClient(clientId: string) {
  for (const socket of this.ctx.getWebSockets()) {
    const attachment = socket.deserializeAttachment()
    if (attachment?.cid === clientId) {
      socket.close(1000, 'replaced')
    }
  }
}

Problem 2: Stale Signaling Messages

Old offer/answer messages from the previous session arrive after reconnection. They mix with new session messages. Everything breaks.

Fix: Session IDs on every signaling message.

const sendOffer = async (peer: OffererPeer) => {
  const sid = ++peer.signalSid  // Increment on every new offer
  peer.activeSid = sid

  const offer = await peer.pc.createOffer({ iceRestart: true })
  await peer.pc.setLocalDescription(offer)

  send({ type: 'offer', to: peer.peerId, sid, sdp: offer })
}

// Receiving side: ignore mismatched session IDs
if (msg.sid !== peer.activeSid) return

Client IDs handle duplicate connections. Session IDs handle stale messages. Both together finally made it stable.

The No-TURN Trade-off

I deliberately skipped TURN servers.

TURN relays traffic through a server when P2P fails (strict corporate firewalls, symmetric NAT). But that defeats the whole point — files would go through my server, and I'd pay egress.

Without TURN, some corporate networks won't work. That's the trade-off. For my use case — sharing files with friends and colleagues on normal networks — STUN alone works fine.

If I needed to support stricter environments, I'd add TURN as an option and charge for it. But the free tier stays P2P-only.

Bonus: E2E Encryption

Optional E2E encryption using URL fragments:

https://example.com/room/ABC123#k=Base64EncodedKey

The # fragment never hits the server. Cloudflare Workers never see the key. Only browsers sharing the link can decrypt.

What I Learned

Durable Objects are underrated. Everyone talks about Workers, but Durable Objects are what make stateful edge applications possible. WebSocket management, room state, connection queueing — all in one primitive.

WebRTC reconnection is painful. The happy path works quickly. The reconnection edge cases take 10x longer. Budget for it.

TURN is a business decision, not a technical one. You can always add it later. Starting without it keeps costs at zero and forces you to validate whether P2P alone is good enough.

The Cloudflare stack is underrated for real-time apps. Workers + Durable Objects + STUN. No external dependencies. One deploy command. It just works.

The best file transfer is the one that never touches your server.

Demo: https://share-files.karakuri-maker.com/

Code: https://github.com/kiyo-e/p2p-share-files

Turn a Hono App into a Debuggable CLI (No Server, Just app.fetch)

kiyo-e — Sat, 03 Jan 2026 01:24:13 +0000

If you've ever built a CLI and hated the edit-run-repeat loop, this pattern helps:

Put all business logic in a Hono app
Call it from the CLI via app.fetch() (no HTTP server)
Keep the adapter pure: no stdout/stderr writes, your CLI owns the output

This post shows a minimal setup, how argv maps to URL/query/body, and optional OpenAPI-powered --help.

TL;DR

hono-cli-adapter lets you call Hono apps directly from the CLI
Your logic stays in Hono—debug with Postman, ship as CLI
Zero stdout writes; your CLI controls all output
Same Hono app works for CLI, HTTP, and MCP servers

The Problem

Debugging CLI tools is tedious. Run, tweak args, run again. No request history, no easy inspection.

What if your CLI logic lived behind HTTP endpoints instead? You'd get Postman for debugging, saved requests for regression tests, and a single source of truth for both CLI and API.

What I Built

hono-cli-adapter — a thin library that converts CLI arguments into HTTP requests and calls your Hono app's app.fetch() directly.

No actual HTTP server needed. Just your Hono app and a few lines of CLI glue.

Getting Started

Install:

npm install hono-cli-adapter

First, your Hono app (this is the logic you want to call from CLI):

// app.ts
import { Hono } from 'hono'
export const app = new Hono()

app.post('/hello/:name', (c) => c.text(`Hello, ${c.req.param('name')}!`))
app.post('/create-user', async (c) => {
  const body = await c.req.json()
  return c.json({ ok: true, user: body })
})

Then, your CLI (just 4 lines):

#!/usr/bin/env node
// cli.ts
import { cli } from 'hono-cli-adapter'
import { app } from './app.js'

await cli(app)

Run it:

node cli.js hello Taro
# -> Hello, Taro!

node cli.js create-user -- name=Taro email=taro@example.com
# -> {"ok":true,"user":{"name":"Taro","email":"taro@example.com"}}

node cli.js --list   # List available routes
node cli.js --help   # Show help

That's it. The same app.ts works with Postman during dev, as an HTTP API in production, and now as a CLI.

How argv Maps to HTTP

CLI input	Becomes
`hello Taro`	Path segments (`POST /hello/Taro`)
`--foo=bar`	Query string (`?foo=bar`)
`-- key=value`	JSON body (`{"key":"value"}`)
`--env KEY=VALUE`	Env overlay (highest priority)

How It Works

Three design constraints:

1. Thin CLI, fat Hono

All business logic lives in Hono. The CLI just handles flags and output. This keeps behavior consistent between CLI and HTTP, and makes your Hono app fully testable on its own.

2. No side effects

The library never touches stdout. You decide how to format output:

const { code, lines } = await runCli(app, process)
for (const l of lines) console.log(l)  // or JSON.stringify, or pipe somewhere
process.exit(code)

3. POST-only

CLI commands trigger actions. POST makes sense. GET support can come later if needed.

MCP Server Support

Here's where Hono really shines. The same app works as:

┌─────────────┐
│   app.ts    │  ← Your business logic (single source of truth)
└─────────────┘
       │
       ├──→ cli.ts (hono-cli-adapter) → CLI
       ├──→ server.ts (Hono serve)    → HTTP API
       └──→ mcp.ts (mcp-hono-adapter) → MCP Server

Just swap the entrypoint. No logic duplication. If you're building MCP tools, this pattern saves a ton of maintenance.

Advanced Usage

Environment Variables

Three layers, last wins:

// 1. process.env (base)
// 2. options.env (adapter config)
// 3. --env flags (highest priority)

await cli(app, process, { env: { API_URL: 'https://dev.example.com' } })

node cli.js do-thing --env API_KEY=secret-123

beforeFetch Hook

Transform requests per command:

await adaptAndFetch(app, process.argv.slice(2), {
  beforeFetch: {
    upload: async (req, argv) => {
      if (argv.file) {
        const buf = await fs.readFile(argv.file)
        const headers = new Headers(req.headers)
        headers.set('content-type', 'application/octet-stream')
        return new Request(req, { body: buf, headers })
      }
    }
  }
})

OpenAPI Integration

Pass a spec to enrich --help:

await runCli(app, process, { openapi: myOpenApiSpec })

Shows parameter types, required/optional, descriptions. Pairs well with hono-openapi.

Gotchas

listPostRoutes uses Hono internals

It inspects Hono's internal router structure. May break on major Hono updates. For production, consider maintaining your own route list.

ESM only

No CommonJS. Node 18+ required.

Wrapping Up

Hono + CLI is a pattern that deserves more attention. You get web tooling during dev, trivial MCP support, and a testable core—all without duplicating logic.

Check it out: github.com/kiyo-e/hono-cli-adapter

Building a Simple MCP Server That Just Returns the Current Time

kiyo-e — Fri, 19 Dec 2025 13:52:10 +0000

TL;DR

Long conversations with ChatGPT/Claude lose track of real time
Built a simple MCP server that returns the current time
Deploy it on Cloudflare Workers, register as a custom connector
URL: https://what-time.kiyo-e.com/mcp
Repo: github.com/kiyo-e/time-mcp

The Problem

I use ChatGPT's scheduled tasks feature to check my Google Calendar and Tasks every morning. Throughout the day, I discuss tasks and schedules with it while working.

Here's the issue: ChatGPT only knows the time from when the conversation started (via the system prompt). As the conversation continues, its sense of time drifts. It might mention an upcoming meeting that already happened, or suggest afternoon tasks when it's already evening.

This small disconnect becomes surprisingly frustrating.

The Solution

I built an MCP server that does exactly one thing: return the current time.

https://what-time.kiyo-e.com/mcp

Register this as a custom connector in ChatGPT or Claude, and instruct the LLM to check the time before discussing schedules. Now it always knows "what time it is."

Implementation

Built with Cloudflare Workers + MCP SDK. The entire implementation is about 50 lines.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { createMcpHandler } from 'agents/mcp';
import { z } from 'zod';

const server = new McpServer({
  name: 'mcp-time-worker',
  version: '0.2.0'
});

server.tool(
  'get_time',
  'Returns the current date and time (to the second) in a given IANA time zone.',
  z.object({
    timezone: z.string().describe('IANA time zone, e.g. Asia/Tokyo').optional()
  }),
  async ({ timezone }) => {
    const tz = timezone || 'Asia/Tokyo';
    const now = formatTime(tz);
    return {
      content: [{ type: 'text', text: now }],
      metadata: { timezone: tz }
    };
  }
);

The get_time tool returns the current time in ISO 8601 format like 2025-06-15T14:30:45+09:00. You can specify any IANA timezone (Asia/Tokyo, America/New_York, etc.).

The time formatting uses Intl.DateTimeFormat with UTC offset calculation:

function formatTime(tz: string): string {
  const now = new Date();
  const parts = new Intl.DateTimeFormat('en-CA', {
    timeZone: tz,
    year: 'numeric',
    month: '2-digit',
    day: '2-digit',
    hour: '2-digit',
    minute: '2-digit',
    second: '2-digit',
    hourCycle: 'h23'
  }).formatToParts(now)
    .reduce<Record<string, string>>((acc, p) => {
      if (p.type !== 'literal') acc[p.type] = p.value;
      return acc;
    }, {});

  // Calculate UTC offset
  const utc = new Date(now.toLocaleString('en-US', { timeZone: 'UTC' }));
  const zoned = new Date(now.toLocaleString('en-US', { timeZone: tz }));
  const offsetMinutes = (zoned.getTime() - utc.getTime()) / 60000;
  // ... build offset string and return
}

Setup Guide

ChatGPT (Pro / Plus)

Go to Settings → Apps & Connectors → Advanced settings and enable "Developer Mode"
Click Create connector
Enter:
- Name: What time is it? (or anything you like)
- URL: https://what-time.kiyo-e.com/mcp
- Authentication: None
In chat, click + icon → select your connector to enable it

Claude (Pro / Max / Team)

Click the Search and tools icon in the chat interface
Select Manage connectors
Click Add custom connector
Enter:
- Name: What time is it?
- URL: https://what-time.kiyo-e.com/mcp

Then instruct the LLM: "Always check the current time before discussing schedules or tasks."

Takeaways

Cloudflare Workers made this trivially easy. Write some code, deploy instantly, zero maintenance. Perfect for small utilities like this.

MCP as a protocol is proving its value. Even something as simple as "return the current time" becomes useful when you can inject accurate context into LLM conversations. The standardization means this one server works with both ChatGPT and Claude.

Conclusion

Problem: LLMs lose track of time in long conversations
Solution: A simple MCP server that returns the current time
URL: https://what-time.kiyo-e.com/mcp
Source: github.com/kiyo-e/time-mcp

Give it a try.

Hello World

kiyo-e — Thu, 18 Dec 2025 13:31:03 +0000

Welcome to My Tech Blog

This is my first post on this tech blog. I'll be sharing my thoughts and experiences on software development, programming, and technology.

Stay tuned for more content!

Why Claude's Custom Connector Failed on Cloudflare (and How I Fixed It)

kiyo-e — Thu, 18 Dec 2025 13:31:02 +0000

TL;DR

I built a custom connector API on Cloudflare Workers that worked perfectly with ChatGPT but failed with Claude. The culprit? Cloudflare's "AI Bot" blocking feature. Turning it off in Security → Bots fixed the issue instantly.

The Problem

I was building a custom connector that works with both ChatGPT and Claude. Hosted it on Cloudflare Workers, tested with ChatGPT—worked fine. Then I tried Claude with the exact same setup. Connection error. Every. Single. Time.

Same API, same endpoint, same configuration. Why would Claude fail when ChatGPT succeeded?

The Solution

Cloudflare's security settings were blocking Claude.

Specifically, under Security → Bots, the "Block AI Bots" option was set to "Block on all pages." Switching this to "Off" allowed Claude to connect immediately.

The Debugging Journey

Here's how I tracked down the issue:

Step 1: Initial Setup

Created the connector API on Cloudflare Workers and deployed it to a custom domain. Configured ChatGPT's connector feature, ran the connection test. Success. Requests were logged, responses were correct.

Step 2: Claude Fails

Set up Claude with the identical endpoint. Connection test failed with a generic "Cannot connect" error—no details, no hints.

Checked my configuration multiple times. Everything looked correct.

Step 3: Checking the Logs

This is where things got interesting. I opened Cloudflare Workers logs and found that Claude's requests never reached the Worker. ChatGPT's requests were logged, but nothing from Claude.

Step 4: Ruling Out Application Code

Maybe my code had some edge case? I rebuilt the entire app from scratch—just authentication, nothing else. Deployed it. Same result. Claude still couldn't connect.

So the application code wasn't the problem.

Step 5: The Breakthrough

On a hunch, I tried connecting using the default *.workers.dev URL instead of my custom domain.

It worked.

Same app, same Claude configuration—different URL. That was the clue I needed. The issue had to be domain-specific.

Step 6: Finding the Setting

Went to Cloudflare Dashboard → Security → Bots. Found "Block AI Bots" enabled with "Block on all pages" selected.

Changed it to "Off," saved, and ran Claude's connection test again.

Success. Finally.

Why This Happened

Cloudflare treats different AI services' User-Agents differently. ChatGPT apparently wasn't flagged, but Claude was. This makes sense for protecting regular websites from AI scraping, but it breaks legitimate API integrations.

The *.workers.dev domain doesn't inherit your custom domain's security settings, which is why it worked as a bypass.

Key Takeaway

If you're hosting a custom connector on Cloudflare and Claude won't connect:

Go to Security → Bots in your Cloudflare dashboard
Find "Block AI Bots"
Set it to Off

That's it. A 30-second fix for hours of debugging.

Conclusion

The frustrating part was that ChatGPT worked fine, which sent me down the wrong debugging path. I assumed the issue was Claude-specific—maybe different auth requirements, maybe a bug in my code.

Turns out it was just Cloudflare doing its job a little too well.

Hope this saves someone else the headache.