Open-source distributed quantum compute network
Hey HN. I'm Colton (YC S21, ex-Acorns), one of the founders of Postquant Labs. My cofounder Richard is a cryptographer out of Draper Labs and DARPA. We're building Quip.Network, the first distributed quantum compute network. We just opened our testnet and wanted to share it here. The basic problem: quantum hardware is here and already competitive on certain optimization problems, but for most people, there's no way to access it. The machines cost millions and the hardware and research are gated by the companies who own them. Also, quantum providers regularly have machines sitting idle because demand isn't consistent, and that's a problem because many architectures need to be cooled near absolute zero and can't just be turned off. There's currently no equivalent of spinning up an on-demand cloud instance for quantum compute. So we're building one. Quip.Network is a spot clearinghouse and marketplace where quantum providers contribute excess capacity, developers deploy their best solvers to an open library, and anyone can submit a workload and get a result without needing to own or understand the hardware. Classical operators (CPUs, GPUs, TPUs) can also participate in solving and verifying. The first quantum subnet was built in close collaboration with D-Wave, the world's leading quantum computing company. It focuses on optimization problems, the kind that appear across finance, logistics, and manufacturing. It runs on annealing QPUs and has demonstrated competitive performance on solution quality, speed, and energy cost relative to classical computing approaches. The mining protocol is designed around these benchmarks, so participants compete to find better solutions. We had about 13,000 signups before launch. The codebase is fully open source because we think quantum advantage should be a verifiable result, not a marketing claim. We want people running nodes, challenging our implementations, and submitting proofs of work optimized for their own hardware. Unlike GPU clusters where one more processor is a linear improvement, the value of adding just one more QPU to your cluster is exponential. It won't be enough to be just AWS, GCP, or IBM. To solve the toughest problems, we'll want to connect together every processor on Earth and have them operate as one giant quantum system. That's why we think a distributed system is the right approach, and that's why our mission is to build the worldwide quantum computer. Happy to answer anything! Docs: quip.gitbook.io/docs | GitHub: github.com/quipnetwork
AI Analysis
Analysis coming soon.
Similar Products
Capgo
Instant updates for Capacitor apps. Ship fixes in minutes, not weeks. Push OTA updates to users without app store delays.
OpenAlternative
Open source alternatives to popular software. Over 1 million users replaced their proprietary tools with open source software. Discover the best alternatives and join the movement.
Artemis.fyi
There are plenty of Artemis II trackers out there. I looked at a bunch and kept running into the same issues - some had data that didn't look right, it was hard to use on smaller screen, others felt overly complicated for what I actually wanted to know: what's the crew doing, where is Orion, how fast is it going. The best one I found was issinfo.net/artemis, which inspired a lot of the design. So I built my own. The part that was genuinely interesting to me was the data. Turns out anyone can query JPL's Horizons API for full ephemeris data on the Orion spacecraft - position, velocity, range - for free. I had no idea this existed. Even better: NASA's Deep Space Network publishes a live XML feed (eyes.nasa.gov/dsn/data/dsn.xml) that updates every 5 seconds showing exactly which ground antennas are talking to which spacecraft. Right now two dishes in Canberra are locked onto Orion - one sending commands, both receiving 6 Mbps of S-band telemetry at 296,000 km. You can see Juno at Jupiter, JWST, Mars Odyssey, all in the same feed. It's pretty amazing what's just sitting there in the open. The app fetches trajectory from Horizons, crew activities from NASA's published flight plan, and live ground station status from DSN. I'll be honest - it's mostly vibe-coded with supervision. The data pipeline is the part that was more manual: figuring out what's publicly available, how to compute relative positions from raw vectors, how to cache and backfill. That was the fun part. Code is open on GitHub. I built it for myself and as a fun exercise, but happy for any feedback - especially around data correctness and what other public data sources are out there that I might be missing. Source: https://github.com/dmarchuk/artemis.fyi
sllm
Running DeepSeek V3 (685B) requires 8×H100 GPUs which is about $14k/month. Most developers only need 15-25 tok/s. sllm lets you join a cohort of developers sharing a dedicated node. You reserve a spot with your card, and nobody is charged until the cohort fills. Prices start at $5/mo for smaller models. The LLMs are completely private (we don't log any traffic). The API is OpenAI-compatible (we run vLLM), so you just swap the base URL. Currently offering a few models.
Ismcpdead.com
Built this to track the ongoing debate around Model Context Protocol - whether it's gaining real traction or just hype. Pulls live data from GitHub, HN, Reddit and a few other sources. Curious what the HN crowd thinks given how active the MCP discussion has been here.