Overlay Network Lookup Services
Submitting data to an index is half the job; getting it back out again is the other half. This defines how a client asks such a service what it is holding and receives an answer it can verify for itself.
6 standards
The question answering half of an overlay: a defined query interface, a way to page through long results, and a way to resume a query that was interrupted or to pay for a private one.
Also searched as CLAP, query, resumable results, lookup.
The read side of an overlay: the interface for querying the outputs it is tracking, as opposed to submitting new transactions to it.
Open in the glossaryAll 6 sit in Overlay services, so browsing that topic finds the same standards.
Submitting data to an index is half the job; getting it back out again is the other half. This defines how a client asks such a service what it is holding and receives an answer it can verify for itself.
Filed under Overlay services
Lookup services is the main subject of these 2.
Submitting data to an index is half the job; getting it back out again is the other half. This defines how a client asks such a service what it is holding and receives an answer it can verify for itself.
Pulling a large, constantly changing list of overlay results used to force a choice between getting a stable view that quickly goes stale, or watching live updates and losing track of what you already saw if your connection dropped. There was no safe way to read the current state of something and then keep watching it change without missing an update that happened during a disconnect. This gives a reader a consistent starting snapshot plus a way to pick back up exactly where it left off, even after going offline.
These are about something else, and deal with lookup services on the way.
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.
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.
Right now, if an app relies on a single server to hold and deliver messages or lookup results, that one server becomes the weak point: if it goes down, delays, or drops something, there is no backup and no way to reward anyone else for stepping in. This approach lets several independent hosts race to answer the same request, with the fastest honest ones getting paid automatically, so no single operator can quietly become a bottleneck or single point of failure.
Different Bitcoin-based apps use the word "overlay" for two very different setups: one where every server is supposed to agree on the exact same data, and one where servers legitimately hold different, non-matching collections. When people conflate these, it becomes unclear whether a mismatch between two servers is a bug to fix or just two valid, different answers.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic