# Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements Ty Everett () ## 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://bsv.brc.dev/overlays/0101.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.