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.
Summary
- Why
- Overlay advertisements can currently only describe plain HTTPS endpoints, leaving no way to advertise services that need authentication, payment, off-chain data, real-time updates, or non-HTTP transports.
- What
- BRC-101 is a proposal for extending SHIP and SLAP advertisement URLs to use composite or non-HTTPS schemes that describe richer facilitator capabilities.
- How
- A service would advertise a URL whose scheme is built from parts, like `https+bsvauth+smf://` or `js8c+bsvauth+smf:`, and a client would parse that scheme to learn what authentication, payment, or transport features it needs to support before talking to the service.
What this lets you do
- advertise authentication requirements in a service URL
- advertise paid submission or lookup in a service URL
- advertise support for non-final or interim transaction states
- advertise real-time lookup over WebSocket or other live transports
- advertise non-HTTPS transports such as radio-based protocols
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-101 accurately, including what it depends on.
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 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.