Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
Index advertisements were assumed to contain a plain web address, which rules out reaching a service any other way. This allows other kinds of address so a service is not tied to one way of being contacted.
About Service discovery, finding which host can answer your question.
Reference for an AI
Everything an assistant needs to answer questions about BRC-101 accurately, including what it depends on.
Summary
- Why
- Plain HTTPS addresses in overlay advertisements cannot express authentication, payment, private data submission, non-final transactions, or non-web transports, which blocks more advanced facilitator behavior.
- What
- BRC-101 is a proposal for extending SHIP and SLAP overlay advertisement URLs with composite schemes that signal richer facilitator capabilities beyond plain HTTPS.
- How
- An advertisement would use a URL scheme like https+bsvauth+smf: or js8c+bsvauth+smf: instead of plain https:, where each added token after the base scheme names a capability such as authentication, payment, or a non-HTTP transport.
What this lets you do
- Signal that an endpoint requires mutual authentication before submission or lookup
- Signal that an endpoint charges or pays for transaction submission or lookup queries
- Advertise support for non-final or interim transaction states
- Advertise non-HTTP transports such as WebSocket streaming or radio protocols like JS8 Call
- Encode extra parameters like GPS coordinates or frequency directly in the advertisement URL
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
The specification
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 [object Object], and ,[object Object] advertisements,
- use
https:in production, - allow plain
http:only for the SDK'slocalpreset, - 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 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.