Skip to content

0101.md

Latest commit

 

History

History
51 lines (31 loc) · 3.05 KB

0101.md

File metadata and controls

51 lines (31 loc) · 3.05 KB
Raw

Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements

Ty Everett (ty@projectbabbage.com)

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 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.