Final Sovereign Rideshare Ranking

Shape. The core repository documentation describes Ridestr as a decentralized rideshare platform built on Nostr with Cashu payments. The feature set is unusually complete for an early-stage project: ride matching, a personal driver network called RoadFlare, NIP-60 wallet sync, HTLC escrow, Nostr-backed profile sync, and Valhalla-based offline routing all appear directly in the published documentation.

Why it wins. The monetary layer is the cleanest in the set. The project is Bitcoin-native rather than merely Bitcoin-compatible, and its MIT License with No-Shitcoin Addendum is not cosmetic: it explicitly blocks downstream non-Bitcoin crypto integration. That combination—Nostr for coordination, Cashu for payments, and anti-shitcoin legal semantics—produces the strongest monetary and licensing alignment in the group.

What keeps it from a perfect score. The primary structural weakness is not philosophical but operational. Relay metadata still matters. A sufficiently powerful observer watching relay traffic, timing, and IP correlation could infer route patterns or social graphs. That is a weaker capture surface than centralized ride-hailing databases, but it is still a meaningful observation layer. Maturity also remains early relative to city-scale systems, even though the release cadence and ecosystem coverage show real momentum.

Shape. The RoadRunner repository presents an open-source ride-sharing client built on Nostr and Lightning, with a React web client plus Node microservices. The design target is peer-to-peer, non-custodial ride sharing. Relative to many early ride-hailing experiments, RoadRunner is notably explicit about location privacy: relay data is kept minimal, and the README argues against long-term geolocation retention.

Why it places second. RoadRunner combines a Bitcoin-native payment stance with a Nostr-native comms layer, which immediately pushes it into the strongest architectural tier. It does not match Ridestr on implementation maturity or documentation density, but it does outperform most competitors on the specific question of how much location state should persist in shared infrastructure.

What limits the score. The stack still depends on application microservices—invoice creators and coordinators—rather than fully eliminating the server role. Those services are self-hostable, but they are still operational choke points, especially if most traffic defaults to a canonical deployment such as roadrunner.lat. Protocolization is also meaningful but not yet as legible or formal as the rideshare schema work visible in Rideshares.org.

Shape. The project is best understood not as a single app but as an attempt to define a ridesharing protocol on Nostr. The main codebase frames the app as an experimental, open-source ridesharing application built on Nostr, while the Hitchwiki notes repository explicitly treats the work as part of a larger effort to connect hitchhiking, ridesharing, and Nostr-based travel tools. That protocol-first orientation is the project’s defining strength.

Why it scores so highly. Rideshares.org is the cleanest expression of composability in the audited set. It uses Nostr-native event structures, route semantics, and pricing fields in order to make rideshare data legible across clients. In other words, it acts less like a walled garden and more like a shared transport language. That is exactly what a protocol-grade civilization brick is supposed to do.

What holds it below RoadRunner and Ridestr. The monetary layer is weaker. Pricing supports BTC and sats, but settlement is external rather than deeply integrated. There is also more geospatial transparency in the data model than in RoadRunner’s more privacy-cautious approach, and the codebase includes a Firebase footprint that creates a default infrastructure compromise even if the project is portable. The stack is therefore excellent at protocolization, strong on comms, but not as hard-lined on settlement or capture minimization as the two projects ranked above it.

Shape. Bullrun is a small, direct, and conceptually elegant attempt to run ridesharing over Lightning. The codebase is lightweight, the design is easy to inspect, and the licensing is maximally permissive under CC0. As an educational object, it is excellent: the core idea is obvious almost immediately.

Why it still matters. Monetary alignment is extremely strong. Bullrun never wavers into fiat plumbing or protocol sprawl; it simply tries to make ridesharing happen with Lightning. That makes it a useful reference implementation for Bitcoin-native payments in a mobility context, and the permissive licensing means it can be forked or cannibalized into future stacks with almost no legal friction.

Why it remains fourth. The architecture is still closer to a demo than to a protocol substrate. The centralized backend sees too much, and the LightningEscrow-style flow acknowledged by the README creates real custody and dispute-resolution weaknesses. There is no Nostr-grade multi-client protocol here, no deeper identity model, and no strong answer to surveillance beyond “run the server personally.” That is meaningful, but it is not sufficient to compete with the top three systems on composability or capture resistance.