10 standards
How a request physically reaches the wallet: an HTTP call to a local port, a message passed between browser windows, or, where there is no network at all, a sequence of animated QR codes across an air gap.
Also searched as substrate, HTTP, XDM, window, air gap, QR, offline, transport.
The transport an application uses to reach a wallet on the same device, such as HTTP to a local port or a browser window message. The calls are the same whichever is used.
Open in the glossary10 standards, spread across 4 of the 12 topics.
Two web pages from different sites cannot safely reach into each other, which becomes a problem when one of them is your wallet. This uses the browser's own page-to-page messaging so an application can ask a wallet to act while each side stays sealed off from the other.
Filed under Wallet
Substrates and transport is the main subject of this one.
Two web pages from different sites cannot safely reach into each other, which becomes a problem when one of them is your wallet. This uses the browser's own page-to-page messaging so an application can ask a wallet to act while each side stays sealed off from the other.
These are about something else, and deal with substrates and transport on the way.
A joke standard, kept in the repository as the template contributors copy when writing their own. It exists to show the expected shape of a proposal without anyone having to take its subject seriously.
A wallet running on your own machine and a website open in your browser have no natural way to talk to each other. This defines one over ordinary web requests, so any application can reach any wallet on the same device without either side having been built for the other.
Some wallets live inside the browser itself rather than running as a separate program. This gives applications one way to reach those, so a developer writes the same code regardless of where the user's wallet actually runs.
An abstract payment protocol still has to travel over something real. This specifies how it runs over ordinary secure web requests, including the practical size limits that implies.
A peer-to-peer handshake still has to travel over ordinary web requests to work with existing infrastructure. This says exactly which endpoints and headers carry it.
Getting data onto a machine deliberately kept off any network means moving it by eye through a camera. This sends it as a stream of QR codes that keeps going until the receiver has enough, so no missed frame needs re-showing.
Right now if you run two wallet-enabled apps on the same computer, or try to use your phone's wallet from a desktop browser, things break: one app grabs the only expected port, or whichever wallet loads last wins and silently takes over. There was no agreed way for an app to see what wallets are available, let the user pick one, and keep that choice stable without accidentally scrambling which wallet handles which connection.
Carrying data to an offline machine as QR codes fails if a single frame is missed and nobody notices. This frames it as plain text lines with checks that confirm the far side really reassembled the whole thing.
Two wallets that are both online right now still end up sending chat messages, item deliveries and coordination notices through a slow relay server meant for offline delivery, which adds delay for no reason. At the same time, two installs of the same account (like a phone and a laptop) have no good way to tell each other apart or talk directly. This fixes both by letting online wallets message each other straight over an existing direct connection instead.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic