User-held identity
Participants control their keys, local history, preferences, and portable evidence.
Founder vision documented · Pre-implementation research RFC
An open protocol
for rides.
PactRide 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.
DocumentedComplete founder vision
OpenApache-2.0 specification
UnprovenIndependent clients required
PactRide / 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. PactRide 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.
PactRide 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 PactRide 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 PactRide 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
The founder-authored documentation is complete; substantive external review and maintainer-diversity exit criteria remain open.
Vision documentedProtocol core
Initial event-family schemas, Nostr transport rules, and executable lifecycle fixtures exist; independent cross-language and relay evidence remains.
Current evidence 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 startedProtocol family
PactRide is self-contained.
CommonPact is later abstraction research.
The intended CommonPact layer may cover identity, discovery, private negotiation, bilateral agreement, lifecycle events, and portable evidence.
PactRide does not depend on it. Extraction requires a substantially different second profile, independent implementation evidence, explicit migration rules, and preservation of transportation-specific safety requirements.
The foundation
Complete enough to be challenged.
01
Founder vision
↗
02The bounded record of what is fully documented and what remains unproven.
Current status
↗
03What exists, what remains unproven, and the immediate gates.
Protocol
↗
04Event envelope, validation, versioning, proofs, and compatibility.
Architecture
↗
05Components, data boundaries, transports, and deployment modes.
Threat model
↗
06Location abuse, malicious peers, Sybil attacks, and infrastructure failure.
Trust model
↗
07Portable evidence without a universal platform score.
Governance
↗
08RFC decisions, conflicts, maintainership, and succession.
CommonPact boundary
↗
09Candidate core mapping, extraction criteria, and PactRide independence.
Licensing
↗
10Apache-2.0 specification rights and the boundary for future official software.
Maintenance policy
↗
Limited capacity, inactivity, archival, and restart conditions.
Open and sustainable
Open specification. Optional commercial value.
The current specification repository uses Apache-2.0. Commercial and independent implementations are allowed, and users do not owe PactRide a royalty or revenue share merely for implementing the protocol.
Sustainability: stewardship can be funded through grants, sponsorships, consulting, managed infrastructure, audits, support, training, authorized certification, and official products. Future official software may use separately published license terms in separate repositories when PactRide controls the required rights.
Read the licensing and commercial boundarySpecificationApache-2.0
Use, modify, distribute, and commercialize subject to the standard license conditions.
ProtocolOpen adoption
Build compatible clients and infrastructure without requesting permission or paying a royalty.
Optional valueProducts and services
Hosting, support, audits, integrations, training, official software, grants, and authorized certification.
Current status
Founder vision documented.
Not a ride service.
PactRide provides a complete initial founder vision, protocol drafts, strict schemas, test vectors, automated validation, threat analysis, governance, licensing boundaries, and contribution pathways. It does not provide rider or driver applications, identity verification, emergency response, payment protection, insurance, independent interoperability proof, or production safety guarantees. It is maintained at limited capacity and has no promised launch date.
Stewardship and continuity
Seeking maintainers and credible partners.
wpggLabs is the current maintainer. The founder maintains the completed initial vision, repository, website, and public record, but is not attempting to build or operate a production ride network alone. Major implementation should resume only with committed technical maintainers, funded research, or a credible bounded pilot partner.
Open participation
Make the proposal harder to break.
PactRide needs protocol engineers, security researchers, mobile developers, accessibility specialists, drivers, riders, cooperative operators, universities, nonprofits, and informed critics.