For the past few months I've been building a family of libraries for the xTalk family, and they've reached the point where I think they're worth sharing.
Each extension is a thin wrapper over a proven native library (two are pure script), and they're built to work together, so you can compose them: torrentxt's DHT can find peers for a datachannelxt link, nostrxt gets its crypto from coinxt and sodiumxt, and the poker app uses four at once. Every wrapped library ships prebuilt for Windows, macOS and Linux.
The demos are all single .livecodescript files. Paste one into a fresh stack script, save, re-open, and the stack builds its own UI. No helper stacks, no wiring, nothing to put in use first. start-here.livecodescript is a clickable directory of all of them if you'd rather browse from inside xTalk.
There are still things in progress, and anything that hasn't been run on a real engine says so in its own header, but it's far enough along that I'd rather have eyes on it than keep polishing.
The extensions
- sodiumxt (sx*) wraps libsodium. Encryption, signatures, sealed boxes, Argon2id password hashing, key derivation, streaming file crypto, hashing, and a real random source.
- torrentxt (bt*) wraps libtorrent. The whole BitTorrent stack: DHT, PEX, magnets, uTP, trackers, webseeds, v1+v2, BEP44 signed mutable items, plus the rp1 peer-wire transport.
- enetxt (en*) wraps ENet 1.3.18. Game-grade reliable UDP: reliable, unreliable-sequenced and unsequenced traffic on separate channels, with one-call broadcast.
- datachannelxt (dc*) wraps libdatachannel. WebRTC data channels that talk to browsers, with real NAT traversal and per-channel reliability.
- onionxt (ox* / oxh*) drives a local Tor daemon, in pure script. Anonymous TCP, v3 onion services, and HTTP-over-onion hosting.
- nostrxt (nx* / nxr*) is Nostr in pure script, with its crypto composed from coinxt and sodiumxt. Signed NIP-01 events, NIP-19 bech32 entities, full NIP-44 v2 encryption, filters, and a relay client that verifies before it delivers. (NIP-44 needs sodiumxt ABI 10+; it fails closed on older installs.)
- box2dxt (b2* / b2k*) wraps Box2D v3.1.0, and it's the oldest member of the family. Full rigid-body physics plus the pure-script b2k game Kit: control-backed bodies in pixels and degrees, sprites, input, a player controller, a camera. The game-engine half that pairs with enetxt.
- coinxt (cx*) wraps trezor-crypto and libsecp256k1. Bitcoin and Ethereum primitives: hashes, secp256k1 (ECDSA/RFC 6979, recoverable + ecrecover, ECDH), encodings and addresses (Base58Check, Bech32/m, RLP, P2PKH/P2WPKH/P2TR/ETH + EIP-55), HD wallets (BIP-39/32/44), transactions (legacy + SegWit, EIP-155 + EIP-1559), and BIP-340 Schnorr plus the BIP-341 Taproot tweak. One gap: no BIP-341 sighash builder yet. It signs a sighash you hand it, it can't build one.
Three of the stacks in this repo are fairly far along examples of combining these libraries into new secure, networked, decentralized, p2p and game apps. But those are just the three I happened to build. The point of the suite is the whole category of app that was basically off the table in xTalk before and is now a weekend project:
- File transfer and sync. Send anything to anyone with no server, no upload and no size cap. Sync a folder between your own machines. Ship your app's own updates over torrents so your users seed for each other.
- Publishing and feeds. Signed, tamper-proof channels on the DHT: a release feed, a podcast, a newsletter, a blog, a software update channel that nobody can take down and nobody but you can post to.
- Chat and messaging. LAN chat, internet chat, encrypted DMs with no server anywhere, group rooms. Three different transports to pick from depending on what you need: reliable UDP, WebRTC, or straight over the BitTorrent peer wire.
- Social apps. Feeds, follows, profiles and media attachments, all signed and verified, with your followers acting as the CDN. Or a Nostr client if you'd rather plug into an existing network with existing relays.
- Multiplayer games. Real physics and game-grade networking in the same toolbox. Sprites, a player controller, a camera and deterministic simulation on one side; separate channels, reliable and unreliable delivery and one-call broadcast on the other. LAN or internet.
- Card and board games with real stakes. Signed action transcripts, hash-chained history and mental-poker shuffles mean a fair game with no trusted host at all, and a hand anyone can audit afterwards.
- Anonymous and censorship-resistant tools. A dropbox that hides both ends, a chat that hides both ends, a service reachable at an .onion address you never had to register with anyone.
- Self-hosting with no server and no port forwarding. Serve a real website, a dashboard or an API straight out of a stack on your desktop, reachable from anywhere, with no hosting bill and no router config.
- Browser bridges. WebRTC data channels talk to actual browsers, so a web page can be the front end for a desktop stack with nothing in between them.
- Local encryption tools. Password vaults, encrypted backups, file lockers, sealed settings, all with modern authenticated crypto that fails closed instead of quietly handing back garbage.
- Signed and verifiable data. License keys, receipts, audit logs, tamper-evident records, and "prove this file is the one I published" tooling.
- Wallets and crypto tooling. Bitcoin and Ethereum wallets, watch-only wallets from an xpub, address generators, message signing as a login, transaction builders.
- Device meshes. Your own machines finding each other on the LAN, admitting each other with a mutual handshake, and syncing state with no cloud account in the middle.
The three apps
Here's what that looks like in practice:
- No Cloud Quick Share (readme). Drag a file onto the window, get a short code, send the code to a friend. They paste it in and the file transfers straight from your machine to theirs. No server, no upload, no size cap. Three ways to share: the code (which is just the file's content address, so the DHT can introduce the two machines), a plain web link any browser can open, or a private Tor transfer with both IP addresses hidden. Add a passphrase and only ciphertext ever hits the swarm, with a wrong passphrase caught before anything downloads. Built on torrentxt, with sodiumxt and onionxt optional.
- holde-em (readme). Serverless no-limit Texas Hold'em. No accounts and no server: players meet on the DHT (the table code is the invite), every action is signed into a hash-chained transcript, and the deal runs on a security ladder topping out at a ristretto255 mental-poker shuffle, so not even the host can see a card they aren't entitled to and a finished hand can be audited afterwards. Hotseat and online both play, with act timers, a time bank, sit-out and return, late joins, host election if the host drops, and optional Tor tables. It uses four members at once: torrentxt, sodiumxt, onionxt, and box2dxt's Kit for the card art.
- Riptide Social (readme). A serverless social network on four self-building cards. Your identity is an Argon2id-sealed seed file the app owns, and the same key doubles as your feed handle and your .onion address. Posts are signed and published to the DHT; following someone fetches their head, walks the post chain back, and shows the signature verdict on every post. Media rides as trackerless torrents, so a post carries only a hash and your followers are the CDN. On top of that: encrypted DMs with no server anywhere, a WebRTC call over the same encrypted rail, a LAN device mesh with a mutual admission handshake, and an anonymous persona over Tor. Feed, follows, media and DMs have all had two-machine passes; calls, the device mesh and the anon card are still waiting on theirs.
- Torrent client. A real multi-torrent client in one file: add by magnet, .torrent, URL, info-hash or drag and drop, with duplicate detection, a live table with progress bars, per-torrent pause/resume/recheck/reannounce, a Files/Peers/Trackers/Log inspector, per-file priorities, sequential streaming, queue ordering, a global upload cap, and remembered settings. Standalone-ready if you want to build it as an app.
- DHT channels. A decentralized release feed. Publish a file and it's seeded and announced in your channel, signed under your ed25519 key on the DHT. Others follow you by pasting your channel card and get a unified, tamper-proof feed across everyone they follow. Optional privacy mode encrypts both the feed and the files, so the file list itself is hidden.
- DHT chat. WebRTC with no signaling server of your own: the BitTorrent DHT carries the offer and the answer, ICE punches the NATs, and the conversation then rides a direct encrypted data channel. The room code is a keypair seed, minted fresh every time you host. If you want to see the pipeline first without any networking, loopback runs two peers inside one stack with the signaling shuttled in script.
- ENet internet chat. Reliable UDP between two machines on different networks. It opens the router port itself, hands you an invite line to paste, and the status pill only goes green when the far end is genuinely a public address, so a same-network test can't pass itself off as the real thing. Live RTT and loss counters beside it. The simpler LAN chat is the one to read first.
- rp1 chat. The smallest thing that exercises the whole peer-wire path: two machines join a metadata-less swarm at a shared room name, the DHT introduces them, and messages travel under a custom BitTorrent extension with no tracker, no server and no file involved. Deliberately plaintext so you can watch the transport work. This is the rail Riptide's DMs ride on.
- OnionXT demo. A tabbed tour of the Tor surface: dial anonymous streams, publish v3 onion services including reproducible seed-derived ones, and serve real HTTP over an onion from either a route handler or a folder. Also the best template in the repo for async flow, since every click kicks something off and the answer arrives in a callback.
- NostrXT demo. Make or import an identity, see your npub, sign a note and watch it verify, decode NIP-19 entities, connect to a relay, subscribe and publish. The relay callback handler is the whole protocol contract in one switch.
- The box2dxt games. A seven-level platformer driven entirely by the Kit's player controller, camera and sprite atlases (the file holds no movement code of its own), a slingshot game where the physics core carries the whole thing and stacked towers sleep until something hits them, and a contraption builder sandbox: drop parts, wire them up with hinges, ropes, sliders and motors, then press Run.
- The two showcase stacks. sodium-demo is a tabbed panel per capability, and every panel tells the same story: your input, a plain sentence about what the crypto does, the output, and a status line that goes red when authentication correctly rejects tampering. coinxt-demo walks a mnemonic all the way to a signed transaction, showing each one decoded as human intent beside the bytes that intent became.
It's a monorepo, but every member stays self-contained: its own build script, source, tests, docs, and its prebuilt native library per platform. You can install one without the others.
Claude Code (Opus 5 and Fable 5) was used heavily throughout. The root CLAUDE.md is deliberately thin and each member carries its own, which is the authority for that layer, so the hard-won lessons about a binding sit next to the code they're about.
The tools/ folder is what makes that workable. There's no headless compiler for LiveCodeScript, so a mistake doesn't surface until you paste the file into a stack on a real engine, and one bad line takes the whole file down. So the checks are Python and run with no engine at all:
- A static checker for LCS and LCB that refuses the specific things that have bitten before: non-ASCII characters, token shadowing, constants used before they're declared, unbalanced blocks, zero-argument calls written in statement position, and per-dialect antipatterns. Every member ships a byte-identical copy and a gate fails the build if one drifts.
- Drift gates for the shared blocks. The UI kit, the test scaffold, the demos' boot self-check and the library code embedded inside each demo each have one master file and are carried verbatim, so a fix is made once instead of eleven times and the copies can't quietly diverge.
- Coverage gates that fail if a public handler is never exercised by any test, or if an old exemption goes stale after a rename.
- Fixture tests for the gates themselves, since a checker that silently stops checking is worse than no checker.
GitHub Actions runs those gates on every push, builds each member's native library across a five-platform matrix with sanitizer lanes, and has a manual workflow that builds every platform's binary at once, installs them into the tree, re-runs the full gate set, and commits.
Getting started
Grab the repo, either clone it or download the zip.
Install the extensions you want. Six of the eight ship a native library: sodiumxt, torrentxt, enetxt, datachannelxt, box2dxt and coinxt. For each one, open its src/<name>.lcb in the Extension Builder and click Install. The native library for your platform is bundled inside, so there's nothing else to download, nothing to rename, and nothing to drop in a system folder. Each member's README has a one-line sanity check you can run in the message box to confirm it loaded. onionxt and nostrxt are pure script and have nothing to install (onionxt does want a Tor daemon running locally, and nostrxt leans on coinxt and sodiumxt for its crypto).
Then open the launcher. Paste start-here.livecodescript into a fresh stack script, save the stack in the repo's root folder, and open it again. It should build itself. Either way it needs to live in the repo root, because it finds every demo by a path relative to its own location.
From there you get a clickable directory of every demo and harness in the tree. Click a path to read what it is and what it needs, then hit Open and the stack builds itself. The one thing the launcher can't do is install extensions for you, so a demo opened without its extension fails closed with a red status line naming what's missing instead of blowing up.
None of the demos are completely finished, but they're far enough along that I think they show what's possible.