User-held identity
Participants control their keys, local history, preferences, and portable evidence.
Pre-implementation research RFC · Open contribution
An open protocol
for rides.
OpenRide explores a future where riders and drivers can discover each other, negotiate privately, verify pickup, and carry evidence between compatible applications—without one company owning the coordination layer or collecting a mandatory protocol commission.
OpenCC0 specification
PortableUser-held identity
NeutralNo protocol tax
OpenRide / exchange
local verification
Rider clientuser-held key
01
Coarse request publishedsigned · TTL-bounded · relay-redundant
public
02
Terms negotiatedexact pickup · price · vehicle
encrypted
03
Pickup verifiedQR · phrase · nearby handshake
bilateral
04
Receipt countersignedportable evidence · local history
complete
Driver clientindependent implementation
Illustrative protocol flow. OpenRide is not a live transportation service.
The premise
Software should coordinate the ride.
It should not own the relationship.
Ride-hailing platforms proved that software can match independent drivers and riders at scale. They also placed discovery, identity, pricing, reputation, and access to work behind one operator.
OpenRide asks which parts can become shared, interoperable infrastructure—closer to email or the web than a marketplace controlled by one company.
Design constraints
Protocol before platform.
Six rules keep OpenRide from becoming the centralized service it was created to avoid.
Private by progression
Public discovery is coarse and temporary. Exact details appear only after intentional encrypted exchange.
Replaceable infrastructure
Relays, maps, payment methods, and community services remain substitutable.
Plural trust
Communities evaluate evidence under local policy instead of accepting one global platform score.
No protocol tax
Optional services may charge transparent fees; base protocol access never requires a per-ride commission.
Interoperability proof
The protocol is not credible until independently written clients complete the same ride flow.
Reference architecture
Public enough to discover.
Private enough to coordinate.
Client A
Rider
keys · preferences · local trust
coarse signed intent
Relay 1Relay 2Community
client-side discovery
Client B
Driver
keys · filters · local ranking
End-to-end encrypted
Offer → counter → matching acceptance proofs → exact pickup → ride state
Physical proximity
QR / short phrase / nearby handshake → bilateral pickup and completion evidence
Relay role
Distribute events. Never become the mandatory dispatcher or source of truth.
Client role
Validate proofs, TTL, duplicates, state conflicts, and local trust policy.
Nearby role
Verify pickup and preserve limited state during outages—not replace citywide internet discovery.
Deliberate boundaries
What OpenRide refuses to pretend.
×No blockchain requirement
Signed bilateral state does not need global consensus.
×No mandatory token or fee
Settlement remains optional and method-neutral.
×No canonical server
Infrastructure providers must be replaceable.
×No fake safety claim
Cryptographic proof does not prove identity, conduct, payment, or physical safety.
×No Bluetooth fantasy
Nearby radio is useful resilience, not reliable citywide dispatch by itself.
×No single official app
Compatibility matters more than one polished interface.
Evidence-driven roadmap
Each phase must prove the next one is justified.
RFC foundation
Vision, safety, governance, schemas, and public review structure are present; external-review exit criteria remain open.
Foundation presentProtocol core
Harden schemas, encryption and relay profiles, state fixtures, and cross-language event validation.
Current workIndependent clients
Two independently written command-line clients complete one shared transcript across test relays.
Next proofMobile and pilot
Reference clients and any bounded community experiment remain gated by interoperability, safety, legal, and operational evidence.
Not startedThe foundation
Built to be challenged.
01
Current status
↗
02What exists, what remains unproven, and the immediate gates.
Protocol
↗
03Event envelope, validation, versioning, proofs, and compatibility.
Architecture
↗
04Components, data boundaries, transports, and deployment modes.
Threat model
↗
05Location abuse, malicious peers, Sybil attacks, and infrastructure failure.
Trust model
↗
06Portable evidence without a universal platform score.
Governance
↗
RFC decisions, conflicts, maintainership, and succession.
Open and sustainable
The protocol stays public. Stewardship can still be funded.
Independent implementations remain possible and do not owe OpenRide a royalty. Future official software may use AGPL plus an optional commercial-license model, but no production reference implementation or commercial license is currently offered.
Legal gate: dual licensing, contributor rights, and trademark ownership require professional review before substantial external code or commercial terms.
Read the licensing and sustainability modelProtocol routeCC0
Independently implement the public specification without permission or royalty.
Planned code routeAGPL
Future official network software may be available under copyleft terms.
Optional valueServices
Hosting, support, audits, integrations, training, and future commercial exceptions.
Current status
Research RFC.
Not a ride service.
OpenRide currently provides protocol drafts, strict schemas, test vectors, automated validation, threat analysis, governance, and contribution pathways. It does not provide rider or driver applications, identity verification, emergency response, payment protection, insurance, or production safety guarantees.
Open participation
Make the proposal harder to break.
OpenRide needs protocol engineers, security researchers, mobile developers, accessibility specialists, drivers, riders, cooperative operators, and informed critics.