Aleph Hackathon

What it does You run a command. Someone on another machine watches the output live, and can scroll back through everything that already happened — the warning three minutes ago, the line before the stack trace — while your command keeps writing. Nothing pauses on your side. Nothing is uploaded to anyone's servers.

Why the transport is the product The output does not travel over a socket. It is appended to a Hypercore: a signed, encrypted, append-only log that replicates over Hyperswarm.

Three properties fall out of that single decision instead of being built:

Rewind while live. Every block the viewer replicated is already on their disk. Scrolling back is a local read, not a request to the broadcaster. History for latecomers. Someone joining twenty minutes in replicates from block 0 and sees the entire session. A socket would give them only what happened after they arrived. A record that cannot be rewritten. The log is signed. Blocks can be appended, never altered or removed — not even by the person who produced them. A socket makes you present at the exact moment or you lose the output. A log lets you arrive late, leave, come back, and rewind — while the source keeps writing.

How it works Each session creates a fresh Hypercore with a new key pair and a new 32-byte encryption key. Captured output is grouped by a chunker — cut on stream change, at 64 KiB, or after 50 ms — and appended as one block: { ts, stream: 'out' | 'err', data }. A block never mixes stdout with stderr, and ordering comes from the block index, never from the timestamp. Cursor and screen-control escape sequences are stripped before storage so a broadcast cannot repaint the viewer's interface. Colour is kept. The swarm topic is the core's discovery key, never the encryption key — the DHT never learns how to read the log. The share string is 103 characters of z32 carrying two 32-byte keys. It cannot be shortened: deriving both from one seed would halve it and hand every viewer the secret key, letting them forge blocks. The length is the price of a viewer that can decrypt but cannot write. So the share is copied to the clipboard at both ends instead — nobody drags a mouse across 103 characters. Pear stack Built from hello-pear-bare, main branch — networking and the OTA updater in a Bare worker thread. Runs on Bare, not Node: bare-subprocess, bare-stdio, bare-fs, bare-tty, bare-env, bare-path, bare-os. Hypercore + Corestore + Hyperswarm for transport and replication. Distributed peer-to-peer with the Pear CLI. One command installs a standalone binary that carries its own runtime — the machine needs neither Node nor Pear to run it. OTA updates verified end to end, twice, by comparing SHA-256 hashes of the installed binary before and after: it replaced itself from the swarm in under 100 seconds with nothing touched by hand. Try it Then, in two terminals:

Viewer keys: ↑ ↓ scroll, g jump to the start, G back to live, q quit. rewind cat streams to stdout for piping instead.

Tested 89 tests, 258 assertions, run on Bare with brittle. Coverage includes the block and share schemas, chunk cutting, ANSI sanitising, PATH resolution, clipboard round-trips, the viewer's LIVE/REWIND state machine, and real replication between two Corestores over a live swarm. Cross-machine behaviour was additionally verified by hand on two physical machines.

Known limitations No pseudo-terminal: rewind captures a command's output streams, not a terminal session. Full-screen programs that repaint the screen are out of scope. The command's stdin is closed, so interactive shells exit immediately. Windows x64 is the tested target; other platforms build from the same scripts but were not exercised. Links Repository: https://github.com/Rom4n10/rewind Pear link: pear://zgikobhxeb4qwki43qr8b6b43yoes6jjp7pmcdqwobsi7pdxxuxo