112 lines
5.2 KiB
HTML
112 lines
5.2 KiB
HTML
|
<!doctype html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<meta charset="utf-8">
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
|
|
<title>App store — Silent Mode</title>
|
||
|
|
<meta name="description" content="A decentralized app store where entries live on the Bitcoin Cash blockchain and reviews are signed endorsements you filter by who you trust. No gatekeeper approves what ships.">
|
||
|
|
<link rel="stylesheet" href="../shared.css">
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<nav class="topnav">
|
||
|
|
<a class="brand" href="../">⛓️ Silent <span class="g">Mode</span></a>
|
||
|
|
<a href="../nav/">Tools</a>
|
||
|
|
<a href="../apps/">Apps</a>
|
||
|
|
<a href="../register.html">Names</a>
|
||
|
|
<a href="./" class="here">Store</a>
|
||
|
|
<a href="../hermes/">Messenger</a>
|
||
|
|
</nav>
|
||
|
|
|
||
|
|
<header class="hero">
|
||
|
|
<div class="mark">🏛️</div>
|
||
|
|
<h1>App <span class="g">store</span>
|
||
|
|
<span class="pill p-designed" style="vertical-align:middle;font-size:12px;margin-left:.6rem">designed · not yet built</span>
|
||
|
|
</h1>
|
||
|
|
<p class="tag">The <i>listings</i> live on the Bitcoin Cash blockchain. The
|
||
|
|
<i>reviews</i> are signed endorsements you filter by who you trust. Nobody approves
|
||
|
|
what ships — but you decide whose word to believe.</p>
|
||
|
|
</header>
|
||
|
|
|
||
|
|
<div class="wrap narrow">
|
||
|
|
|
||
|
|
<section class="plain">
|
||
|
|
<h2>The problem this fixes</h2>
|
||
|
|
<p class="lede">Every existing app store is one company deciding what runs on your
|
||
|
|
device. That company can be pressured — by governments, by competitors, by its own
|
||
|
|
politics — and every developer above them stands or falls on their whim. Sideloading
|
||
|
|
exists as an escape hatch but with none of the discovery, updates, or verification
|
||
|
|
that make a store useful.</p>
|
||
|
|
<p class="lede">A store without a gatekeeper needs two things it usually can't have at
|
||
|
|
once: <b>a canonical listing</b> nobody can rewrite, and <b>a review system</b> that
|
||
|
|
isn't captured by whoever votes hardest.</p>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<h2>How the design solves both</h2>
|
||
|
|
<ol class="steps">
|
||
|
|
<li><b>Listings are on-chain records.</b>
|
||
|
|
<span>Same shape as BNS name registrations, under a new prefix
|
||
|
|
(<code class="inline">APS1</code>). One record per app: name, description, icon,
|
||
|
|
version, APK / installer SHA-256, and the signing-cert fingerprint the client
|
||
|
|
must match on install. Payload is a hash — the full manifest lives on Sia.</span></li>
|
||
|
|
<li><b>Anyone can list. That's the point.</b>
|
||
|
|
<span>Publishing a listing costs a small on-chain fee and needs no permission.
|
||
|
|
Removing something you don't own is impossible. Store operators — if they exist
|
||
|
|
— curate what they <i>surface</i>, they don't gatekeep what <i>exists</i>.</span></li>
|
||
|
|
<li><b>Reviews are signed endorsements you filter.</b>
|
||
|
|
<span>An endorsement is a signed on-chain statement: "I, <code class="inline">alice.bch</code>,
|
||
|
|
vouch for app X." Your client filters endorsements by trust lists you subscribe
|
||
|
|
to — a security researcher's list, a friend's, your own. A one-star review from
|
||
|
|
a bot you don't follow simply doesn't render. Token-curated registries and
|
||
|
|
formal reputation come later.</span></li>
|
||
|
|
<li><b>Install verifies against the chain.</b>
|
||
|
|
<span>The Ariadne client pulls the APK from wherever the listing says (Sia,
|
||
|
|
server, mirror), checks the SHA-256 against the on-chain record, checks the
|
||
|
|
signing cert against the fingerprint in the record, and only then installs.
|
||
|
|
Same principle as verifying a website: the chain is the truth, not the mirror.</span></li>
|
||
|
|
</ol>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<h2>Where it fits</h2>
|
||
|
|
<div class="grid">
|
||
|
|
<div class="card">
|
||
|
|
<h3>The frontend <span class="src s-sia">.bch site</span></h3>
|
||
|
|
<p>Browse, search, and read the listing pages in any browser via the
|
||
|
|
<a href="../nav/#relay">relay</a>, or natively in <a href="../nav/#theseus">Theseus</a>
|
||
|
|
and <a href="../nav/#android">Ariadne</a>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="card">
|
||
|
|
<h3>The listings <span class="src s-chain">on chain</span></h3>
|
||
|
|
<p>Records under the <code class="inline">APS1</code> prefix, indexed by the same
|
||
|
|
Argus engine that already reads BNS. Adding the record type is a small change,
|
||
|
|
not a new blockchain.</p>
|
||
|
|
</div>
|
||
|
|
<div class="card">
|
||
|
|
<h3>The verified install <span class="src s-chain">via Ariadne</span></h3>
|
||
|
|
<p>Mobile-track slice: an "install with on-chain hash + cert verification" flow
|
||
|
|
inside the Ariadne Android app. That's the reason the store frontend and the
|
||
|
|
resolver ship as one story.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<div class="note warn"><b>Status: designed, not built.</b> The proposal lives in
|
||
|
|
<code class="inline">_coordination/sessions/mobile-resolver.md</code>. A protocol
|
||
|
|
addition (<code class="inline">APS1</code> record type) and a frontend track are the
|
||
|
|
two open pieces. The trust-list review system starts permissionless; formal token-
|
||
|
|
curated registries are a Phase 2 conversation, not a launch requirement.</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<footer>
|
||
|
|
<div>Silent Mode — a Deviant project.</div>
|
||
|
|
<div class="fine">Not yet built. The listing model is decided; the review model starts
|
||
|
|
simple (client-side trust lists) and formalizes only if the simple version proves
|
||
|
|
insufficient in practice.</div>
|
||
|
|
</footer>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|