PeerServ Host Interconnect Protocol

Ty Everett ([e-mail])

Abstract

This document outlines the PeerServ Host Interconnect Protocol (PHIP), a peer discovery mechanism specifically designed for the PeerServ message relay system. Analogous to the scalability and resiliency enabled by BRC-23 CHIP (Confederacy Host Interconnect Protocol) for overlay networks, PHIP allows PeerServ instances to discover and connect with other active instances where a particular user receives messages, thus enabling robust and efficient message delivery across these instances. It also defines a mechanism for instances to prove the authenticity of the original message sender to one another using BRC-69 key linkage information.

Motivation

BRC-33 establishes a reliable message relay architecture, providing a solution for situations where users need to exchange messages but are unable to do so directly over the network. While a centralized server is simpler to deploy, a federated approach that enables instances to cooperate and assist each other in delivering messages removes the need for everyone on the network to rely on a single server. By proposing an interconnect protocol for PeerServ hosts, this document aims to address this requirement and enhance the scalability and reliability of the PeerServ message relay system.

Specification

PHIP Token Protocol

The PHIP token is a BRC-48 output on the Bitcoin SV network which hosts an advertisement created by the PeerServ server operator. The protocol comprises the following ordered fields:

Field	Description
Field 1	The term 'PHIP', representing a PHIP advertisement.
Field 2	The BRC-31 identity key of the instance operator who submitted the advertisement.
Field 3	The domain name of the HTTPS server hosting the PeerServ instance.
Field 4	The BRC-31 identity key of the user who the instance operator believes will receive messages via the PeerServ instance.
Field 5	A signature from the recipient authorizing this host to make this advertisement. The recipient signature is specified below.
Field 6	Optional. If provided, comprises a Regular Expression that is used to test if the message box is supported. If the regular expression passes, the PeerServ instance supports the message box. This is only an optional "fail fast" mechanism, and instance operators must be prepared to reject messages that are destined for users or message boxes they are unwilling to support.

Recipient Signature

The purpose of the recipient signature is to prevent malicious PeerServ hosts from creating advertisements that route messages destined for certain recipients to their servers without authorization. The recipient's PeerServ host will need to obtain this signature from the recipient prior to creating any advertisements to receive messages on their behalf.

The message template for the recipient signature is as follows:

<host key> <host domain> <box regex>

Where:

• <host key> is the BRC-31 identity key of the PeerServ host the recipient is authorizing

• <host domain> is the domain the recipient knows the host to reside at, and

• <box regex> is either the regular expression, or if no regular expression is provided, the string ALL

For example: 028d37b941208cd6b8a4c28288eda5f2f16c2b3ab0fcb6d13c18b47fe37b971fc1 peerserv.babbage.systems ALL

The signature is to be computed by the recipient according to the BRC-3 process. The BRC-43 security level is 1, the protocol ID is PHIP authorization and the key ID is 1. The counterparty is anyone, meaning that anyone can verify the recipient's signature.

Token Creation Process

We specify the creation of a new BRC-22 overlay network (with accompanying BRC-24 lookup service) that will host and track PHIP tokens from various PeerServ instance operators across the network. When it wishes to advertise that messages can be routed to a particular user through their server, the PeerServ instance operator creates a new PHIP token and submits it to the overlay. Upon receiving a new submission, the overlay operators must confirm that the BRC-48 locking key of the PeerServ instance operator is connected to their claimed BRC-31 identity key by ensuring that the BRC-42 child key used for signing can be linked back to the claimed identity key.

The token creation process followed by a PeerServ instance operator comprises several steps:

1. Obtaining the recipient's signature to authorize the message routing advertisement.

2. Deriving the BRC-48 Locking Key: The PeerServ instance operator should use BRC-42 key derivation, with the operator's BRC-31 identity key as the sender private key, while the 'anyone' public key (1 times G) should be the counterparty. The invoice number for BRC-43 is calculated at security level 2, with protocol ID PHIP and key ID 1. Then, the signing private key can be derived from the identity key using this invoice number.

3. Computing the Signature: The derived private key from the earlier step is used to calculate the BRC-48 signature covering the fields of the PHIP token.

4. Broadcast the Transaction: A transaction output is embedded with the PHIP token, and this transaction is then submitted to the PHIP overlay network.

Validation and Verification of Tokens

Before admitting a PHIP token into the overlay, PHIP overlay operators should verify that the claimed identity key from the PeerServ instance operator corresponds to the BRC-48 signing key. Any invalid tokens must not be admitted into the overlay. The validation and verification process is specified in the steps below:

• Verify the PHIP identifier. The first field of the PHIP token should be equal to PHIP. If the PHIP identifier fails to verify, the token has to be rejected as invalid.

• Validate the BRC-48 locking key. The overlay operator should apply the BRC-42 key derivation method, with the advertiser's BRC-31 identity key as the sender public key and the 'anyone' private key (1) as the recipient. The BRC-43 methodology should then be used to calculate the invoice number at security level 2, protocol ID PHIP and key ID 1. The public key derived through the advertiser's identity key using this invoice number must match the BRC-48 locking key; if not, the token is rejected as invalid.

• Validate the BRC-48 signature. The signature produced in the BRC-48 process, using the public key derived, should be verified over the fields of the PHIP token. Only valid signatures which satisfy the necessary conditions should be considered authentic.

• Verify the recipient signature. Use the recipient's claimed BRC-31 identity public key to derive the appropriate signing key for the PHIP authorization protocol, with security level 1 and key ID 1 for the anyone counterparty. Check the signature against the specified message based on the provided fields.

• Blacklist checks. If the overlay network operator maintains a blacklist of known-malicious PeerServ instance operators, they can choose not to admit the token.

• Allow the token into the PHIP overlay. The token is deemed valid if all conditions are successfully met, and can be admitted into the PHIP overlay network.

PHIP Lookup Service

As alluded to earlier, we specify the creation of a new BRC-24 PHIP lookup service which allows network users to find and query various PHIP advertisement UTXOs, thereby facilitating the navigation and interaction with other operators' PeerServ instances. As specified later, PeerServ instance operators looking to forward new messages to the correct place so that the recipient can access them can make use of this lookup service to find which PeerServ instance is in use by the PeerServ message recipient.

Provider Name

We specify PHIP as the BRC-24 Lookup Service Provider Name.

Query Processing

The lookup service accepts a JSON object as its query. The object is specified to contain a recipient key, which the lookup service will use to find records for PeerServ hosts who claim to deliver to the specified recipient.

Query Example

{
  "user": "028d37b941208cd6b8a4c28288eda5f2f16c2b3ab0fcb6d13c18b47fe37b971fc1"
}

The network user performs a lookup service query for the 'user' key, which is the BRC-31 identity key of the message recipient they want to reach. The lookup service will search and return all corresponding UTXOs linked to that key. The network user can then utilize the HTTPS URL(s) for the host record(s) returned, in order to effectuate message delivery.

Routing Authorization Endpoint

Before a PeerServ instance operator advertises that it is able to receive incoming messages on behalf of final recipients, it will need a way to collect authorizations from said recipients. These authorizations are sent to a new BRC-31-protected endpoint (in addition to those specified by BRC-33) which collects and verifies recipient authorization signatures. We specify this HTTPS, JSON, POST endpoint as follows: POST /authorizeRouting

Parameters

Name	Description
message	The message that has been signed by the recipient (required for the avoidance of doubt, makes validation and error handling easier)
signature	The recipient authorization signature, as specified

Processing Steps

The PeerServ instance that receives this request will validate the signature, storing and using it if it later decides to advertise this recipient's availability for the receipt of incoming messages across the network.

Return Value

If the server received and validated the authorization from the recipient, a success response is returned.

{
  "status": "success"
}

Errors

If there was an error, appropriate HTTP status codes should be used. An example of a reasonable error response is provided.

{
  "status": "error",
  "code": "ERR_SIGNATURE_INVALID",
  "description": "The recipient authorization signature could not be verified."
}

Message Delivery Endpoint

When a PeerServ instance operator advertises that it is able to receive incoming messages from other hosts, it must be prepared to accept requests to a new BRC-31-protected endpoint (in addition to those specified by BRC-33) to propagate incoming messages. We specify this HTTPS, JSON, POST endpoint as follows: POST /propagateMessage

Parameters

Name	Description
originalSender	The BRC-31 identity key of the original message sender
keyLinkage	The BRC-69 (Method 2) key linkage information that links the original sender with the Authrite message signature
signedMessage	The message comprising the original Authrite request made by the original sender, which will contain all relevant information, including the message recipient, message box, and message body
senderSignature	The signature that the original sender provided for the message when it was delivered to the sender's local, original PeerServ host

Processing Steps

The PeerServ instance that receives this request will perform the following steps:

1. Compute the child public key for the original message sender by adding (by point addition) the keyLinkage value to the originalSender public key.

2. Check the senderSignature against the computed public key for validity.

3. Examine the signedMessage to determine the appropriate message box and recipient.

4. If the server is willing to add this message to the specified message box for the specified recipient, the message is added.

Return Value

If the message was successfully stored in the recipient's appropriate PeerServ message box, a success response is returned.

{
  "status": "success"
}

Errors

If there was an error, appropriate HTTP status codes should be used. An example of a reasonable error response is provided.

{
  "status": "error",
  "code": "ERR_SENDER_LINKAGE_VERIFICATION_FAILED",
  "description": "Unable to link the signature to the original message sender."
}

Message Delivery to Recipient PeerServ Instance

When a BRC-33 message sender submits a new message destined for a recipient to his local PeerServ instance, the PeerServ instance will perform the following steps to effectuate message delivery across the network:

1. Save the BRC-31 Authrite message signature, message payload, message signing child public key, BRC-43 protocol ID and key ID used for BRC-31 signature verification on the incoming message that was provided by the sender. This will later be used for BRC-69 key linkage revelation.

2. Use the PHIP lookup service to look up UTXOs associated with the PeerServ instances in use by the recipient.

3. If Regular Expression fields were provided for any of the tokens, test the message box where the message is to be delivered against these values, discarding any tokens that fail the Regular Expression check, but keeping any tokens that did not provide one.

4. Apply the steps defined by the Validation and Verification of Tokens section of this document, verifying for themself that the tokens provided by the lookup service are legitimate, and dropping any that fail this verification.

5. Make use of the Message Delivery Endpoint to deliver the message to each of the PeerServ instance operators with valid PHIP tokens, providing the stipulated parameters.

Monetization

It is possible to make use of BRC-41 within the Message Delivery Endpoint to monetize the routing and delivery of PeerServ messages, which would allow operators to collect fees for relaying and synchronizing messages. Subject to routing agreements between hosts, people who make use of this endpoint should be prepared to handle a 402 Payment Required error, as specified by BRC-41. Network operators may also choose to route messages for free, but this is not sustainable at large scale.

Implementations

There are no known implementations of this standard at present. This specification will be updated as and when an appropriate implementation is developed.