Messaging Protocol

The messaging protocol specifies the format and sequence of messages to be exchanged over the network in order to agree on a journey and coordinate a pickup.

The messaging protocol is a key component of the nRide p2p ride-hailing platform, providing a secure and efficient means for riders and drivers to negotiate rides directly without intermediaries. The messaging protocol is built on top of the NKN network, leveraging its unique features to provide a decentralized, scalable, and robust messaging infrastructure. By defining a sequence of messages to be exchanged between riders and drivers, the messaging protocol enables efficient and reliable ride negotiation while ensuring the privacy and security of sensitive information. In this section, we will discuss the technical details of the messaging protocol, including its encryption and security features, reliability and fault tolerance, and integration with the NKN network.

P2P Network

The implementation of peer-to-peer protocols in mobile applications can be challenging, especially due to the dynamic nature of mobile devices' network conditions, which often do not have a static public IP address. However, nRide has tackled this problem by leveraging NKN, a blockchain-based overlay network.

New Kind of Network

NKN (New Kind of Network) provides multiple independent and self-organized relay nodes, enabling clients to send and receive data for free without requiring a server or third-party services. This eliminates the need for clients to have a public IP address or port forwarding. All data transmitted through the network is end-to-end authenticated and encrypted, ensuring that only the sender and receiver can access and modify the content.

NKN's Proof of Relay (PoR) consensus mechanism incentivizes nodes to relay data packets and participate in the network by providing computing resources, bandwidth, and storage, allowing it to achieve high levels of scalability, security, and efficiency while remaining decentralized.

Messages

This section outlines the sequence of messages that are exchanged over the network to negotiate and agree on a ride in the nRide protocol. It provides a detailed description of each message and its purpose in the ride-hailing process. By following this sequence, riders and drivers can efficiently communicate with each other, agree on the details of the ride, and ensure a safe and reliable experience.

Request

Passengers can initiate a ride request by broadcasting a "Request" message to nearby drivers. The message contains several pieces of information, including a unique ID for the request and the coordinates of the pickup and destination points. These pieces of information allow drivers to quickly and easily identify the ride request and determine whether they are able to accept it.

Additionally, the "Request" message may include a raw “data" field that can be used to encode arbitrary information. This field may be used to include additional information about the ride request, such as the passenger's profile information or any special instructions for the driver.

Request {
	String id;
	String source;
	double startLat;
	double startLon;
	String startAddress;
	double endLat;
	double endLon;
	String endAddress;
	[]byte data;
}

RequestCancellation

Before receiving or accepting proposals, passengers can broadcast a RequestCancellation to signify that their request is no longer active. The "acceptedProposalID" field is used to prevent multiple drivers from accepting the same ride request and to ensure that only one driver is assigned to each ride request. If a driver receives a ride request with an "acceptedProposalID" field that matches their own ID, it means that they have already accepted the request and should not take any further action. If a driver receives a ride request with an "acceptedProposalID" field that does not match their own ID, it means that another driver has already accepted the request, and the driver should disregard the request and wait for another one.

RequestCancellation {
	String id;
	String source;
	String requestID;
	String acceptedProposalID;
}

Proposal

When a driver receives a ride request from a passenger, they have the option to send a "Proposal" back to the sender of the request. The proposal typically includes information about the driver's position, a proposed price for the ride, and the driver's NRIDE address for setting up the escrow account. The NRIDE address is associated with a cryptocurrency wallet on the JUNO blockchain, which drivers use to send and receive NRIDE tokens when participating in the escrow mechanism for a ride request.

In some systems, this process can be automated based on the driver's preferences, location, and other factors. This means that drivers do not need to actively monitor their phones or interact with the system to analyze and respond to incoming ride requests. Instead, the system can automatically match drivers with ride requests based on various criteria, such as proximity to the passenger's location or the driver's availability.

Proposal {
	String id;
	String source;
	String requestID;
	double driverLat;
	double driverLon;
	double price;
	String tokenAddress;
	[]byte data;
}

ProposalCancellation

Drivers can send a "ProposalCancellation" to the passenger before their proposal is accepted. This cancellation signifies that the driver's proposal is no longer valid, for example if the driver is no longer able to fulfill the ride request or if the passenger has already chosen a different driver.

Sending a ProposalCancellation allows drivers to inform the passenger that they are no longer able to fulfill the ride request, which can help to prevent confusion and ensure that the passenger is able to quickly find another driver to fulfill the request.

ProposalCancellation {
	String id;
	String source;
	String proposalID;
}

Acceptance

When a passenger broadcasts a ride request, they may receive multiple proposals from nearby drivers. To select the best proposal, the passenger will typically compare prices and time estimates computed locally before choosing the one that best meets their needs.

To accept a proposal, the passenger must first initialize an escrow account using the proposer's NRIDE address. This involves sending a deposit into the escrow account, which can be automated for convenience. With the escrow account initialized, the passenger can then broadcast an "Acceptance" message to nearby drivers, informing all proposers that a proposal has been accepted.

The selected proposer can then continue with the ride request, while the other drivers return to listening for requests. The escrow account ensures that the driver is paid for their services, while also providing a layer of security and protection for both the passenger and the driver.

Acceptance {
	String id;
	String source;
	String proposalID;
	String escrowID;
}

Confirmation

After a passenger broadcasts an "Acceptance" message to nearby drivers, the driver whose proposal was selected will receive the message and use the provided escrow ID to check the passenger's deposit in the escrow account. If the deposit is confirmed, the driver must then send their own deposit to the same escrow account before sending a "Confirmation" message to the passenger.

This process helps to ensure that both parties have a stake in the transaction and are committed to following through with the ride request. By requiring both the passenger and the driver to send deposits to the escrow account, the NRIDE ecosystem ensures that there is a mutual agreement and incentive to complete the ride.

Confirmation {
	String id;
	String source;
	String acceptanceID;
}

Termination

Once a "Confirmation" message has been sent by the driver and received by the passenger, either party can send a "Termination" message to signify that the ride request has been canceled or completed. This termination message may include a secret phrase that allows the other party to redeem their deposit, as well as any cancellation fees that may apply.

The use of a secret phrase helps to ensure that the refund process is secure and only authorized parties can redeem their deposit. By including this key phrase in the termination message, the other party can then use it to redeem their deposit from the escrow account.

Termination {
	String id;
	String source;
	String confirmationID;
	String reason; // Completed or Cancelled
	String secret;
}

TerminationAck

When a ride request is terminated by either the passenger or the driver, the other party can respond with a "TerminationAck" message that includes a secret phrase. This phrase allows the counterparty to unlock their part of the escrow account and receive their deposit, as well as any applicable cancellation fees.

By responding with a TerminationAck message that includes a secret phrase, the user helps to ensure that the refund process is secure and that the other party can redeem their deposit from the escrow account.

Overall, this process helps to create a more transparent and reliable ride sharing experience for both passengers and drivers, by providing a mechanism for canceling ride requests and receiving refunds if necessary. The use of the secret phrase also helps to ensure that the refund process is secure and that only authorized parties can redeem their deposit from the escrow account.

TerminationAck {
	String id;
	String source;
	String terminationID;
	String secret;
}