Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements

Ty Everett ([e-mail])

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 new SHIP and SLAP schemes allow for the advertisement of new Overlay Services that have more advanced capabilities, including real-time updates from lookup services, non-final transaction submission, mutual authentication, payment, off-chain / private value submission, non-HTTP transport mechanisms, and much more.

Compared to plain HTTPS, they make a significant improvement. Facilitators for each of these custom "protocol" fields in the advertised SHIP/SLAP URLs can be implemented into standard libraries, the associated lookup services can be updated to facilitate querying by them, and new default SLAP trackers can be added so that users are able to stay connected in more ways than one.