The Unrecorded School: Ephemeral, Accountless Peer-Learning Rooms

The Unrecorded School (TUS) is a web-based platform that reimagines online learning as a private, temporary, and direct human experience. Instead of user accounts, profiles, progress tracking, or recommendation algorithms, TUS offers ephemeral rooms tied to a specific topic and a fixed duration. A room is spawned via a unique link; participants join by simply following that link. No name, no email, no cookie—just a placeholder label like 'Student 5' that disappears when the session ends. The room has a chat, a shared whiteboard, and a collaborative text editor. The host (the link creator) can set a topic, a timer (e.g., 60 minutes), and a few ground rules. After the timer expires, the room and all its content are permanently deleted from the server. There is no database of users, no log of chat messages, no analytics. The only persistence is an optional, encrypted export that the host can download before the room dissolves. The architecture uses WebRTC for peer-to-peer communication to minimize server storage, and a lightweight signaling server that retains no connection metadata. Moderation is handled by the host in real-time (mute, remove) and via community norms—since there is no identity, bad behavior has no lasting consequence, so the design leans on short sessions and positive incentives. The project never got past a proof-of-concept because building robust moderation without accounts proved technically and ethically thorny, and the team couldn't reconcile the ideal of zero data with the pragmatic need for basic abuse prevention.

Current online learning platforms are data-hungry. They track every click, every pause, every wrong answer to build profiles and feed algorithms. This creates a chilling effect on curiosity—students self-censor, afraid of being judged or profiled. Moreover, the requirement to create an account is a barrier to spontaneous learning. You can't just drop into a study group for 20 minutes without committing your identity and data. The Unrecorded School addresses the itch for private, low-friction, and temporary collaborative learning spaces that exist purely for the sake of learning, not for data extraction.

• Enable anyone to create a learning room with a single click, no registration.
• Ensure zero data retention: no logs, no accounts, no cookies, no analytics.
• Make rooms ephemeral: auto-delete after the set duration (e.g., 15/30/60/120 minutes).
• Provide real-time collaboration tools: chat, whiteboard, shared text editor, screen share.
• Allow hosts to download an encrypted transcript before deletion.
• Keep the platform fast and lightweight, running on minimal infrastructure (static site + signaling server).
• Intentional design to prevent abuse through short durations and host controls (mute, remove, report).

• No user accounts, profiles, or any persistent identity.
• No content moderation beyond real-time host actions—no AI flagging, no post-hoc review.
• No recommendation engine, no personalization, no learning analytics.
• No monetization through data or advertising; if ever funded, only via donations or grants.
• No mobile apps—the web is enough to avoid app store tracking.
• No encryption at rest (since nothing is stored), only optionally encrypted export.

Frontend: React (with hooks) for UI, using WebRTC (via simple-peer) for peer-to-peer data channels and video/audio. Shared whiteboard: Fabric.js or tldraw embedded. Collaborative text editor: Yjs (CRDT) over WebRTC. Backend: minimal signaling server in Node.js (ws or Socket.IO) that only helps peers discover each other and then forgets them. No database—just an in-memory map of active room IDs, which resets on server restart. Hosting: static site on Netlify or Vercel; signaling server on a small VPS (e.g., $5/month DigitalOcean). No CDN for dynamic content. Optional: a simple STUN/TURN server (coturn) for NAT traversal.

The architecture is intentionally stateless and decentralized. Every room exists only in the memory of its participants and the signaling server during the session. A user creates a room by hitting the 'Start a Room' button, which generates a random 6-word slug (e.g., 'quiet-hippo-dance-44'). The slug is added to the signaling server's active rooms set. The creator gets a URL: tus.org/room/quiet-hippo-dance-44. When participants open that URL, their browser loads the static web app and connects to the signaling server via websocket. The signaling server facilitates a WebRTC handshake and then forgets the participant's address. After the handshake, all data (chat, whiteboard edits, cursor positions) flow directly peer-to-peer via WebRTC data channels. A single 'host' (the creator) can set the timer and moderate. When the timer expires, the host's browser sends a 'self-destruct' signal to all peers, which clears local state and disconnects. The signaling server also deletes the room entry. There is no server-side logging of messages or metadata. For the encrypted export, the host's browser compiles the session data, encrypts it with a key derived from the room slug, and prompts a download. The server never sees this data.

• Moderation without identity: a determined bad actor could disrupt multiple sessions. Mitigation: short durations, host controls (mute, remove), and the option to make rooms invite-only via a link that expires.
• Technical complexity of WebRTC on diverse networks: some users behind strict NATs may struggle. Mitigation: offer a TURN server as fallback, but that adds cost and logs IPs—a trade-off we were uneasy about.
• Lack of persistence means no 'library' of past learning—valuable content is lost. That's by design, but some users may find it frustrating.
• Scalability of signaling server: heavy traffic could overwhelm a simple in-memory store. Mitigation: use Redis or a similar ephemeral store, but that adds complexity and a point of data accumulation.

• Can we make host moderation effective enough without persistent identity? Should we allow hosts to create a temporary, client-side 'block list' that persists locally?
• Is it ethical to provide an encrypted export if the host could be compelled to disclose it? Should we not offer export at all?
• Should we support audio/video? It increases bandwidth and could attract harassment. Would text-only be safer?
• How do we handle illegal content (e.g., child exploitation) without any logs? The classic conundrum: privacy vs. safety. The trade-off might be too risky for a real launch.

The core tension between absolute privacy and minimal abuse prevention kept the team in a loop—every solution to moderation (captchas, rate limits, reputation scores) eroded the zero-data promise. Life moved on, and the project faded as members took jobs at more conventional edtech companies. The proof-of-concept is still on GitHub, untouched since 2022.

The project was inspired by the ephemeral chat room model of platforms like Bindle and the privacy advocacy of the Mastodon community. A working prototype was demoed internally but never deployed publicly due to moderation concerns. The question remains: can a truly private learning space exist at scale?