**TL;DR:** What if you could update your post signature (footer ) *once* and have it automatically reflected across *all* your old posts — without any centralized service, without re-editing, and using nothing but native HIVE infrastructure? Here's a concrete proposal to make that happen. --- ![image.png](https://files.peakd.com/file/peakd-hive/louis88/23tkmzJn2rA4cnavekwP1GiqPavnpv1QChfWQ8vPde98f55nR8HtZqbQ9dsdvZXwzXyyf.png) ## The Problem Anyone who has been blogging on HIVE for a while knows this situation: you have a signature at the bottom of your posts — maybe a logo, some links to your socials, a tagline. Looks great. Now six months later, you've rebranded. Your Twitter handle changed. You started a new project. You want to update the signature. The result? Either you leave hundreds of old posts with an outdated signature, or you start a tedious editing marathon. Neither is great. The root cause is simple: **we're storing the signature content directly inside the post body.** That means it's immutable the moment the post is broadcast. The signature is a *copy*, not a *reference*. The fix is equally simple in principle — but requires a small ecosystem shift to pull off properly. --- ## The Core Idea: Reference, Don't Copy Instead of embedding the signature content directly into each post, we embed only a **lightweight marker** — a tiny placeholder that gets resolved to the *current* signature at render time by the frontend. ``` Old approach (bad): New approach (good): ┌──────────────────────┐ ┌──────────────────────┐ │ Post Body │ │ Post Body │ │ [content...] │ │ [content...] │ │ │ │ │ │ === SIGNATURE === │ │ [//]: # (hive-sig:v1:alice)│ Logo | Links | Text │ │ │◄── just a marker └──────────────────────┘ └──────────┬───────────┘ ▲ hardcoded, │ frontend resolves at render time immutable ▼ ┌──────────────────────────┐ │ account.posting_ │ │ json_metadata │◄── change once, │ .hive_signature │ update everywhere └──────────────────────────┘ ``` The signature itself lives **on-chain in your account's `posting_json_metadata`**. Change it once → every old post that carries your marker immediately shows the updated signature on any supporting frontend. ![image.png](https://files.peakd.com/file/peakd-hive/louis88/23t7BQQX3VndNbSo7x32gbN7hKHgKARGFu5BZdhPuJA153RzgV321Umu57q8PFhZaMRWH.png) --- ## Step 1 — Store Your Signature in `posting_json_metadata` HIVE accounts already have a native, writable metadata field: `posting_json_metadata`. It's updated via the `account_update2` operation and costs virtually zero RC. We'd simply define a reserved key inside it — `hive_signature` — with a standardized schema: ```json { "profile": { "name": "Alice", "...": "..." }, "hive_signature": { "version": 1, "enabled": true, "updated": "2024-11-01T12:00:00Z", "content": { "format": "markdown", "body": "---\n![Logo](https://images.hive.blog/0x0/...)\n**[@alice](/@alice)** · [Twitter](https://twitter.com/alice) · [About](/about)\n*Posted with ❤️ on HIVE*\n---" } } } ``` Updating it is a standard broadcast with your posting key: ```javascript import { Client, PrivateKey } from "@hiveio/dhive"; const client = new Client(["https://api.hive.blog"]); const updatedMeta = { profile: { /* existing profile data */ }, hive_signature: { version: 1, enabled: true, updated: new Date().toISOString(), content: { format: "markdown", body: "---\n![Logo](https://ipfs.io/ipfs/QmABC...)\n**My Blog** | [Twitter](...) | [Newsletter](...)\n---" } } }; await client.broadcast.updateAccount({ account: "alice", posting_json_metadata: JSON.stringify(updatedMeta), extensions: [] }, PrivateKey.fromString("5K...")); ``` No tokens spent. No smart contract. No database. Pure HIVE. #### For Example - this is my current Footer / Signature, i'll embed all the time ``` ---

[![image.png](https://files.peakd.com/file/peakd-hive/louis88/23v4Zbq5TQyn3aFGQ7YcUyQJQCHhh556WQfTgmeR6EtVe1RWUURNc89oCX25ZFnUHAXww.png)](https://vote.hive.uno/@louis.witness) ##### Vote for my Hive Witness U can vote for my Witness using Hive Keychain here: https://vote.hive.uno/@louis.witness

[![image.png](https://files.peakd.com/file/peakd-hive/louis88/24241zs2F4mEKWwVa9y2CkqHjUcR7Rh2EyRQEXZA5vfHdjEMnq8Ej8R4cWxT1jgAtXQHP.png)](https://primersion.com/he-witnesses) ##### Vote for my Hive Engine Witness Vote for my Witness on Hive-Engine using Primersion Tool: https://primersion.com/he-witnesses ^{Enter your Username and search for louis.witness}

``` ---

--- ## Step 2 — Embed a Marker in Your Posts (Not the Signature Itself) When writing a post, you place a single standardized comment at the end of your body. It's invisible when rendered by a supporting frontend, and harmless when not: ```markdown This is my amazing post about HIVE development... Lorem ipsum, great content, much value. much wow. [//]: # (hive-sig:v1:alice) ``` This Markdown comment syntax (`[//]: # (...)`) is already widely used as an "invisible comment" in Markdown. It renders as nothing in standard Markdown parsers. The post content on-chain never changes — only the resolution of the marker changes, because it's looked up live. --- ## Step 3 — Frontend Resolution Logic This is the only part that requires frontend changes. The logic is intentionally simple: ```javascript async function renderPostWithDynamicSignature(postBody, client) { const SIG_MARKER = /\[\/\/\]: # \(hive-sig:v1:([\w.\-]+)\)/; const match = postBody.match(SIG_MARKER); if (!match) return postBody; // no marker → render as-is const sigAuthor = match[1]; // e.g. "alice" // Fetch live from chain — this is already cached by most frontends const [account] = await client.database.getAccounts([sigAuthor]); let sigContent = ""; try { const meta = JSON.parse(account.posting_json_metadata || "{}"); const sig = meta?.hive_signature; if (sig?.enabled && sig?.content?.body) { sigContent = sig.content.body; } } catch { // graceful fallback: render nothing } return postBody.replace(SIG_MARKER, sigContent); } ``` Every time a post is opened, the current signature is fetched from the author's account metadata and injected before rendering. The account data is typically already fetched for displaying the author profile anyway, so in most frontend implementations this adds **zero additional API calls**. > Frontends can also implement this as a feature in their frontend without the markdown marker. whatever the better solutions should be. --- ## Images in Signatures — Decentralization Options Since the signature body is Markdown, images are just URLs. Here's a comparison of hosting strategies, from most centralized to most decentralized: | Method | Pros | Cons | |---|---|---| | `images.hive.blog` | Official, CDN-backed, fast | Centralized service | | IPFS (e.g. `ipfs.io/ipfs/Qm...`) | Decentralized, content-addressed | Requires pinning | | Base64 inline in JSON | 100% on-chain | Large, RC-intensive | For most users, `images.hive.blog` is perfectly fine in practice. --- ## Why This Is Better Than a Third-Party Service You might say: *"Can't I just host a signature snippet on my own server and embed an iframe or image tag?"* Technically yes and no — but that breaks several important things: - **Availability:** Your server goes down, your signature breaks on every post ever written. - **Decentralization:** You're now a centralized dependency for your own content. - **Trust:** Other users can't verify what you serve from your domain won't change to something malicious. - **Archival:** Long-term post archives (e.g. HiveArchive) would have a broken dependency forever. - Frontends won't allow you to implement an iframe from an external not whitelisted source. The `posting_json_metadata` approach avoids all of this. The data lives on the HIVE blockchain itself, is accessible from any node, is verifiable, and follows the same replication guarantees as every other piece of HIVE content. --- ## Proposed Specification (Draft HIP) To standardize this across frontends, a **HIVE Improvement Proposal** seems like the right path. Here's a rough draft of what that might look like: ``` Title: Dynamic Post Signatures via posting_json_metadata Type: Informational / Frontend Standard Status: Draft (RFC) Summary: Defines a standard for embedding dynamic, author-controlled signature blocks in HIVE posts using a Markdown marker resolved at render time from the author's posting_json_metadata. Marker syntax: [//]: # (hive-sig:v1:{author_account}) Metadata key: posting_json_metadata.hive_signature Required fields: version (integer, currently 1) enabled (boolean) content (object) format ("markdown") body (string, max 2000 chars) Optional fields: updated (ISO8601 timestamp) alt_text (string, for accessibility) Security: - Frontends MUST sanitize the body (no JS, no iframes, no tracking pixels) - Frontends MUST treat this as untrusted Markdown input - Max body length SHOULD be enforced at render time (suggested: 2000 chars) Backward compatibility: - Frontends that don't support this spec render the marker as an invisible Markdown comment — no visible breakage - Posts without a marker are unaffected ``` --- ## What Needs to Happen Next For this to become a real, usable feature for everyday HIVE users, we need a few things: 1. **Feedback on the spec** — Is `posting_json_metadata` the right place? Should there be a size limit? Any edge cases I'm missing? 2. **Frontend adoption** — The three main frontends that would need to implement this are **PeakD**, **Ecency**, and **Hive.blog**. All three are open source. A well-written PR with a clean implementation would be the fastest path forward. 3. **Tooling** — A simple UI in profile settings ("Edit Signature") that writes the `hive_signature` block would make this accessible to non-technical users. A browser extension could also serve as a bridge in the meantime. 4. **Potential HIP submission** — If there's positive reception here, formalizing this as a HIP would help drive consistent implementation across the ecosystem. --- ## Summary | Property | Value | |---|---| | **On-chain storage** | `account.posting_json_metadata.hive_signature` | | **Post marker** | `[//]: # (hive-sig:v1:{author})` | | **Update mechanism** | `account_update2` broadcast | | **Cost** | ~0 RC | | **Third-party dependency** | None | | **Backward compatible** | ✅ Yes | | **Requires consensus/HF** | ❌ No — frontend-only change | This is a **zero-cost, fully on-chain, backwards-compatible** improvement that could realistically ship in any frontend within a few hours of development. The hard part isn't the code — it's alignment. --- I'm posting this here to start the conversation and collect feedback before drafting a proper HIP. If you see technical issues with the approach, have a better alternative, or are a frontend dev who'd be interested in implementing this — please drop a comment below. Let's build it. --- [//]: # (hive-sig:v1:louis88)

A third party post