AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-09 07:38:09 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
e7d3de896642f16de25843e63cc72dc131d11419
rfc-index/status/raw/status-app-protocols.html
status-im-auto e7d3de8966 Update documentation
2025-12-22 13:04:47 +00:00

576 lines
57 KiB
HTML
Raw Blame History

<!DOCTYPE HTML>
<html lang="en" class="ayu" dir="ltr">
<head>
<!-- Book generated using mdBook -->
<meta charset="UTF-8">
<title>Status App Protocols - Vac RFC</title>
<!-- Custom HTML head -->
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#ffffff">
<link rel="icon" href="../../favicon.svg">
<link rel="shortcut icon" href="../../favicon.png">
<link rel="stylesheet" href="../../css/variables.css">
<link rel="stylesheet" href="../../css/general.css">
<link rel="stylesheet" href="../../css/chrome.css">
<link rel="stylesheet" href="../../css/print.css" media="print">
<!-- Fonts -->
<link rel="stylesheet" href="../../FontAwesome/css/font-awesome.css">
<link rel="stylesheet" href="../../fonts/fonts.css">
<!-- Highlight.js Stylesheets -->
<link rel="stylesheet" href="../../highlight.css">
<link rel="stylesheet" href="../../tomorrow-night.css">
<link rel="stylesheet" href="../../ayu-highlight.css">
<!-- Custom theme stylesheets -->
<link rel="stylesheet" href="../../custom.css">
</head>
<body class="sidebar-visible no-js">
<div id="body-container">
<!-- Provide site root to javascript -->
<script>
var path_to_root = "../../";
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "navy" : "ayu";
</script>
<!-- Work around some values being stored in localStorage wrapped in quotes -->
<script>
try {
var theme = localStorage.getItem('mdbook-theme');
var sidebar = localStorage.getItem('mdbook-sidebar');
if (theme.startsWith('"') && theme.endsWith('"')) {
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
}
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
}
} catch (e) { }
</script>
<!-- Set the theme before any content is loaded, prevents flash -->
<script>
var theme;
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
if (theme === null || theme === undefined) { theme = default_theme; }
var html = document.querySelector('html');
html.classList.remove('ayu')
html.classList.add(theme);
var body = document.querySelector('body');
body.classList.remove('no-js')
body.classList.add('js');
</script>
<input type="checkbox" id="sidebar-toggle-anchor" class="hidden">
<!-- Hide / unhide sidebar before it is displayed -->
<script>
var body = document.querySelector('body');
var sidebar = null;
var sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
if (document.body.clientWidth >= 1080) {
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
sidebar = sidebar || 'visible';
} else {
sidebar = 'hidden';
}
sidebar_toggle.checked = sidebar === 'visible';
body.classList.remove('sidebar-visible');
body.classList.add("sidebar-" + sidebar);
</script>
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
<div class="sidebar-scrollbox">
<ol class="chapter"><li class="chapter-item expanded affix "><a href="../../index.html">Introduction</a></li><li class="chapter-item expanded "><a href="../../vac/index.html"><strong aria-hidden="true">1.</strong> Vac</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../vac/1/coss.html"><strong aria-hidden="true">1.1.</strong> 1/COSS</a></li><li class="chapter-item expanded "><a href="../../vac/2/mvds.html"><strong aria-hidden="true">1.2.</strong> 2/MVDS</a></li><li class="chapter-item expanded "><a href="../../vac/3/remote-log.html"><strong aria-hidden="true">1.3.</strong> 3/Remote Log</a></li><li class="chapter-item expanded "><a href="../../vac/4/mvds-meta.html"><strong aria-hidden="true">1.4.</strong> 4/MVDS Meta</a></li><li class="chapter-item expanded "><a href="../../vac/25/libp2p-dns-discovery.html"><strong aria-hidden="true">1.5.</strong> 25/Libp2p DNS Discovery</a></li><li class="chapter-item expanded "><a href="../../vac/32/rln-v1.html"><strong aria-hidden="true">1.6.</strong> 32/RLN-V1</a></li><li class="chapter-item expanded "><a href="../../vac/raw/index.html"><strong aria-hidden="true">1.7.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../vac/raw/consensus-hashgraphlike.html"><strong aria-hidden="true">1.7.1.</strong> Consensus Hashgraphlike</a></li><li class="chapter-item expanded "><a href="../../vac/raw/decentralized-messaging-ethereum.html"><strong aria-hidden="true">1.7.2.</strong> Decentralized Messaging Ethereum</a></li><li class="chapter-item expanded "><a href="../../vac/raw/eth-mls-offchain.html"><strong aria-hidden="true">1.7.3.</strong> ETH MLS Offchain</a></li><li class="chapter-item expanded "><a href="../../vac/raw/eth-mls-onchain.html"><strong aria-hidden="true">1.7.4.</strong> ETH MLS Onchain</a></li><li class="chapter-item expanded "><a href="../../vac/raw/deleted/eth-secpm.html"><strong aria-hidden="true">1.7.5.</strong> ETH SecPM</a></li><li class="chapter-item expanded "><a href="../../vac/raw/gossipsub-tor-push.html"><strong aria-hidden="true">1.7.6.</strong> Gossipsub Tor Push</a></li><li class="chapter-item expanded "><a href="../../vac/raw/logos-capability-discovery.html"><strong aria-hidden="true">1.7.7.</strong> Logos Capability Discovery</a></li><li class="chapter-item expanded "><a href="../../vac/raw/mix.html"><strong aria-hidden="true">1.7.8.</strong> Mix</a></li><li class="chapter-item expanded "><a href="../../vac/raw/noise-x3dh-double-ratchet.html"><strong aria-hidden="true">1.7.9.</strong> Noise X3DH Double Ratchet</a></li><li class="chapter-item expanded "><a href="../../vac/raw/rln-interep-spec.html"><strong aria-hidden="true">1.7.10.</strong> RLN Interep Spec</a></li><li class="chapter-item expanded "><a href="../../vac/raw/rln-stealth-commitments.html"><strong aria-hidden="true">1.7.11.</strong> RLN Stealth Commitments</a></li><li class="chapter-item expanded "><a href="../../vac/raw/rln-v2.html"><strong aria-hidden="true">1.7.12.</strong> RLN-V2</a></li><li class="chapter-item expanded "><a href="../../vac/raw/sds.html"><strong aria-hidden="true">1.7.13.</strong> SDS</a></li></ol></li><li class="chapter-item expanded "><a href="../../vac/template.html"><strong aria-hidden="true">1.8.</strong> Template</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/index.html"><strong aria-hidden="true">2.</strong> Waku</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/core/index.html"><strong aria-hidden="true">2.1.</strong> Standards - Core</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/core/10/waku2.html"><strong aria-hidden="true">2.1.1.</strong> 10/Waku2</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/11/relay.html"><strong aria-hidden="true">2.1.2.</strong> 11/Relay</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/12/filter.html"><strong aria-hidden="true">2.1.3.</strong> 12/Filter</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/13/store.html"><strong aria-hidden="true">2.1.4.</strong> 13/Store</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/14/message.html"><strong aria-hidden="true">2.1.5.</strong> 14/Message</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/15/bridge.html"><strong aria-hidden="true">2.1.6.</strong> 15/Bridge</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/17/rln-relay.html"><strong aria-hidden="true">2.1.7.</strong> 17/RLN Relay</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/19/lightpush.html"><strong aria-hidden="true">2.1.8.</strong> 19/Lightpush</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/31/enr.html"><strong aria-hidden="true">2.1.9.</strong> 31/ENR</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/33/discv5.html"><strong aria-hidden="true">2.1.10.</strong> 33/Discv5</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/34/peer-exchange.html"><strong aria-hidden="true">2.1.11.</strong> 34/Peer Exchange</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/36/bindings-api.html"><strong aria-hidden="true">2.1.12.</strong> 36/Bindings API</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/64/network.html"><strong aria-hidden="true">2.1.13.</strong> 64/Network</a></li><li class="chapter-item expanded "><a href="../../waku/standards/core/66/metadata.html"><strong aria-hidden="true">2.1.14.</strong> 66/Metadata</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/standards/application/index.html"><strong aria-hidden="true">2.2.</strong> Standards - Application</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/application/20/toy-eth-pm.html"><strong aria-hidden="true">2.2.1.</strong> 20/Toy ETH PM</a></li><li class="chapter-item expanded "><a href="../../waku/standards/application/26/payload.html"><strong aria-hidden="true">2.2.2.</strong> 26/Payload</a></li><li class="chapter-item expanded "><a href="../../waku/standards/application/53/x3dh.html"><strong aria-hidden="true">2.2.3.</strong> 53/X3DH</a></li><li class="chapter-item expanded "><a href="../../waku/standards/application/54/x3dh-sessions.html"><strong aria-hidden="true">2.2.4.</strong> 54/X3DH Sessions</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/index.html"><strong aria-hidden="true">2.3.</strong> Standards - Legacy</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/standards/legacy/6/waku1.html"><strong aria-hidden="true">2.3.1.</strong> 6/Waku1</a></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/7/data.html"><strong aria-hidden="true">2.3.2.</strong> 7/Data</a></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/8/mail.html"><strong aria-hidden="true">2.3.3.</strong> 8/Mail</a></li><li class="chapter-item expanded "><a href="../../waku/standards/legacy/9/rpc.html"><strong aria-hidden="true">2.3.4.</strong> 9/RPC</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/informational/index.html"><strong aria-hidden="true">2.4.</strong> Informational</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/informational/22/toy-chat.html"><strong aria-hidden="true">2.4.1.</strong> 22/Toy Chat</a></li><li class="chapter-item expanded "><a href="../../waku/informational/23/topics.html"><strong aria-hidden="true">2.4.2.</strong> 23/Topics</a></li><li class="chapter-item expanded "><a href="../../waku/informational/27/peers.html"><strong aria-hidden="true">2.4.3.</strong> 27/Peers</a></li><li class="chapter-item expanded "><a href="../../waku/informational/29/config.html"><strong aria-hidden="true">2.4.4.</strong> 29/Config</a></li><li class="chapter-item expanded "><a href="../../waku/informational/30/adaptive-nodes.html"><strong aria-hidden="true">2.4.5.</strong> 30/Adaptive Nodes</a></li></ol></li><li class="chapter-item expanded "><a href="../../waku/deprecated/index.html"><strong aria-hidden="true">2.5.</strong> Deprecated</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../waku/deprecated/5/waku0.html"><strong aria-hidden="true">2.5.1.</strong> 5/Waku0</a></li><li class="chapter-item expanded "><a href="../../waku/deprecated/16/rpc.html"><strong aria-hidden="true">2.5.2.</strong> 16/RPC</a></li><li class="chapter-item expanded "><a href="../../waku/deprecated/18/swap.html"><strong aria-hidden="true">2.5.3.</strong> 18/Swap</a></li><li class="chapter-item expanded "><a href="../../waku/deprecated/fault-tolerant-store.html"><strong aria-hidden="true">2.5.4.</strong> Fault Tolerant Store</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="../../nomos/index.html"><strong aria-hidden="true">3.</strong> Nomos</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../nomos/raw/index.html"><strong aria-hidden="true">3.1.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../nomos/raw/nomosda-encoding.html"><strong aria-hidden="true">3.1.1.</strong> NomosDA Encoding</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/nomosda-network.html"><strong aria-hidden="true">3.1.2.</strong> NomosDA Network</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-hardware-requirements.html"><strong aria-hidden="true">3.1.3.</strong> P2P Hardware Requirements</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-nat-solution.html"><strong aria-hidden="true">3.1.4.</strong> P2P NAT Solution</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-network-bootstrapping.html"><strong aria-hidden="true">3.1.5.</strong> P2P Network Bootstrapping</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/p2p-network.html"><strong aria-hidden="true">3.1.6.</strong> P2P Network</a></li><li class="chapter-item expanded "><a href="../../nomos/raw/sdp.html"><strong aria-hidden="true">3.1.7.</strong> SDP</a></li></ol></li><li class="chapter-item expanded "><a href="../../nomos/deprecated/index.html"><strong aria-hidden="true">3.2.</strong> Deprecated</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../nomos/deprecated/claro.html"><strong aria-hidden="true">3.2.1.</strong> Claro</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="../../codex/index.html"><strong aria-hidden="true">4.</strong> Codex</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../codex/raw/index.html"><strong aria-hidden="true">4.1.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../codex/raw/codex-block-exchange.html"><strong aria-hidden="true">4.1.1.</strong> Block Exchange</a></li><li class="chapter-item expanded "><a href="../../codex/raw/codex-marketplace.html"><strong aria-hidden="true">4.1.2.</strong> Marketplace</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="../../status/index.html"><strong aria-hidden="true">5.</strong> Status</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../status/24/curation.html"><strong aria-hidden="true">5.1.</strong> 24/Curation</a></li><li class="chapter-item expanded "><a href="../../status/28/featuring.html"><strong aria-hidden="true">5.2.</strong> 28/Featuring</a></li><li class="chapter-item expanded "><a href="../../status/55/1to1-chat.html"><strong aria-hidden="true">5.3.</strong> 55/1-to-1 Chat</a></li><li class="chapter-item expanded "><a href="../../status/56/communities.html"><strong aria-hidden="true">5.4.</strong> 56/Communities</a></li><li class="chapter-item expanded "><a href="../../status/61/community-history-service.html"><strong aria-hidden="true">5.5.</strong> 61/Community History Service</a></li><li class="chapter-item expanded "><a href="../../status/62/payloads.html"><strong aria-hidden="true">5.6.</strong> 62/Payloads</a></li><li class="chapter-item expanded "><a href="../../status/63/keycard-usage.html"><strong aria-hidden="true">5.7.</strong> 63/Keycard Usage</a></li><li class="chapter-item expanded "><a href="../../status/65/account-address.html"><strong aria-hidden="true">5.8.</strong> 65/Account Address</a></li><li class="chapter-item expanded "><a href="../../status/71/push-notification-server.html"><strong aria-hidden="true">5.9.</strong> 71/Push Notification Server</a></li><li class="chapter-item expanded "><a href="../../status/raw/index.html"><strong aria-hidden="true">5.10.</strong> Raw</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../status/raw/simple-scaling.html"><strong aria-hidden="true">5.10.1.</strong> Simple Scaling</a></li><li class="chapter-item expanded "><a href="../../status/raw/status-app-protocols.html" class="active"><strong aria-hidden="true">5.10.2.</strong> Status App Protocols</a></li><li class="chapter-item expanded "><a href="../../status/raw/status-mvds.html"><strong aria-hidden="true">5.10.3.</strong> Status MVDS</a></li><li class="chapter-item expanded "><a href="../../status/raw/url-data.html"><strong aria-hidden="true">5.10.4.</strong> URL Data</a></li><li class="chapter-item expanded "><a href="../../status/raw/url-scheme.html"><strong aria-hidden="true">5.10.5.</strong> URL Scheme</a></li></ol></li><li class="chapter-item expanded "><a href="../../status/deprecated/index.html"><strong aria-hidden="true">5.11.</strong> Deprecated</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="../../status/deprecated/3rd-party.html"><strong aria-hidden="true">5.11.1.</strong> 3rd Party</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/account.html"><strong aria-hidden="true">5.11.2.</strong> Account</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/client.html"><strong aria-hidden="true">5.11.3.</strong> Client</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/dapp-browser-API-usage.html"><strong aria-hidden="true">5.11.4.</strong> Dapp Browser API Usage</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/eips.html"><strong aria-hidden="true">5.11.5.</strong> EIPs</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/ethereum-usage.html"><strong aria-hidden="true">5.11.6.</strong> Ethereum Usage</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/group-chat.html"><strong aria-hidden="true">5.11.7.</strong> Group Chat</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/IPFS-gateway-for-sticker-Pack.html"><strong aria-hidden="true">5.11.8.</strong> IPFS Gateway for Sticker Pack</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/keycard-usage-for-wallet-and-chat-keys.html"><strong aria-hidden="true">5.11.9.</strong> Keycard Usage for Wallet and Chat Keys</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/notifications.html"><strong aria-hidden="true">5.11.10.</strong> Notifications</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/payloads.html"><strong aria-hidden="true">5.11.11.</strong> Payloads</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/push-notification-server.html"><strong aria-hidden="true">5.11.12.</strong> Push Notification Server</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/secure-transport.html"><strong aria-hidden="true">5.11.13.</strong> Secure Transport</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/waku-mailserver.html"><strong aria-hidden="true">5.11.14.</strong> Waku Mailserver</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/waku-usage.html"><strong aria-hidden="true">5.11.15.</strong> Waku Usage</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/whisper-mailserver.html"><strong aria-hidden="true">5.11.16.</strong> Whisper Mailserver</a></li><li class="chapter-item expanded "><a href="../../status/deprecated/whisper-usage.html"><strong aria-hidden="true">5.11.17.</strong> Whisper Usage</a></li></ol></li></ol></li></ol>
</div>
<div id="sidebar-resize-handle" class="sidebar-resize-handle">
<div class="sidebar-resize-indicator"></div>
</div>
</nav>
<!-- Track and set sidebar scroll position -->
<script>
var sidebarScrollbox = document.querySelector('#sidebar .sidebar-scrollbox');
sidebarScrollbox.addEventListener('click', function(e) {
if (e.target.tagName === 'A') {
sessionStorage.setItem('sidebar-scroll', sidebarScrollbox.scrollTop);
}
}, { passive: true });
var sidebarScrollTop = sessionStorage.getItem('sidebar-scroll');
sessionStorage.removeItem('sidebar-scroll');
if (sidebarScrollTop) {
// preserve sidebar scroll position when navigating via links within sidebar
sidebarScrollbox.scrollTop = sidebarScrollTop;
} else {
// scroll sidebar to current active section when navigating via "next/previous chapter" buttons
var activeSection = document.querySelector('#sidebar .active');
if (activeSection) {
activeSection.scrollIntoView({ block: 'center' });
}
}
</script>
<div id="page-wrapper" class="page-wrapper">
<div class="page">
<div id="menu-bar-hover-placeholder"></div>
<div id="menu-bar" class="menu-bar sticky">
<div class="left-buttons">
<label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
<i class="fa fa-bars"></i>
</label>
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
<i class="fa fa-paint-brush"></i>
</button>
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
<li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
</ul>
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
<i class="fa fa-search"></i>
</button>
</div>
<h1 class="menu-title">Vac RFC</h1>
<div class="right-buttons">
<a href="../../print.html" title="Print this book" aria-label="Print this book">
<i id="print-button" class="fa fa-print"></i>
</a>
<a href="https://github.com/vacp2p/rfc-index" title="Git repository" aria-label="Git repository">
<i id="git-repository-button" class="fa fa-github"></i>
</a>
</div>
</div>
<div id="search-wrapper" class="hidden">
<form id="searchbar-outer" class="searchbar-outer">
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
</form>
<div id="searchresults-outer" class="searchresults-outer hidden">
<div id="searchresults-header" class="searchresults-header"></div>
<ul id="searchresults">
</ul>
</div>
</div>
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
<script>
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
});
</script>
<div id="content" class="content">
<main>
<h1 id="status-protocols"><a class="header" href="#status-protocols">STATUS-PROTOCOLS</a></h1>
<div class="rfc-meta">
<table>
<tr><th>Name</th><td>Status Protocol Stack</td></tr>
<tr><th>Status</th><td>raw</td></tr>
<tr><th>Category</th><td>Standards Track</td></tr>
<tr><th>Editor</th><td>Hanno Cornelius &lt;hanno@status.im&gt;</td></tr>
<tr><th>Contributors</th><td>Jimmy Debe &lt;jimmy@status.im&gt;<br>Aaryamann Challani &lt;p1ge0nh8er@proton.me&gt;</td></tr>
</table>
</div>
<!-- timeline:start -->
<h2 id="timeline"><a class="header" href="#timeline">Timeline</a></h2>
<ul>
<li><strong>2025-12-22</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/b1a578393edf8487ccc97a5f25b25af9bf41efb3/docs/status/raw/status-app-protocols.md"><code>b1a5783</code></a> — Chore/mdbook updates (#237)</li>
<li><strong>2025-12-18</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/d03e699084774ebecef9c6d4662498907c5e2080/docs/status/raw/status-app-protocols.md"><code>d03e699</code></a> — ci: add mdBook configuration (#233)</li>
<li><strong>2025-03-07</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/f4b34afd1a1e198b0d99b911bf8b371b5b13a6b8/status/raw/status-app-protocols.md"><code>f4b34af</code></a> — Fix Linting Errors (#135)</li>
<li><strong>2025-02-21</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/9bed57e4ad5d6609202a18f581a00b2fd81f6acb/status/raw/status-app-protocols.md"><code>9bed57e</code></a> — docs: define basic sharding for Communities (#132)</li>
<li><strong>2024-11-20</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/776c1b76cda73aa1feaf5746a4cdb56b6836b4be/status/raw/status-app-protocols.md"><code>776c1b7</code></a> — rfc-index: Update (#110)</li>
<li><strong>2024-10-25</strong> — <a href="https://github.com/vacp2p/rfc-index/blob/37b3edfba3a103ef138a345a2a0cac7f28c07f7a/status/raw/status-app-protocols.md"><code>37b3edf</code></a> — docs: add spec for status protocol stack, deprecate waku-usage spec (#105)</li>
</ul>
<!-- timeline:end -->
<h2 id="abstract"><a class="header" href="#abstract">Abstract</a></h2>
<p>This specification describes the Status Application protocol stack.
It focuses on elements and features in the protocol stack for all application-level functions:</p>
<ul>
<li>functional scope (also <em>broadcast audience</em>)</li>
<li>content topic</li>
<li>ephemerality</li>
<li>end-to-end reliability layer</li>
<li>encryption layer</li>
<li>transport layer (Waku)</li>
</ul>
<p>It also introduces strategies to restrict resource usage, distribute large messages, etc.
Application-level functions are out of scope and specified separately. See:</p>
<ul>
<li><a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a></li>
<li><a href="../56/communities.html">56/STATUS-COMMUNITIES</a></li>
</ul>
<h2 id="status-protocol-stack"><a class="header" href="#status-protocol-stack">Status protocol stack</a></h2>
<p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in <a href="https://www.ietf.org/rfc/rfc2119.txt">2119</a>.
See the simplified diagram of the Status application protocol stack:</p>
<div class="table-wrapper"><table><thead><tr><th></th></tr></thead><tbody>
<tr><td>Status application layer</td></tr>
<tr><td>End-to-end reliability layer</td></tr>
<tr><td>Encryption layer</td></tr>
<tr><td>Transport layer (Waku)</td></tr>
<tr><td></td></tr>
</tbody></table>
</div>
<h2 id="status-application-layer"><a class="header" href="#status-application-layer">Status application layer</a></h2>
<p>Application level functions are defined in the <em>application</em> layer.
Status currently defines functionality to support three main application features:</p>
<ul>
<li>Status Communities, as specified in <a href="../56/communities.html">56/STATUS-COMMUNITIES</a></li>
<li>Status 1:1 Chat, as specified in <a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a></li>
<li>Status Private Group Chat, as specified in a subsection of <a href="../55/1to1-chat.html#negotiation-of-a-11-chat-amongst-multiple-participants-group-chat">55/STATUS-1TO1-CHAT</a></li>
</ul>
<!-- TODO: list functions not related to main app features, such as user sync, backup, push notifications, etc. -->
<p>Each application-level function, regardless which feature set it supports, has the following properties:</p>
<ol>
<li>Functional scope</li>
<li>Content topic</li>
<li>Ephemerality</li>
</ol>
<h3 id="functional-scope"><a class="header" href="#functional-scope">Functional Scope</a></h3>
<p>Each Status app-level message MUST define a functional scope.
The functional scope MUST define the <em>minimum</em> scope of the audience that should <em>participate</em> in the app function the message is related to.
In other words, it determines the minimum subset of Status app participants
that should have access to messages related to that function.</p>
<p>Note that the functional scope is distinct from the number of participants that is <em>addressed</em> by a specific message.
For example, a participant will address a 1:1 chat to only one other participant.
However, since all users of the Status app MUST be able to participate in 1:1 chats,
the functional scope of messages enabling 1:1 chats MUST be a global scope.
Similarly, since private group chats can be set up between any subset of Status app users,
the functional scope for messages related to private group chats MUST be global.
Along the same principle, messages that originate within communities are of global interest
for all users who have an interest in the Status Communities feature.
Such messages MUST have a global functional scope,
that can be accessed by any app users interested in communities.
A different group of messages are addressed only to the participant that generated those messages itself.
These <em>self-addressed</em> messages MUST have a local functional scope.</p>
<p>If we further make a distinction between "control" and "content" messages,
we can distinguish five distinct functional scopes.</p>
<p>All Status messages MUST have one of these functional scopes:</p>
<h4 id="global-general-scope"><a class="header" href="#global-general-scope">Global general scope</a></h4>
<ol>
<li><em>Global control</em>: messages enabling the basic functioning of the app to control general features that all app users should be able to participate in. Examples include Contact Requests, global Status Updates, Group Chat Invites, etc.</li>
<li><em>Global content</em>: messages carrying user-generated content for global functions. Examples include 1:1 chat messages, images shared over private group chats, etc.</li>
</ol>
<h4 id="global-community-scope"><a class="header" href="#global-community-scope">Global community scope</a></h4>
<ol>
<li><em>Global community control</em>: messages enabling the basic functioning of the app to control features related to communities. Examples include Community Invites, Community Membership Updates, community Status Updates, etc.</li>
<li><em>Global community content</em>: messages carrying user-generated content for members of any community.</li>
</ol>
<blockquote>
<p><strong>Note:</strong> a previous iteration of the Status Communities feature defined separate community-wide scopes for each community.
However, this model was deprecated and all communities now operate on a global, shared scope.
This implies that different communities will share shards on the routing layer.</p>
</blockquote>
<h4 id="local-scope"><a class="header" href="#local-scope">Local scope</a></h4>
<ol>
<li><em>Local</em>: messages related to functions that are only relevant to a single user. Also known as <em>self-addressed messages</em>. Examples include messages used to exchange information between app installations, such as User Backup and Sync messages.</li>
</ol>
<p>Note that the functional scope is a logical property of Status messages.
It SHOULD however inform the underlying <a href="#pubsub-topics-and-sharding">transport layer sharding</a> and <a href="#subscribing">transport layer subscriptions</a>.
In general a Status client SHOULD subscribe to participate in:</p>
<ul>
<li>all global functions</li>
<li>global community functions if it is interested in this feature, and</li>
<li>its own local functions.</li>
</ul>
<h3 id="content-topics"><a class="header" href="#content-topics">Content topics</a></h3>
<p>Each Status app-level message MUST define a content topic that links messages in related app-level functions and sub-functions together.
This MUST be based on the filter use cases for <a href="#subscribing">transport layer subscriptions</a>
and <a href="#retrieving-historical-messages">retrieving historical messages</a>.
A content topic SHOULD be identical across all messages that are always part of the same filter use case (or always form part of the same content-filtered query criteria).
In other words, the number of content topics defined in the app SHOULD match the number of filter use cases.
For the sake of illustration, consider the following common content topic and filter use cases:</p>
<ul>
<li>if all messages belonging to the same 1:1 chat are always filtered together, they SHOULD use the same content topic (see <a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a>)</li>
<li>if all messages belonging to the same Community are always filtered together, they SHOULD use the same content topic (see <a href="../56/communities.html">56/STATUS-COMMUNITIES</a>).</li>
</ul>
<p>The app-level content topic MUST be populated in the <code>content_topic</code> field in the encapsulating Waku message (see <a href="#waku-messages">Waku messages</a>).</p>
<h3 id="ephemerality"><a class="header" href="#ephemerality">Ephemerality</a></h3>
<p>Each Status app-level message MUST define its <em>ephemerality</em>.
Ephemerality is a boolean value, set to <code>true</code> if a message is considered ephemeral.
Ephemeral messages are messages emitted by the app that are transient in nature.
They only have temporary "real-time" value
and SHOULD NOT be stored and retrievable from historical message stores and sync caches.
Similarly, ephemeral message delivery is best-effort in nature and SHOULD NOT be considered in message reliability mechanisms (see <a href="#end-to-end-reliability-layer">End-to-end reliability layer</a>).</p>
<p>An example of ephemeral messages would be periodic status update messages, indicating a particular user's online status.
Since only a user's current online status is of value, there is no need to store historical status update messages.
Since status updates are periodic, there is no strong need for end-to-end reliability as subsequent updates are always to follow.</p>
<p>App-level messages that are considered ephemeral, MUST set the <code>ephemeral</code> field in the encapsulating Waku message to <code>true</code> (see <a href="#waku-messages">Waku messages</a>)</p>
<h2 id="end-to-end-reliability-layer"><a class="header" href="#end-to-end-reliability-layer">End-to-end reliability layer</a></h2>
<p>The end-to-end reliability layer contains the functions related to one of the two end-to-end reliability schemes defined for Status app messages:</p>
<ol>
<li>Minimum Viable protocol for Data Synchronisation, or MVDS (see <a href="./status-mvds.html">STATUS-MVDS-USAGE</a>)</li>
<li>Scalable distributed log reliability (spec and a punchier name TBD, see the <a href="https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16">original forum post announcement</a>)</li>
</ol>
<p>Ephemeral messages SHOULD omit this layer.
Non-ephemeral 1:1 chat messages SHOULD make use of MVDS to achieve reliable data synchronisation between the two parties involved in the communication.
Non-ephemeral private group chat messages build on a set of 1:1 chat links
and consequently SHOULD also make use of MVDS to achieve reliable data synchronisation between all parties involved in the communication.
Non-ephemeral 1:1 and private group chat messages MAY make use of of <a href="https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16">scalable distributed log reliability</a> in future.
Since MVDS does not scale for large number of participants in the communication,
non-ephemeral community messages MUST use scalable distributed log reliability as defined in this <a href="https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16">original forum post announcement</a>.
The app MUST use a single channel ID per community.</p>
<h2 id="encryption-layer"><a class="header" href="#encryption-layer">Encryption layer</a></h2>
<p>The encryption layer wraps the Status App and Reliability layers in an encrypted payload.</p>
<!-- TODO: This section is TBD. We may want to design a way for Communities to use de-MLS in a separate spec and generally simplify Status encryption. -->
<h2 id="waku-transport-layer"><a class="header" href="#waku-transport-layer">Waku transport layer</a></h2>
<p>The Waku transport layer contains the functions allowing Status protocols to use <a href="../../waku/standards/core/10/waku2.html">10/WAKU2</a> infrastructure as transport.</p>
<h3 id="waku-messages"><a class="header" href="#waku-messages">Waku messages</a></h3>
<p>Each Status application message MUST be transformed to a <a href="../../waku/standards/core/14/message.html">14/WAKU2-MESSAGE</a> with the following structure:</p>
<pre><code class="language-protobuf">syntax = "proto3";
message WakuMessage {
bytes payload = 1;
string content_topic = 2;
optional uint32 version = 3;
optional sint64 timestamp = 10;
optional bytes meta = 11;
optional bool ephemeral = 31;
}
</code></pre>
<ul>
<li><code>payload</code> MUST be set to the full encrypted payload received from the higher layers</li>
<li><code>version</code> MUST be set to <code>1</code></li>
<li><code>ephemeral</code> MUST be set to <code>true</code> if the app-level message is ephemeral</li>
<li><code>content_topic</code> MUST be set to the app-level content topic</li>
<li><code>timestamp</code> MUST be set to the current Unix epoch timestamp (in nanosecond precision)</li>
</ul>
<h3 id="pubsub-topics-and-sharding"><a class="header" href="#pubsub-topics-and-sharding">Pubsub topics and sharding</a></h3>
<p>All Waku messages are published to pubsub topics as defined in <a href="../../waku/informational/23/topics.html">23/WAKU2-TOPICS</a>.
Since pubsub topics define a routing layer for messages,
they can be used to shard traffic.
The pubsub topic used for publishing a message depends on the app-level <a href="#functional-scope">functional scope</a>.</p>
<h4 id="self-addressed-messages"><a class="header" href="#self-addressed-messages">Self-addressed messages</a></h4>
<p>The application MUST define at least one distinct pubsub topic for self-addressed messages.
The application MAY define a set of more than one pubsub topic for self-addressed messages to allow traffic sharding for scalability.</p>
<h4 id="global-messages"><a class="header" href="#global-messages">Global messages</a></h4>
<p>The application MUST define at least one distinct pubsub topic for global control messages and global content messages.
The application MAY defined a set of more than one pubsub topic for global messages to allow traffic sharding for scalability.
It is RECOMMENDED that separate pubsub topics be used for global control messages and global content messages.</p>
<h4 id="community-messages"><a class="header" href="#community-messages">Community messages</a></h4>
<p>The application SHOULD define at least one distinct pubsub topic for global community control messages and global community content messages.
The application MAY define a set of more than one pubsub topic for global community messages to allow traffic sharding for scalability.
It is RECOMMENDED that separate pubsub topics be used for global community control messages and global community content messages.</p>
<h4 id="large-messages"><a class="header" href="#large-messages">Large messages</a></h4>
<p>The application MAY define separate pubsub topics for large messages.
These pubsub topics for large messages MAY be distinct for each functional scope.</p>
<h3 id="resource-usage"><a class="header" href="#resource-usage">Resource usage</a></h3>
<p>The application SHOULD use a range of Waku protocols to interact with the Waku transport layer.
The specific set of Waku protocols used depend on desired functionality and resource usage profile for the specific client.
Resources can be restricted in terms of bandwidth and computing resources.</p>
<p>Waku protocols that are more appropriate for resource-restricted environments are often termed "light protocols".
Waku protocols that consume more resources, but simultaneously contribute more to Waku infrastructure, are often termed "full protocols".
The terms "full" and "light" is just a useful abstraction than a strict binary, though,
and Status clients can operate along a continuum of resource usage profiles,
each using the combination of "full" and "light" protocols most appropriate to match its environment and motivations.</p>
<p>To simplify interaction with the selection of "full" and "light" protocols,
Status clients MUST define a "full mode" and "light mode"
to allow users to select whether their client would prefer "full protocols" or "light protocols" by default.
Status Desktop clients are assumed to have more resources available and SHOULD use full mode by default.
Status Mobile clients are assumed to operate with more resource restrictions and SHOULD use light mode by default.</p>
<p>For the purposes of the rest of this document,
clients in full mode will be referred to as "full clients" and
clients in light mode will be referred to as "light clients".</p>
<h3 id="discovery"><a class="header" href="#discovery">Discovery</a></h3>
<p>The application MUST make use of at least one discovery method to discover and connect to Waku peers
useful for the user functions specific to that instance of the application.</p>
<p>The specific Waku discovery protocol used for discovery depends on the use case and resource-availability of the client.</p>
<ol>
<li><a href="https://eips.ethereum.org/EIPS/eip-1459">EIP-1459: DNS-based discovery</a> is useful for initial connection to bootstrap peers.</li>
<li><a href="../../waku/standards/core/33/discv5.html">33/WAKU2-DISCV5</a> allows decentralized discovery of Waku peers.</li>
<li><a href="https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md">34/WAKU2-PEER-EXCHANGE</a> allows requesting peers from a service node
and is appropriate for resource-restricted discovery.</li>
</ol>
<p>All clients SHOULD use DNS-based discovery on startup
to discover a set of bootstrap peers for initial connection.</p>
<p>Full clients SHOULD use <a href="../../waku/standards/core/33/discv5.html">33/WAKU2-DISCV5</a> for continuous ambient peer discovery.</p>
<p>Light clients SHOULD use <a href="https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md">34/WAKU2-PEER-EXCHANGE</a> to discover a set of service peers
used by that instance of the application.</p>
<h3 id="subscribing"><a class="header" href="#subscribing">Subscribing</a></h3>
<p>The application MUST subscribe to receive the traffic necessary for minimal app operation
and to enable the user functions specific to that instance of the application.</p>
<p>The specific Waku protocol used for subscription depends on the resource-availability of the client:</p>
<ol>
<li>Filter client protocol, as specified in <a href="../../waku/standards/core/12/filter.html">12/WAKU2-FILTER</a>, allows subscribing for traffic with content topic granularity and is appropriate for resource-restricted subscriptions.</li>
<li>Relay protocol, as specified in <a href="../../waku/standards/core/11/relay.html">11/WAKU2-RELAY</a>, allows subscribing to traffic only with pubsub topic granularity and therefore is more resource-intensive. Relay subscription also allows the application instance to contribute to the overall routing infrastructure, which adds to its overall higher resource usage but benefits the ecosystem.</li>
</ol>
<p>Full clients SHOULD use relay protocol as preferred method to subscribe to pubsub topics matching the scopes:</p>
<ol>
<li>Global control</li>
<li>Global content</li>
<li>Global community control, if the client has activated the Status Communities feature</li>
<li>Global community content, if the client has activated the Status Communities feature</li>
</ol>
<p>Light clients SHOULD use filter protocol to subscribe only to the content topics relevant to the user.</p>
<h4 id="self-addressed-messages-1"><a class="header" href="#self-addressed-messages-1">Self-addressed messages</a></h4>
<p>Status clients (full or light) MUST NOT subscribe to topics for messages with self-addressed scopes.
See <a href="#self-addressed-messages-4">Self-addressed messages</a>.</p>
<h4 id="large-messages-1"><a class="header" href="#large-messages-1">Large messages</a></h4>
<p>Status clients (full or light) SHOULD NOT subscribe to topics set aside for large messages.
See <a href="#large-messages-4">Large messages</a>.</p>
<h3 id="publishing"><a class="header" href="#publishing">Publishing</a></h3>
<p>The application MUST publish user and app generated messages via the Waku transport layer.
The specific Waku protocol used for publishing depends on the resource-availability of the client:</p>
<ol>
<li>Lightpush protocol, as specified in <a href="../../waku/standards/core/19/lightpush.html">19/WAKU2-LIGHTPUSH</a> allows publishing to a pubsub topic via an intermediate "full node" and is more appropriate for resource-restricted publishing.</li>
<li>Relay protocol, as specified in <a href="../../waku/standards/core/11/relay.html">11/WAKU2-RELAY</a>, allows publishing directly into the relay routing network and is therefore more resource-intensive.</li>
</ol>
<p>Full clients SHOULD use relay protocol to publish to pubsub topics matching the scopes:</p>
<ol>
<li>Global control</li>
<li>Global content</li>
<li>Global community control, if the client has activated the Status Communities feature</li>
<li>Global community content, if the client has activated the Status Communities feature</li>
</ol>
<p>Light clients SHOULD use lightpush protocol to publish control and content messages.</p>
<h4 id="self-addressed-messages-2"><a class="header" href="#self-addressed-messages-2">Self-addressed messages</a></h4>
<p>Status clients (full or light) MUST use lightpush protocol to publish self-addressed messages.
See <a href="#self-addressed-messages-4">Self-addressed messages</a>.</p>
<h4 id="large-messages-2"><a class="header" href="#large-messages-2">Large messages</a></h4>
<p>Status clients (full or light) SHOULD use lightpush protocols to publish to pubsub topics set aside for large messages.
See <a href="#large-messages-4">Large messages</a>.</p>
<h3 id="retrieving-historical-messages"><a class="header" href="#retrieving-historical-messages">Retrieving historical messages</a></h3>
<p>Status clients SHOULD use the store query protocol, as specified in <a href="https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md">WAKU2-STORE</a>, to retrieve historical messages relevant to the client from store service nodes in the network.</p>
<p>Status clients SHOULD use <a href="https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md#content-filtered-queries">content filtered queries</a> with <code>include_data</code> set to <code>true</code>,
to retrieve the full contents of historical messages that the client may have missed during offline periods,
or to populate the local message database when the client starts up for the first time.</p>
<h4 id="store-queries-for-reliability"><a class="header" href="#store-queries-for-reliability">Store queries for reliability</a></h4>
<p>Status clients MAY use periodic content filtered queries with <code>include_data</code> set to <code>false</code>,
to retrieve only the message hashes of past messages on content topics relevant to the client.
This can be used to compare the hashes available in the local message database with the hashes in the query response
in order to identify possible missing messages.
Once the Status client has identified a set of missing message hashes
it SHOULD use <a href="https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md#message-hash-lookup-queries">message hash lookup queries</a> with <code>include_data</code> set to <code>true</code>
to retrieve the full contents of the missing messages based on the hash.</p>
<p>Status clients MAY use <a href="https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md#presence-queries">presence queries</a>
to determine if one or more message hashes known to the client is present in the store service node.
Clients MAY use this method to determine if a message that originated from the client
has been successfully stored.</p>
<h4 id="self-addressed-messages-3"><a class="header" href="#self-addressed-messages-3">Self-addressed messages</a></h4>
<p>Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve self-addressed messages relevant to that client.
See <a href="#self-addressed-messages-4">Self-addressed messages</a>.</p>
<h4 id="large-messages-3"><a class="header" href="#large-messages-3">Large messages</a></h4>
<p>Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve large messages relevant to that client.
See <a href="#large-messages-4">Large messages</a>.</p>
<h3 id="providing-services"><a class="header" href="#providing-services">Providing services</a></h3>
<p>Status clients MAY provide service-side protocols to other clients.</p>
<p>Full clients SHOULD mount
the filter service protocol (see <a href="../../waku/standards/core/12/filter.html">12/WAKU2-FILTER</a>)
and lightpush service protocol (see <a href="../../waku/standards/core/19/lightpush.html">19/WAKU2-LIGHTPUSH</a>)
in order to provide light subscription and publishing services to other clients
for each pubsub topic to which they have a relay subscription.</p>
<p>Full clients SHOULD mount
the peer exchange service protocol (see <a href="https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md">34/WAKU2-PEER-EXCHANGE</a>)
to provide light discovery services to other clients.</p>
<p>Status clients MAY mount the store query protocol as service node (see <a href="https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md">WAKU2-STORE</a>)
to store historical messages and
provide store services to other clients
for each pubsub topic to which they have a relay subscription</p>
<h3 id="self-addressed-messages-4"><a class="header" href="#self-addressed-messages-4">Self-addressed messages</a></h3>
<p>Messages with a <em>local</em> functional scope (see <a href="#functional-scope">Functional scope</a>),
also known as <em>self-addressed</em> messages,
MUST be published to a distinct pubsub topic or a distinct <em>set</em> of pubsub topics
used exclusively for messages with local scope (see <a href="#pubsub-topics-and-sharding">Pubsub topics and sharding</a>).
Status clients (full or light) MUST use lightpush protocol to publish self-addressed messages (see <a href="#publishing">Publishing</a>).
Status clients (full or light) MUST NOT subscribe to topics for messages with self-addressed scopes (see <a href="#subscribing">Subscribing</a>).
Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve self-addressed messages relevant to that client (see <a href="#retrieving-historical-messages">Retrieving historical messages</a>).</p>
<h3 id="large-messages-4"><a class="header" href="#large-messages-4">Large messages</a></h3>
<p>The application MAY define separate pubsub topics for large messages.
These pubsub topics for large messages MAY be distinct for each functional scope (see <a href="#pubsub-topics-and-sharding">Pubsub topics and sharding</a>).
Status clients (full or light) SHOULD use lightpush protocols to publish to pubsub topics set aside for large messages (see <a href="#publishing">Publishing</a>).
Status clients (full or light) SHOULD NOT subscribe to topics set aside for large messages (see <a href="#subscribing">Subscribing</a>).
Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve large messages relevant to that client (see <a href="#retrieving-historical-messages">Retrieving historical messages</a>).</p>
<h4 id="chunking"><a class="header" href="#chunking">Chunking</a></h4>
<p>The Status application MAY use a chunking mechanism to break down large payloads
into smaller segments for individual Waku transport.
The definition of a large message is up to the application.
However, the maximum size for a <a href="../../waku/standards/core/14/message.html">14/WAKU2-MESSAGE</a> payload is 150KB.
Status application payloads that exceed this size MUST be chunked into smaller pieces
and MUST be considered a "large message".</p>
<h2 id="copyright"><a class="header" href="#copyright">Copyright</a></h2>
<p>Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>.</p>
<h2 id="references"><a class="header" href="#references">References</a></h2>
<ol>
<li><a href="../55/1to1-chat.html">55/STATUS-1TO1-CHAT</a></li>
<li><a href="../56/communities.html">56/STATUS-COMMUNITIES</a></li>
<li><a href="../../waku/standards/core/10/waku2.html">10/WAKU2</a></li>
<li><a href="../../waku/standards/core/11/relay.html">11/WAKU2-RELAY</a></li>
<li><a href="../../waku/standards/core/12/filter.html">12/WAKU2-FILTER</a></li>
<li><a href="../../waku/standards/core/14/message.html">14/WAKU2-MESSAGE</a></li>
<li><a href="../../waku/informational/23/topics.html">23/WAKU2-TOPICS</a></li>
<li><a href="../../waku/standards/core/19/lightpush.html">19/WAKU2-LIGHTPUSH</a></li>
<li><a href="https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16">Scalable distributed log reliability</a></li>
<li><a href="./status-mvds.html">STATUS-MVDS-USAGE</a></li>
<li><a href="https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md">WAKU2-STORE</a></li>
</ol>
</main>
<nav class="nav-wrapper" aria-label="Page navigation">
<!-- Mobile navigation buttons -->
<a rel="prev" href="../../status/raw/simple-scaling.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next prefetch" href="../../status/raw/status-mvds.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
<div style="clear: both"></div>
</nav>
</div>
</div>
<nav class="nav-wide-wrapper" aria-label="Page navigation">
<a rel="prev" href="../../status/raw/simple-scaling.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next prefetch" href="../../status/raw/status-mvds.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
</nav>
</div>
<script>
window.playground_copyable = true;
</script>
<script src="../../elasticlunr.min.js"></script>
<script src="../../mark.min.js"></script>
<script src="../../searcher.js"></script>
<script src="../../clipboard.min.js"></script>
<script src="../../highlight.js"></script>
<script src="../../book.js"></script>
<!-- Custom JS scripts -->
<script src="../../scripts/rfc-index.js"></script>
</div>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink