PeerServ Message Relay Interface
Sending someone a message directly needs both of you online at the same moment, which often you are not. This defines a message box on a server that holds messages until the recipient comes to collect them.
8 standards
Delivering a message to a party who is not there right now. Standards here define message boxes that hold it until collection, the relay interface in front of them, and the binary encoding used on the wire.
Also searched as message box, PeerServ, relay, message board, inbox, notification.
8 standards, spread across 3 of the 12 topics.
Sending someone a message directly needs both of you online at the same moment, which often you are not. This defines a message box on a server that holds messages until the recipient comes to collect them.
Filed under Peer to peer
Messaging is the main subject of these 5.
Sending someone a message directly needs both of you online at the same moment, which often you are not. This defines a message box on a server that holds messages until the recipient comes to collect them.
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.
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.
Sending someone bitcoin, a token, or a digital asset usually means they have to be online and ask for it first, or you need some separate side channel to tell them a payment is coming and how to claim it. This makes it hard to just drop an asset into someone's account the way you'd send an email, especially when the asset involves extra rules about colors, authority, or expiry that both sides need to agree on and check independently.
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.
These are about something else, and deal with messaging on the way.
Reaching someone online means knowing which service they are on, which stops being true the moment they move. This gives each person a readable handle that resolves wherever they actually are.
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.
Moving coins between two different blockchains usually means trusting an exchange or bridge to hold your funds while the swap happens, and that middleman can freeze, lose, or steal them. This describes a way for two wallets to trade coins across chains directly, so that either the trade completes for both sides or each party simply gets its own coins back, with nobody ever holding the other's funds and neither side needing to be online at the same moment.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic