Open Heart Protocol

Original Article ↗ Hacker News Discussion ↗

Overview

  • Protocol lets sites register emoji “reactions” to URLs and read back aggregated counts.
  • Framed as a decentralized “like/reaction” system, alternative to things like Webmention or embedded counters.

Use Cases & Appeal

  • Seen as a fun, “dumb in a good way” toy that adds lightweight interactivity to static sites.
  • Nostalgic comparisons to 90s “visitor logs” and simple button counters.
  • Some like that it supports arbitrary emoji rather than a single heart and that it’s simple to self‑host.

Abuse, Anonymity, and Legal Liability

  • Strong concern: any anonymous write/anonymous read service tends to be used for illicit activity (identity theft, extortion, CSAM, etc.).
  • Worry about being unable to identify users if law enforcement appears, and the cost of “extended engagements” with authorities.
  • Others argue this is overblown: criminals have many easier options (own servers, compromised WordPress, pastebins, encrypted archives, messaging apps).
  • Debate over whether worrying about edge criminal use discourages small/indie projects unnecessarily.

Technical Concerns & Data Encoding

  • Discussion that even with “one emoji” limits, you can encode arbitrary data:
    • Emoji are multibyte; with Zero Width Joiner (ZWJ) or variation selectors, you can build very long emoji sequences and encode strings.
    • Spec also allows arbitrary trailing data that servers “should” ignore; in theory this could carry large illicit payloads, though if not stored it’s not hosted content.
  • Some think this is a theoretical but low‑value vector; others see it as non‑trivial risk for operators.

Protocol Design & Semantics

  • Questions why this merits the term “protocol” vs. a basic HTTP counter API (PUT /count/increment).
  • Critiques:
    • No quality control or authentication means reaction counts are easily gamed and may be meaningless.
    • JSON “object” response loses ordering semantics; spec treats them as unordered even if some implementations preserve order.
    • HTTP status code choices debated (403/404/405/204 distinctions).
    • Accepting arbitrary emoji is seen as unnecessary attack surface; some suggest restricting to a fixed set or a single heart.

Adoption, Decentralization & Related Ideas

  • Unclear what incentives publishers have to adopt, since reactions mostly benefit the site’s own silo unless tied to identities.
  • Ideas for tying reactions to federated identities (e.g., Bluesky/Mastodon style signed reactions) to create a web‑wide like system.
  • Compared to browser extensions that overlay comments on any page; discussions about moderation, spam, and why such systems struggle.
  • Mixed views on decentralization: protocol is centralized per deployment but self‑hostable; some wish for a broader “open comment protocol” instead.