Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements

Ty Everett ([e-mail])

Status

This document is currently aspirational rather than descriptive of the interoperable behavior implemented by bsv-blockchain/ts-sdk.

Current resolver and broadcaster implementations:

• expect concrete host base URLs in SHIP and SLAP advertisements,

• use https: in production,

• allow plain http: only for the SDK's local preset,

• and do not currently negotiate composite schemes such as https+bsvauth+smf: or non-HTTP transports directly from advertisement URLs.

Implementers SHOULD therefore treat the mechanisms described below as future extension ideas, not as present-day interoperability requirements.

Currently, there are only HTTPS URLs within SHIP and SLAP advertisements.

This https: scheme indicates that, according to pre-defined rules (like headers and the /submit or /lookup paths), submission or lookups are facilitated over the HTTPS protocol.

However, sometimes we want to do things like:

• Authenticate users before accepting transactions or facilitating lookup

• Charge a payment for transaction submission, or pay the sender if a transaction is accepted

• Charge a payment for lookup queries

• Submit private or off-chain values alongside a transaction

• Submit non-final transactions that deal with interim states

• Facilitate real-time lookups with WebSocket or based on live / non-final transactions

• Advertise certain IPv6 capabilities and bridges

• Advertise non-HTTPS or non-internet communications systems like radio / JS8 Call

In these scenarios, other schemes can be used within the "protocol" portion of the URL.

For example, current SHIP/SLAP only contemplates URL schemes like https://example.com.

However, a new URL might be something like:

SHIP https+bsvauth+smf://example.com (HTTPS with BSV Auth and Service Monetization Framework enabled)

SHIP https+bsvauth+scrypt-offchain://example.com (HTTPS with BSV Auth and sCrypt off-chain values for transaction submission)

SHIP https+rtt://example.com (HTTPS with real-time transacting support, e.g. non-finals accepted)

SLAP wss://example.com (real-time event-listening live web-socket lookup response streaming)

SLAP js8c+bsvauth+smf:?lat=40&long=130&freq=40meters&radius=1000miles (lookup is advertised using JS8 Call protocol at a given set of GPS coordinates, a given frequency and radius, with BSV Auth and Service Monetization Framework enabled.

These proposed SHIP and SLAP schemes would allow the advertisement of Overlay Services with more advanced capabilities, including real-time updates from lookup services, non-final transaction submission, mutual authentication, payment, off-chain/private value submission, and non-HTTP transport mechanisms.

Compared to plain HTTPS, they may eventually provide a significant improvement. However, until a concrete facilitator specification and interoperable implementation exist, wallets and overlay clients SHOULD assume plain HTTPS base URLs (or local HTTP for development) when processing SHIP and SLAP advertisements.