14 standards
An application that needs an overlay has to find one. Standards here cover advertising a service on chain, publishing it at a domain name, and resolving a name to whatever is behind it.
Also searched as SHIP, SLAP, advertisement, resolution, handle, registry lookup.
SHIP stands for Service Host Interconnect Protocol, a protocol used to advertise which topics a given overlay node hosts. It allows nodes in an overlay network to discover peers that carry the topic data they need.
Open in the glossary14 standards, spread across 4 of the 12 topics.
Independent implementations picking their own names for the same index or query will not interoperate. This proposes naming conventions so a name means the same thing wherever it appears.
Filed under Overlay services
Service discovery is the main subject of these 9.
An index that watches part of the blockchain is only useful if you can find one, and relying on a single index is a single point of failure. This describes how such services announce what they track, so clients can discover several and survive one going offline.
Knowing which services track which data is not the same as knowing which ones will answer questions about it. This extends the discovery mechanism so a service can advertise the specific queries it is willing to serve.
Referring to a file by a web address breaks the moment that address stops working. This lets a file be named by its contents instead, with any number of hosts advertising that they hold a copy.
Independent implementations picking their own names for the same index or query will not interoperate. This proposes naming conventions so a name means the same thing wherever it appears.
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.
If you know a domain runs some kind of overlay service, there was no standard place to find out where to actually send requests for it. You'd end up guessing at conventions like an api. subdomain, or asking around, with no way to be sure you weren't just hitting the wrong host. This gives a domain one clear file where it states, service by service, which URL to use.
Apps that talk to overlay services had no standard way to ask a host "what can you actually do, and on what terms" before sending data. Without that, a client either guesses a URL and hopes, or every integration invents its own private handshake for things like private lookups or proposing a transaction that isn't finished yet. This makes it possible for a client to discover exactly which services and payment or auth rules a host supports, and to safely work with draft transactions that are not yet final.
When a wallet or app stops endorsing an advertisement, or a root decides it no longer wants to show one, there has been no shared, attributable way to ask a server to stop serving that one specific record without pretending to be a global ban or an on-chain spend. Without it, roots either ignore stale or withdrawn ads forever or quietly drop them with no record of who asked or why, and restoring one later is guesswork.
A service can get cut off from its users when a domain registrar suspends a name, a host is seized, or an app store delists it, even though the service itself is still running fine. Normally there is no way for a client to find a service again once the one path it knew about disappears, short of shipping a brand new app update. This gives a client a way to rediscover the service through a record nobody can take down, because it lives on the blockchain.
These are about something else, and deal with service discovery on the way.
A Bitcoin address is a long unreadable string, and asking someone to type one is a good way to lose money. This documents the widely-used scheme that lets people be paid at a readable name like john@example.com instead.
A message relay is only dependable if there is more than one of them, and clients need some way to find them. This describes how relay servers announce themselves, so no single one has to stay up forever.
Indexes need to find each other and stay in step, and doing that ad hoc leaves gaps. This defines how they announce what they track and what they answer, and how they synchronise once found.
A receiver has to know which network group carries the slice of traffic it wants before it can subscribe. This has senders announce that mapping periodically, so a listener can join without being told out of band.
Large files are usually treated as one indivisible blob: you can't name it until the whole thing has finished uploading, a single failed byte range means retrying the entire download, and there's no way to prove a partial chunk actually belongs to the file it claims to be part of. This makes streaming uploads, resumable downloads, and safe partial reads of big files awkward or impossible with simple whole-file hashing.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic