7 standards
How the corpus grows without stranding existing software: extensions an older wallet can ignore safely, reserved identifiers that keep room for future schemes, legacy encodings kept alongside new ones, and profiles that let two systems interoperate.
Also searched as backwards compatible, extension, interoperability, legacy, versioning, vendor neutral, deprecation.
7 standards, spread across 3 of the 12 topics.
If applications are free to use any protocol name they like, a future standard cannot claim one without breaking somebody. This reserves a range of names so later permission schemes have room to exist.
Filed under Wallet
These are about something else, and deal with compatibility and extensions on the way.
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.
If applications are free to use any protocol name they like, a future standard cannot claim one without breaking somebody. This reserves a range of names so later permission schemes have room to exist.
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.
Labels attached to wallet activity are used both for organising and for deciding what an application may see, which means new labelling ideas cannot be added safely. This reserves label space so they can.
An app that wants to greet a returning user by the name of their wallet account has no way to ask the wallet what that account is currently called, so it either guesses, hardcodes a vendor name, or stays silent. This leaves users confused when the same account shows up under different branding across apps or over time. A small, optional way to carry that label alongside the version string the wallet already returns solves this without adding new wallet methods."
A wallet reporting its version to an app used to need one chunky piece of text for every single feature it wanted to advertise, like "offline payments supported" or "color module supported". Stack up a dozen features and the version string blows past old length limits that some apps still enforce, so the wallet either hides capabilities or risks crashing the app. There was no cheap way to say "I support these twelve things" in the same space it used to take to say "I support this one thing".
If your app sends messages between users and those messages contain binary data, like signatures or encrypted blobs, encoding everything as JSON text makes the payload bigger than it needs to be, and that waste gets worse the more binary content you pack in. This matters once you care about bandwidth or are sending a lot of small messages. It makes it possible to send and receive the exact same messages more compactly.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic