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.
Integuru
Hey HN! We’re Alan and Richard from Integuru (YC W24). We generate fast, reliable integrations for platforms lacking official APIs. About 2 years ago, we released the first agent that reverse-engineers network traffic to build integrations (https://github.com/Integuru-AI/Integuru). Since then, we’ve developed a new approach to reverse-engineer platforms’ source code directly. This solution also includes authentication support. Here’s a demo: https://youtu.be/4l2L8fILC2g?si=nbWbDiFrWZIWRPM7. Many AI products need to integrate with web apps, but platforms often lack official APIs. So far, there are two main ways to integrate: browser automation and via network requests. We set out to build the original agent because we ourselves suffered from RPA’s latency, reliability, and throughput issues. The original agent solved many of the prior issues, but it wasn’t perfect either. The original agent did things the obvious way: (1) have a human do the action; (2) the agent observes the network requests and (3) recreates them. That got us far, but it only supported the path the user triggered. In production, we saw all the uncovered cases: different states, missing fields, permission differences, hidden validations, and request changes we could never catch in a single run. So we started building a new solution from the ground up. Our first step was to add agents that trigger many variations of the same action. To protect the platform’s data integrity, we added a gating layer that blocks outbound requests. This lets us observe the exact request structure, branching behavior, and platform logic without accidentally mutating the live system. But this still wasn’t enough. Some logic is hard to surface by execution alone. A lot of the business rules live in the frontend bundle. So we set out to analyze the true “answer sheet” for each platform: the source code. After experimenting, we got this working. We built a source-code analysis layer that deobfuscates and traces the code associated with each action. In practical terms, our system can handle most tricky edge cases without triggering all flows. Together, these two layers result in much better coverage of the production surface area. They support more edge cases, fail less often, and avoid a lot of the brittle one-off fixes that usually come later. Finally, we added auto-healing and API doc generation to improve reliability and the UX. We also offer a 24/7 on-call maintenance team for companies on the production plan. We now spend most of our time supporting vertical AI companies and helping them connect to their customer systems. We offer a free plan for integrating with one platform and charge for additional platforms, accounts, and overage API calls. For instance, we help healthcare AI companies connect to EHRs and payer portals, and logistics companies connect to TMSs and ERPs. Some companies are now running more than 1M monthly requests per platform. Across our production users, API calls complete in ~3 seconds at 99.9%+ success rate on average. We’re also building a library of APIs that users can use out of the box. That said, this version still has limitations we want to iterate on. Although we already tackle some anti-bot mechanisms, the agent still struggles to generate integrations with heavily anti-botted platforms. When the agent fails, our on-call team steps in to improve the agent or build the integration manually if the customer requests it. Also, the UX for generating an integration is still quite manual. Our next step is to build a CLI experience, so people and their agents can create, test, and use integrations in a much more flexible manner. This also prevents humans from having to wait for Integuru to finish its tasks. We want to one day allow developers and agents to integrate with all platforms instantly. Integuru is an ongoing effort. We’re passionate about automating integrations and would love your feedback!
LINQ CLI
Hey my name is Patrick, I’m a co-founder and CTO of Linq. We’re an API for sending and receiving iMessages (it does RCS/SMS too). It can do everything you can manually in iMessage (typing indicators, reactions, delivery emphasis, FindMy etc.) Our main customers are companies building conversational agents but we’re wanting to make it easier for developers to get started for free. To do that we built a CLI that lets you manage up to 20 contacts and gives you full API access for free. I’d love your feedback so we can keep improving it. Install via npm using: npm install -g @linqapp/cli Recently, I used the CLI to connect my Claude bot to WeWork & iMessage and haven’t had to use the WeWork app in a few weeks to book rooms. Github: https://github.com/linq-team/linq-cli Landing page: https://linqapp.com/cli Three constraints you should know about: 1. The free tier requires inbound-first (ie someone must text you before you text them) and has a limit of 20 contacts. This is to avoid spam. 2. The line is shared. This means a few other people will be using the same phone number as you, none of our paid production lines work this way. If you're testing enterprise grade our sandbox mirrors production, but has a 7 day time limit. The CLI is shared because there is a real infrastructure cost to us and we want to give this away for free. 3. We require an email to sign up. To avoid spam + our infrastructure cost. To be precise about "open source", it's the CLI. The whole client is in that repo, so you can read exactly what leaves your machine. The backend that delivers messages is closed.
Open-Source AI Racing Harness
Hi I'm Dan from Elodin, making an open source real-time capable flight software simulation. For AI Grand Prix contestants, the wait for the Round 1 virtual qualifier simulation has been grueling. If you’re competing, check out our simulation harness to tide you over, built to match the published competition constraints and message format. It runs against real Betaflight, which we learned requires at least 1000 sensor samples per second to run real-time correctly. The competition warranted introducing a new feature to generate the camera sensor directly in the simulation loop. Typically people connect to Unreal or similar game engine to create a camera sensor, which works well but is very heavy. For the simple needs of this challenge, creating sample directly in the loop is very handy and easy to use. Happy to hear your feedback on this! While it's not fancy looking currently, it uses the Rust Bevy game engine, which should allow us to improve the visual fidelity quickly. We all should easily be able to shift our implementation to the published competition sim once it lands. Hope you enjoy and good luck!