Handshakes

The Handshake Process: Building a Web of Trust

While digital credentials form the foundation of reputation on the Toto Chain, the Handshake process takes trust to the next level. It bridges the gap between the digital and physical worlds, creating a robust "web of trust" based on verified, real-world interactions.

This document explains what a Handshake is, why it's so valuable, and the step-by-step process for completing one.

What is a Handshake?

A Handshake (also known as a "moment" or "web of trust ceremony") is the formal, on-chain verification of a face-to-face meeting between two users. It serves as proof that two individuals have met in the real world and mutually acknowledge the interaction.

Why is it Important?

A verified Handshake is one of the most powerful ways to increase your reputation score. For each completed Handshake, you'll earn 1,000,000 reputation points. You can earn up to 200,000,000 points in this way (that's 200 Handshakes). You can always make more Handshakes, but they won't add more reputation beyond the cap.

Handshakes demonstrate a high level of engagement and provide a strong signal of trust that cannot be easily faked. This makes the entire reputation system more resilient and meaningful.

Who is Involved?

The Handshake is a tri-party process, requiring the active participation of three distinct parties:

  1. The Initiator (User A): The user who begins the Handshake process.

  2. The Recipient (User B): The user who confirms the Handshake with the Initiator.

  3. The Attestation Provider (AP): A trusted, third-party service that verifies the meeting occurred and finalizes the Handshake on-chain.

The Handshake Process: A Step-by-Step Guide

The process involves a sequence of on-chain transactions that correspond to the real-world interaction.

Step 1: Request the Handshake

After meeting in person, one of the users initiates the process on-chain.

  • Action: The Initiator (User A) calls the handshake.requestHandshake extrinsic.

  • Parameter: The recipient field must contain the account ID of the Recipient (User B).

  • Result: This creates an open Handshake request on the chain, signaling the start of the verification process.

Step 2: Confirm the Handshake

Next, the other user involved in the meeting must confirm the interaction.

  • Action: The Recipient (User B) calls the handshake.confirmHandshake extrinsic.

  • Parameter: The sender field must contain the account ID of the Initiator (User A).

  • Result: This action confirms that both parties agree the meeting took place. The Handshake is now pending final verification from a trusted third party.

Step 3: Complete the Handshake (Attestation)

This final step is performed by an official Attestation Provider. The AP uses its own off-chain methods (e.g., verifying that both users were at the same location at the same time) to validate the meeting.

  • Action: The Attestation Provider calls the handshake.completeHandshake extrinsic.

  • Parameters: The extrinsic must include the account IDs for both the sender (User A) and the recipient (User B).

  • Result: This is the final, official attestation. The chain recognizes the Handshake as complete and valid. Both the Initiator and the Recipient are awarded a significant amount of reputation points.

By following this secure, multi-step process, the Toto Chain ensures that the web of trust is built on a foundation of verified, real-world connections, making the entire ecosystem safer and more reliable.

Canceling a Handshake

It's possible to cancel a Handshake.

  • Action: The Initiator (User A) calls the handshake.cancelHandshake extrinsic.

  • Parameter: The with field must contain the account ID of the would-be Recipient (User B).

  • Result: This cancels the pending Handshake.

Handling Handshakes with RPC calls

The handshake pallet on the Toto Chain provides several RPC (Remote Procedure Call) endpoints that allow external applications to query the state of the handshake process without needing to decode raw storage. These calls are essential for building user interfaces and services that interact with the web of trust.

This document describes the available handshake RPC calls, their purpose, parameters, and return values.

handshake_getHandshakeCount

  • Purpose: This call retrieves the total number of handshakes that a specific account has successfully completed. It's a simple way to query a user's overall participation in the web of trust.

  • Parameters:

    • account: AccountId: The address of the user whose completed handshake count you want to query.

    • at: Option<BlockHash>: (Optional) The hash of a specific block. If provided, the query will return the count as it was at that point in history. If omitted (null), it returns the count at the latest block.

  • Returns:

    • u32: A single number representing the total count of completed handshakes for the specified account.

handshake_getCompletedHandshakes

  • Purpose: This call retrieves a list of all the accounts that a specific user has successfully completed a handshake with. This allows you to see the direct connections a user has formed in the web of trust.

  • Parameters:

    • account: AccountId: The address of the user whose connections you want to retrieve.

    • at: Option<BlockHash>: (Optional) The hash of a specific block to query the state at that point in history.

  • Returns:

    • Vec<AccountId>: A list (vector) of account addresses. Each address in the list represents a user with whom the queried account has a completed handshake.

handshake_getHandshakeStatus

  • Purpose: This call checks the current status of a potential handshake between two specific users. It tells you whether a handshake is non-existent, pending, confirmed by one party, or fully completed.

  • Parameters:

    • account1: AccountId: The account address of the first user in the pair.

    • account2: AccountId: The account address of the second user in the pair.

    • at: Option<BlockHash>: (Optional) The hash of a specific block to query the state at that point in history.

  • Returns:

    • HandshakeStatus: An enum that will be represented as a string with one of the following values:

      • "Empty": No handshake process has been initiated between these two accounts.

      • "Pending": A handshake has been requested but not yet confirmed.

      • "Confirmed": The handshake has been confirmed by the recipient and is awaiting finalization by an Attestation Provider.

      • "Completed": The handshake has been successfully finalized.

handshake_handshakeExists

  • Purpose: This is a simple boolean check to see if any kind of handshake (in any state other than Empty) exists between two users.

  • Parameters:

    • account1: AccountId: The account address of the first user.

    • account2: AccountId: The account address of the second user.

    • at: Option<BlockHash>: (Optional) The hash of a specific block to query the state at that point in history.

  • Returns:

    • bool: true if a handshake in any state other than Empty exists between the two accounts, false otherwise.

handshake_hasHandshakeCompleted

  • Purpose: This is a specific boolean check to determine if a handshake between two users has been fully completed.

  • Parameters:

    • sender: AccountId: The account address of one user in the pair.

    • recipient: AccountId: The account address of the other user in the pair.

    • at: Option<BlockHash>: (Optional) The hash of a specific block to query the state at that point in history.

  • Returns:

    • bool: true if the handshake between the two accounts is in the "Completed" state, false otherwise.

Error Cases

  • What happens if someone tries to handshake with themselves?

    • The transaction will fail. The requestHandshake function includes a check to ensure the sender and the recipient are not the same account. If they are, the function returns an error, CannotHandshakeWithYourself, and the state of the chain is not changed.

  • What if a handshake already exists between two users?

    • The transaction to create a new handshake will fail. The logic first checks if a handshake in any state (requested, confirmed, or completed) already exists between the two users. If it does, the requestHandshake extrinsic will return an error, HandshakeAlreadyExists, preventing duplicate entries.

  • What if a non-recipient tries to confirm a handshake?

    • The transaction will fail. The confirmHandshake extrinsic is designed to be called by the recipient of the initial request. The function checks that the account sending the confirmation transaction (origin) is the same as the recipient stored in the original handshake request. If an unauthorized third party tries to call it, the chain will not find a matching request for them to confirm, and the transaction will fail with an error like HandshakeDoesNotExist.

  • What if someone tries to complete a handshake that's not confirmed?

    • The transaction will fail. The completeHandshake extrinsic, which can only be called by a trusted Attestation Provider, includes a crucial state check. It verifies that the handshake's status is Confirmed before proceeding. If the handshake is still in the Requested state (or any other state), the function will return an error, HandshakeIsNotConfirmed, and the completion will be rejected.

PreviousLiveness and ReputationNextIntro to RPC Calls

Last updated