DOI: https://doi.org/10.5281/zenodo.21947277
Canonical: https://thonly.org/research/b-links-signed-provenance · Licence: CC0 1.0
Working draft. This specification describes a primitive in active design for HeartBank® Storage (B-Storage℠) at
heartbank.us. It is published defensively to establish prior art: the architectural patterns are dedicated to the commons, and the author's non-assertion below is what keeps them free of patent — CC0 itself waives no patent right. Several design questions (notably the precise accounting of the conferred-benefit disclosure) remain open and are stated honestly as such in §13.
This specification is offered to the commons in the spirit of dāna — that the open internet may retain, beneath the rising tide of synthetic media, a layer where a shared thing can carry proof that a human made it, when, and at what cost to whom.
The contribution of this paper is a composition, not any single component. Link previews exist. Content-addressed deduplication exists. Cryptographic timestamping exists. Proof-of-humanity protocols exist. Tip buttons exist. What does not exist, to the author's knowledge as of the date above, is the integration of all five into one shareable unit — a B-Link℠ — such that the act of sharing a file simultaneously (i) saves the recipient storage, (ii) proves a verified human is the origin, (iii) timestamps that origin for provenance, (iv) discloses, as a fact, the benefit conferred on the recipient — one copy rather than n, and (v) offers the recipient a frictionless, optional way to thank the sharer. The integrated unit is the invention; this document places it in the public domain.
This is a defensive publication. The author and HeartBank® will not seek patent on this specification or any portion of it, in any jurisdiction, at any time; this publication is prior art from its date; CC0 1.0 governs the text and the patterns. The purpose is the inverse of a patent: to ensure that these patterns remain freely implementable by anyone, and that no later filer may claim them as novel. Where individual components have existing prior art, that prior art is cited generously in §12; the author claims novelty only for the specific composition and for the named sub-mechanisms identified in §15.
Trademarks (HeartBank®, the B-prefix family, B-Storage℠, B-Link℠, B-PoH℠) are separate from the architectural patterns and are reserved; the patterns may be implemented under any other name without restriction.
Consumer media sharing today imposes a hidden, compounding storage tax. When a user shares a photo or video to a group of n recipients on a copy-based messaging platform whose defaults save received media into the library and the cloud backup, the asset is duplicated across every recipient's device and personal cloud — the sender's local copy, plus one resident copy per recipient per app surface. Families routinely carry the same memories n times over, and the platform surfaces upgrade prompts that turn the duplication into a purchase decision. This is an invisible cost borne by recipients and an invisible kindness when a sharer chooses to avoid it.
This paper specifies the B-Link℠: a rich link-preview primitive that replaces copy-based sharing with reference-based sharing while carrying four additional, normally-absent payloads. A single cloud-canonical copy of an asset lives in B-Storage℠; what travels through messaging and social surfaces is a lightweight, standards-compliant link preview (Open Graph / oEmbed) that renders inline. Bound to that preview are: a verified-human signature (Proof of Humanity ℠, "B-PoH℠"), establishing that a real, unique human is the origin; a cryptographic timestamp, establishing when — together yielding a portable share-registration record — a verified human registered this hash at this time — useful for distinguishing human-shared from bot-emitted media; a conferred-benefit disclosure stated as a fact of the share (e.g., "Thon shared 33 MB without making you a copy"), with the counterfactual saving defined only on inspection; and an optional, recipient-initiated gratitude affordance ("tap to thank") routing a voluntary thank — and, if the recipient chooses, a tip — back to the sharer.
The design's central thesis, developed in the companion position paper The Share Is the Wedge, is that sharing is high-frequency and thanking is low-frequency, and that decoupling the two — making the share the ambient carrier and the thank the sparing, recipient-initiated conversion — is what allows a gratitude economy to acquire a viral distribution surface without debasing the gratitude. This paper specifies the carrier. We also specify a permanence floor ensuring received content is never hostage to the sharer's ongoing subscription, and a threat model addressing sybil attacks, false benefit claims, and thank-bait spam. We state open problems honestly, chief among them the precise, defensible accounting of the conferred-benefit figure.
Consider a family group of four. One member shares a 33 MB video. On a copy-based messaging platform whose defaults save received media into the library and the cloud backup, the asset is transmitted and stored as a distinct resident copy for each participant, on each surface that retains media. The sender keeps the original in their photo library; each of the three recipients receives a full copy that lands both in the messaging app's local store and, through automatic media-saving or cloud photo sync, in their personal cloud backup.
COPY-BASED SHARING (status quo)
one 33 MB asset, family of 4
Sender ──┬── local library ............ 33 MB
├── msg app cache ............. 33 MB
send → ├── Recipient A device+cloud .. 33 MB ×2 surfaces
├── Recipient B device+cloud .. 33 MB ×2 surfaces
└── Recipient C device+cloud .. 33 MB ×2 surfaces
───────
resident copies of the SAME memory: up to 8 (7 beyond the original)The asset that one person created is now resident up to eight times — seven copies beyond the original — for a single share, and the multiplication recurs for every share by every member. The felt consequence is chronic storage pressure: devices and personal clouds fill, and the platform surfaces upgrade prompts ("you're out of storage") that convert the duplication into recurring revenue. The user experiences this as an ambient tax with no identifiable beneficiary and no party to thank for relief. The scope is the messaging default: shared-album products (Google Photos, iCloud Shared Albums) and cloud links (Dropbox) already avoid most of this for the workflows that use them, and what they lack is the rest of the composition, not the reference.
Two observations motivate everything that follows. First, the tax is structural, not behavioral — it is a property of copy-based sharing, not of any user's carelessness. Second, the kindness of not imposing it is invisible: a person who shares in a way that saves recipients storage confers a real benefit that no one perceives, because saved storage is the absence of a cost. Making that invisible kindness legible is a design opportunity, and a recurring theme of the HeartBank corpus (see emotional infrastructure for invisible kindness).
B-Storage℠ (HeartBank® Storage, sited at heartbank.us, read "HeartBank, Us" — sharing among us) replaces copy-based sharing with reference-based sharing. The asset is uploaded once to a cloud-canonical location. What the sharer distributes is not the bytes but a B-Link: a URL whose unfurled preview renders inline on the destination surface.
REFERENCE-BASED SHARING (B-Storage)
one 33 MB asset, family of 4
Sharer ── uploads once → B-Storage canonical copy .... 33 MB (1×)
│
share B-Link → ┌─────────┴──────────┐
│ lightweight preview │ ~tens–hundreds of KB
│ renders inline on │ per recipient surface
│ each recipient's app│
└─────────┬───────────┘
│
full asset on-demand (streamed, ephemeral) if tapped
───────
resident full copies across recipients: 0 (preview only)The recipient sees the content inline via a preview image and can stream the full asset on demand. If the recipient never needs a permanent personal copy, no full duplicate is ever resident on their device or in their cloud. This is the same architecture that makes a streamed video link cheaper for a recipient than an emailed video file; B-Storage applies it to the everyday family-sharing case and binds the additional payloads of §3–§6 to the preview.
The exact storage saved is the difference between a full resident copy and a cached preview thumbnail, realized only when recipient consumption stays ephemeral (streamed, not re-saved). This boundary condition is important and is treated honestly in §5 and §13; it is the single most attackable claim in the design and we decline to overstate it.
A B-Link is a standards-compliant shareable URL whose preview metadata is extended with four bound payloads. It is designed to degrade gracefully: on a surface that understands only Open Graph, it renders as an ordinary rich preview; the additional payloads are namespaced properties under one prefix, with a JSON endpoint for surfaces that ask, and are progressively revealed on surfaces (the B-Storage web view, the HeartBank app, or a future verifying client) that understand them.
┌───────────────────────── B-LINK ─────────────────────────┐
│ https://heartbank.us/b/<content-id> │
│ │
│ (1) PREVIEW Open Graph / oEmbed image + title │
│ └─ renders inline on iMessage, WhatsApp, Slack, … │
│ │
│ (2) SIGNATURE B-PoH℠ verified-human attestation │
│ └─ "a unique real human is the origin" │
│ │
│ (3) TIMESTAMP RFC-3161 / OpenTimestamps anchor │
│ └─ "...and this is when it was registered" │
│ │
│ (4) BENEFIT DISCLOSURE fact-form conferred benefit │
│ └─ "Thon shared 33 MB without making you a copy" │
│ │
│ (5) GRATITUDE AFFORDANCE optional, recipient-initiated │
│ └─ "tap to thank" → thank (+ optional tip) │
└────────────────────────────────────────────────────────────┘| Payload | Carries | Standards basis | Visible by default? |
|---|---|---|---|
| Preview | image, title, description | Open Graph, oEmbed, Twitter Cards | Yes (all surfaces) |
| Signature | verified-human attestation | Proof of Humanity ℠ (B-PoH℠) | On verifying surfaces |
| Timestamp | registration time anchor | RFC 3161, OpenTimestamps | On verifying surfaces |
| Benefit disclosure | the fact of the share (one copy, not n); the counterfactual saving on tap | this specification | In preview description (text) |
| Gratitude affordance | thank / optional tip action | this specification | On HeartBank surfaces |
The description string in the Open Graph preview is the one place where payloads (4) and a call to (5) can travel as plain text through any surface that renders a preview, e.g.:
Thon shared 33 MB without making you a copy. Tap to thank Thon.
This is what allows a B-Link to carry its gratitude semantics into closed messaging surfaces that will never integrate the protocol — the preview text is the lowest common denominator and the universal carrier (§8, and the companion Share Is the Wedge).
Each B-Link binds a B-PoH℠ signature: an attestation that the origin is a verified, unique human, produced through the optional, layered Proof of Humanity ℠ stack specified in the companion paper B-PoH as the humanity layer for the AI-native internet and verified-human anonymous local giving. The signature answers who (a real human, uniquely) without necessarily disclosing which named human to every surface — the binding can be to a stable pseudonymous human-key, with the display name shown only where the sharer has chosen to be named.
A cryptographic timestamp anchors when the share was registered — the token's generation time, not when the asset was made. Implementations may use an RFC 3161 timestamping authority, OpenTimestamps (Bitcoin-anchored), or an L2 commitment; the specification is agnostic to the anchor.
Together, signature + timestamp yield a portable share-registration record:
PROVENANCE TRIPLE bound to content-id <cid>:
who = verified-human key (B-PoH) → "a real, unique human"
when = timestamp anchor → "registered 2026-06-08T…Z"
what = content hash of the canonical asset → tamper-evident identityTwo uses follow. Registration: a creator of original digital art (including AI-assisted art the human directed and curated) obtains a timestamped, human-signed record at the moment of sharing — useful as evidence that a verified human registered the work at that time, not of authorship or of first publication. Human-vs-synthetic distinction: in an internet where synthetic media is cheap and unattributed, a B-Link's verified-human signature lets a recipient (or a downstream platform) distinguish a human chose to share this from a bot emitted this. This is the consumer-facing complement to provenance standards aimed at the capture device (§12).
The signature attests human origin of the share, not the truth, originality, or non-infringement of the content. This limitation is stated plainly in §13: a verified human can share a lie or someone else's work; B-PoH raises the cost of sybil/bot abuse and gives provenance, but it is not a content-authenticity oracle.
The disclosure states the benefit the share conferred on the recipient as a fact of the share, in the preview text: "Thon shared 33 MB without making you a copy." The ambient carrier states the fact — one canonical copy, no duplicate made for you — which is true on every surface before any consumption mode is known; the saving is defined only on tap ("a full resident duplicate would have cost you up to 33 MB; this preview costs N KB") and never in the description. Its purpose is to make an invisible kindness legible and thereby to manufacture an occasion for gratitude where none previously existed (§6).
Honesty about the figure is a first-class design constraint, because it is the design's most attackable claim. The saving is real only as the difference between (a) the full resident copy the recipient would otherwise have stored and (b) the lightweight preview the recipient does store — and only when consumption remains ephemeral. If the recipient taps through and permanently re-saves the full asset, the net saving for that recipient approaches zero.
per-recipient saving = S_full − S_preview (if consumed ephemerally)
per-recipient saving ≈ 0 (if full asset re-saved)
honest display rule:
• the ambient description states the FACT (one copy, not n) — never a saving
• the saving is defined only on tap, as a counterfactual bound ("one cloud copy + preview +
on-demand stream, vs. a full resident duplicate")
• never aggregate into an unverifiable lifetime "you saved X GB" vanity metricThe specification therefore requires that any displayed saving be definable on inspection — a recipient who taps the figure sees exactly what it means — and prohibits inflating it into unsubstantiated aggregate vanity metrics. A defensible, conservative framing ("this share avoided a full duplicate on your device") is preferred over a precise byte count the implementer cannot stand behind per-recipient. The corpus records this as an open problem (§13); we specify the constraint (honesty, definability) even where the exact formula is still being settled.
The conferred-benefit disclosure generalizes beyond storage. Any quantifiable, recipient-side benefit conferred by a share — bandwidth saved, time saved, a curated/denoised version delivered — may be disclosed by the same mechanism, subject to the same honesty constraint.
Bound to the preview is an optional, recipient-initiated gratitude action: tap to thank. A tap routes a thank — and, only if the recipient chooses, a monetary tip — to the sharer, closing the acknowledgment loop on the invisible kindness now made visible. Where the tip carries value, it funds the sharer's capacity to give again rather than the sharer's bill; the routing rule that enforces this is specified below.
The affordance is governed by a binding design constraint inherited from the broader HeartBank thesis: thanking must remain sparing and sacred; sharing may be frequent. A gratitude call-to-action placed aggressively on every share trains thank-blindness — the same banner-blindness that hollowed out the social "like." The specification therefore requires:
ASYMMETRY-PRESERVING RULES for the gratitude affordance
────────────────────────────────────────────────────────
1. The benefit disclosure is AMBIENT INFORMATION, not a demand.
2. The thank is RECIPIENT-INITIATED — never auto-prompted, never
nagged, never defaulted-on.
3. Sharing is the frequent act; thanking is the sparing conversion.
The UI must not invert this ratio.
4. No coercion: content is never withheld pending a thank (see §7).
5. A tip is strictly optional and secondary to the thank; "Kiitos
always; cash optional."
6. A tip NEVER OFFSETS THE SHARER'S OWN COST — it is routed to
forward-spendable gratitude capacity, never to the sharer's
balance owed. Thanks may fund a livelihood; thanks may never
pay a bill. (Routing rule, below.)The asymmetry is the point. The companion position paper The Share Is the Wedge develops the argument that decoupling distribution frequency (share) from value frequency (thank) is what lets gratitude acquire a high-frequency carrier without debasing it; this paper's contribution is to encode that asymmetry into the primitive so that implementations cannot casually violate it.
The thank routes through HeartBank's existing circulation mechanisms (Personal Account℠ / Re-Tip Jar℠ at Phase 1; Personal Wallet℠ / Re-Tip Fund℠ at Phase 2; see fractal three-level architecture). Tips will be pass-through to the sharer; HeartBank will take no cut of the gratitude (per the non-bank, fee-funds-the-institution posture of the corpus).
A gratitude affordance attached to a subscribed service invites an error that looks harmless and is not. If a tip offsets what the sharer owes the platform, the tip is running backward — from the recipient of a gift to the giver, in settlement — which is the direction that distinguishes market exchange from circulation. Three distinct failures follow from that single inversion:
WHY BACKWARD-ROUTED TIPS FAIL
─────────────────────────────────────────────────────────────
1. REBATE SHAPE a tip that pays the sharer's bill nets
against a payment; the "gift" becomes a
discount, and sharing becomes an investment
with a return.
2. EXTRACTION PATH a universally shareable link + a withdrawable
tip = a direct financial motive to spam.
3. SOFT COERCION "thank me so I can keep paying" is the
milder form of "thank me or this disappears"
(§7) — the sharer acquires a personal stake
in being thanked.The rule that removes all three: a tip received for a cost-offset conferred benefit — storage or bandwidth the sharer was already paying for — is credited as forward-spendable gratitude capacity — a Re-Tip Fund℠ balance, disbursable only as a gift onward and never withdrawable as personal funds or applied against the recipient's own subscription. What the recipient receives is the capacity to give again, so the value continues to move forward through them rather than terminating in settlement.
The boundary that keeps the rule honest. It is scoped to the flow, not to the person or the product, and it must not be generalized into "gratitude may never be income." Creative and care labor supported by patronage is a livelihood, and the same platform may legitimately carry both flows: route to forward-spendable capacity when the thanks would offset a cost the recipient owes; route directly when it supports labor. Default is direct; divert only on cost-offset. Applied here: thanks for sharing a file you were already storing divert; patronage of original work does not. The test is mechanical: the provenance record marks the sharer as creator or as sharer; a thank on a share the sharer did not create routes to the Fund; a thank on the sharer's own work routes direct. Curation (§8) is labor and routes direct.
A structural anti-abuse dividend (see §11). Making the received value non-withdrawable removes the economic motive for thank-bait spam entirely: a spammer may farm thanks indefinitely and extract nothing. This converts a detection arms race — rate limits, quality classifiers — into a defense-in-depth layer behind an incentive that no longer exists.
A naïve reference-based design makes received content hostage to the sharer's ongoing subscription: if the sharer stops paying, the canonical copy and its B-Link die, and the recipient's received memory evaporates. For a gratitude-and-memory institution this is uniquely corrosive, and it would turn the gratitude affordance into coercion — "thank me or this disappears." That is the opposite of a gift.
The specification therefore mandates a permanence floor:
PERMANENCE FLOOR
────────────────
• Anything SHARED-AND-RECEIVED is durable even if the CREATOR lapses.
• A received gift within the format's LENGTH CAP is kept free, forever —
the cap is the product's shape, not a meter. Beyond the cap the sharer
pays a ONE-TIME ENDOWMENT at creation; nothing is rented.
• RECEIVED = at least one recipient's received-record exists; that record
is what pins the object. Nothing is held hostage to a subscription;
subscription gates CREATION/CAPACITY, never RECEIPT.The principle: subscription gates creation and capacity to give; it never gates receipt of a gift already given. This severs the coercion vector while preserving a legitimate revenue model on the creation side.
The primitive generalizes from media to two further shareable units:
The significance is the reach. Because a B-Link rides the universal Open Graph / link-preview rails, it renders wherever Open Graph is unfurled — iMessage, WhatsApp, Slack, Discord, email, and social feeds — with no platform integration required, and surfaces that strip previews show a plain link — the same vector by which Spotify, YouTube, and TikTok links propagate. Every shared B-Link is thus a verified-human, gratitude-bearing surface placed inside a closed platform that will never adopt the protocol. This makes the B-Link a candidate consumer wedge for the Proof-of-Humanity layer of the AI-native internet: provenance and humanity-attestation reach end users not through a new browser or platform they must adopt, but through links they already share. (Strategic development: companion paper The Share Is the Wedge and B-PoH humanity layer.)
CREATE/UPLOAD SHARE RECEIVE
─────────── ───── ───────
human (B-PoH verified) sharer posts B-Link recipient surface unfurls
uploads/creates asset → to any surface → preview inline:
│ │ ┌──────────────────┐
one canonical copy B-Link carries: │ [preview image] │
in B-Storage • OG preview │ "Thon shared 33 │
│ • B-PoH signature │ MB, no copy. │
provenance triple • timestamp │ Tap to thank." │
(who/when/what) • benefit disclosure └────────┬─────────┘
registered + timestamped • gratitude affordance │
recipient may:
• stream on demand
• verify provenance
• (optionally, sparingly)
tap to thank → thank
(+ optional tip) to sharer
PERMANENCE FLOOR: received content stays alive regardless of sharer's
subscription state (§7).| Threat | Description | Mitigation |
|---|---|---|
| Sybil / bot flooding | Bots emit B-Links at scale to farm tips or pollute feeds | B-PoH gating: only verified unique humans can originate signed B-Links; rate-limits per human-key |
| Thank-bait spam | Humans spam low-value B-Links to solicit thanks/tips | Primary (structural): the routing rule (§6.1) — received value is forward-spendable only and never withdrawable, so the economic motive to farm thanks does not exist. Defense-in-depth: recipient-initiated thanks only (no auto-prompt); Miss Aquarius℠-side quality/rate signals; recipient filters (no-abuse, degrees-of-separation) per the PoH recipient-filter stack |
| False benefit claims | Inflated "saved you X" figures | Definability-on-inspection requirement (§5); conservative default framing; prohibition on unverifiable aggregate vanity metrics |
| Provenance forgery | Claiming human origin for synthetic/stolen content | Signature attests human origin of the share, not content truth (§4, §13); timestamp + content-hash make tampering evident; does not prevent a human sharing others' work |
| Coercion via link-death | "Thank me or this disappears" | Permanence floor (§7): receipt is never gated on payment |
| Preview-cache leakage | Sensitive preview cached on third-party surfaces | Sharer controls preview generation; sensitive shares can suppress rich preview / use access-controlled previews |
The residual risk the design explicitly does not solve is content authenticity: B-PoH establishes human, unique, when — not true, original, lawful. This is a deliberate scoping decision, not an oversight (§13).
The author cites prior art generously and claims novelty only for the composition and the named sub-mechanisms (§15).
The novel composition: a single shareable unit that is, at once, a storage-deduplicating reference, a verified-human-signed and timestamped provenance record, a fact-form conferred-benefit disclosure to the recipient, and a recipient-initiated gratitude affordance — propagating through universal link-preview rails. No cited art combines these; the combination is the contribution, and it is hereby placed in the public domain.
Per the HeartBank standing practice of stating limits plainly:
A note for implementers on framing, included because mis-framing is itself a failure mode. B-Storage should not be positioned as "cloud storage" — that is a commodity (consumer photo clouds, shared albums, file lockers) and a losing competition. The storage saving is the hook; the moat is the bound provenance (verified-human signature + timestamp) and the gratitude rail. The accurate description is: a provenance-and-gratitude-native sharing layer that happens to save you storage. The storage saving gets the user in the door; the verified-human share record and the acknowledgment loop are why the layer is worth adopting.
For the record (all dedicated to the public domain under CC0 1.0):
Working draft, dated 2026-06-08. Subject to refinement before final publication; §13 records the open problems honestly. The architectural patterns are dedicated to the public domain under CC0 1.0 Universal; trademark rights to specific marks are separately reserved by the author and HeartBank®.
Author: Thon Ly · Founder, HeartBank® · Kâmpôt, Cambodia.
Co-drafted in collaboration with Miss Aquarius℠ (the project's named AI substrate; CEO of HeartBank). Substantive authorship and final editorial control remain with the author.
_— End of defensive publication —_
This document's SHA-256 is attested independently of the site and its authors — anchored to the Bitcoin blockchain via OpenTimestamps and signed under RFC 3161 by three timestamp authorities in three jurisdictions, one of them eIDAS-qualified — and each revision carries a Zenodo version; a timestamp proves this exact text existed no later than its date and nothing about authorship, originality, or the validity of any claim.