Aleph Hackathon

Install

pear install pear://8uss8m4b53cndz5sdexo8xbjyn5b1ccr7455y7fmay7yedw3kbey

Seeded through judging.

Platforms

Binaries are built for macOS arm64 and x64, Linux arm64 and x64, and Windows x64. All five ship in the same drive and pear install pulls the one your machine needs. Only macOS arm64 has actually been tested, on a MacBook Pro M5. The others compile but the capture path has never been run there.

The problem

You get through the screen, the take home, the system design. Then the last round goes badly. You were nervous, you stutter, or you just had a bad day. A live interview measures two things at once: whether you can do the work, and whether you can explain it out loud, in real time, to a stranger. Both are real skills. They are not the same one.

What it does

• the interviewer records a question and gets an invite
• the candidate redeems it, hears the question, and replays it as often as they want
• record, listen back, re-record. Only the chosen take is sent
• the interviewer hears one answer and how many attempts it took, never the attempts
• follow-ups and new questions continue the session
• the interviewer can end it with an offer, and the candidate gets confetti
• transcription and answer review run on-device, no API key, no network call

Why peer-to-peer

The moment you let someone re-record, you have to answer where the discarded takes go. On any hosted platform the answer is someone's bucket and a promise. Here the takes live in a scratch folder on the candidate's machine and are deleted on send or on quit. Delete actually deletes, because there was never a second copy.

How it works

Pairing. The invite is a blind-pairing invite, not the session key. It grants nothing until the interviewer confirms, and only then does the candidate learn the key both sides hash into a topic. No registration server.

Storage. One Hyperdrive per side: Hyperbee for metadata, Hyperblobs for audio. The audio is never sent. Each side writes into its own drive and passes the key, and the other replicates and reads. drive.put runs once per turn, at send.

Protocol. A Protomux channel beside the pairing one, since blind-pairing already muxes that connection. Messages are generated by Hyperschema and wrapped so decode also vets ranges, key validity and path traversal.

Local models. QVAC through @qvac/bare-sdk. Whisper tiny for speech, Qwen3 for the review. Only speech blocks startup, and the review model downloads behind the session.

Built on

hello-pear-bare, main variant, with pear-runtime in a Bare worker thread. A session is long lived and the main thread is busy with raw mode TTY, timers and blocking local inference. variant/daemon is for one-shot commands that exit. variant/single-thread would put replication behind that inference.

OTA

Released with pear touch, pear build, pear stage, pear provision and pear seed. The demo shows an update reaching an installed copy: the version on screen changes, the doctor gains a progress bar, and the interviewer menu gains a fifth option.

Tests

npm test runs an end to end suite that pairs two peers on a private DHT and runs a real session, asserting the audio is byte for byte identical on both sides, the interviewer learns only the take count, and the invite does not carry the drive key.

Known limitations

Capture drops roughly a tenth of the samples on macOS, in periodic gaps. Measured, not fixed. Whisper tiny mangles technical vocabulary, and the review then reasons over the mangled text. Both sides have to be online at the same time. There is no blind peering yet.