Thursday, June 4, 2026

Tentausando: A Protocol for User-Owned Ranking on the Open Web

Tentausando — Product Requirements Document

An open protocol for syndication, discovery, and user-owned ranking on the open web.

Document Product Requirements Document (PRD)
Version v0.10 — Draft (structural re-sequence)
Status For internal review / partner circulation
Authors Rhombus Ticks and Redwin Tursor
IT Consulting TC Ricks
Imprint Red Anvil Creative
Date June 4, 2026

Re-sequence Note (v0.10)

This revision does not change the architecture. It changes the order in which the document earns the reader's attention, on four moves:

  1. Lead with the ranking thesis, not the machinery. The feed's ranking is what decides what you see and what you never do — and someone else controls it. "Ranking sovereignty" is a reader reclaiming control of that ordering. This is now §0, before any acronym. The terms ASM, Ed25519, and federatable index — which trigger the "another decentralization protocol" reflex on contact — are deferred until the thesis is already stated.
  2. Promote bridges from a risk-section footnote to the seeding strategy. A high-quality protocol with no network on it is dead on arrival. Opt-in bridges that let people carry their own existing content in are the only credible cold-start lever, so they are stated up front (§2) rather than buried in §9.2.
  3. Demote the addiction dial's public-number theater. The dial is a powerful private instrument and a dangerous public badge — "my addiction level is 2/10" turns a practice into a status display. The published-setting visibility is now opt-in, not mandatory, and the "culturally significant public number" framing is removed.
  4. Add author accountability. A published ranking algorithm shapes the feed of everyone who subscribes to it. Algorithms now carry a legible feed-composition profile (source concentration, diversity, addiction profile) so an author owns the feed they shape — the same legibility principle the rest of the protocol already rests on.

Prior revision history (v0.2–v0.9) is preserved in Appendix C.

0. Thesis — Whoever controls the ranking controls what you see

You are reading inside a feed someone else controls.

Every feed you use decides which content reaches you, in what order, and how often — and that ordering is not neutral. The ranking is the product: it decides what gets your attention and what you never see at all. Every major platform has captured that ranking and tuned it to a single objective — maximize engagement — and then hidden the controls. The grievance people actually have with modern feeds is not that they cannot reach content. It is that an operator they cannot see is ordering what they read, optimized for someone else's revenue, and refusing to say how.

Tentausando's thesis is that ranking sovereignty — owning the ranking itself, over content that cannot be deplatformed — is the real and underexploited opportunity. Not a better black box. The removal of the box, and the return of control to the reader.

Everything downstream — identity, indexing, syndication markup, the algorithm marketplace — is machinery in service of that one idea, introduced only after the idea is established and justified by reference back to it.

A second, structural claim sits underneath the first: because content lives on the author's own pages rather than on a platform, the substrate itself cannot be deplatformed. None of the post-Twitter destinations — Threads, Mastodon, or even Bluesky — can offer that for the place their users actually gather. You can be removed from every one of them. You cannot be removed from your own pages.

1. Problem Statement

The open web has a distribution problem that is coordination-shaped, not technology-shaped. The individual pieces required to fix it largely exist; no one has assembled them into a coherent stack with a reference implementation and a reason for ordinary users to show up.

The concrete failures:

RSS is structurally impoverished. It carries a title, a body, and a date. It has no native concept of identity, curation, comments, content type, or ranking. It died in the mainstream partly because its de facto coordination layer (Google Reader) was discontinued and nothing replaced the index.

ActivityPub absorbed the decentralization energy and overshot. Federation in the Mastodon model requires running or joining a server, accepting an instance's moderation regime, and operating inside a protocol built for microblogging social graphs rather than general content syndication. It is the wrong weight class for "let me publish a page and have it discovered."

Discovery is a coordination problem. Someone has to run the index, and prior efforts collapsed less from cost than from centralization — when the one index everyone depended on went away, nothing replaced it. Avoiding a single load-bearing index, not funding one, is the hard part (see §9.1).

Algorithmic control is talked about but not delivered. Regulatory pressure (e.g. the EU Digital Services Act's transparency provisions) and post-platform-collapse user sentiment have raised the salience of "I want to control my feed." But every product still ships a black box, and the few that expose knobs do so trivially. No one treats the algorithm — the ranking itself — as a first-class, ownable, shareable object.

Comment federation keeps dying. Disqus, Coral, Commento and others each solve a slice and stall on the same chicken-and-egg adoption curve. A clean, XML-native, identity-anchored approach has not been tried at the protocol level.

1.1 The networks people fled to each fail — and a central actor controls what you see

The post-Twitter migration scattered across three "open-ish" destinations. Each has a documented, structural problem, and they share one: a central operator controls reach, moderation, and whether you continue to exist there — which means a central operator controls what you see and can switch it off.

Threads is Meta — the corporate control people left. At launch it collected so much sensitive data — health, finances, location — that it was branded a "privacy nightmare" and held out of the EU over data-protection law. Its fediverse support arrived roughly eighteen months late and is still hobbled — you cannot even search for fediverse users from Threads — while over 800 servers preemptively pledged to defederate from it (the "Fedipact") over Meta's moderation and privacy record. The embrace-extend-extinguish worry is not hypothetical: 404 Media documented Meta blocking links to Pixelfed, and observers note Meta can make ActivityPub deliberately awkward and later withdraw it once it has served its purpose. Add an engagement-shaped feed that deprioritizes news and politics by design, moderation that has wrongly deactivated numerous accounts, and the end of fact-checking, and Threads is a walled garden wearing open-protocol clothes. To its credit it brings capital-grade infrastructure and the lowest barrier to entry of the three by riding existing Instagram graphs — but that reach is Meta's to grant or revoke.

Mastodon is feudal decentralization. It solves "no single corporate owner" by handing your identity and your moderation regime to a volunteer instance admin, and it makes a newcomer choose a server before they understand what a server is. Discovery runs backwards — search is deliberately limited, and the network has repeatedly dogpiled even consent-respecting search tools into shutting down. Instances shut down and take their users' identities with them; admins suspend accounts; defederation severs whole communities overnight. The operator is smaller and kinder than Meta, but there is still an operator who can remove you.

Bluesky markets a decentralization it does not yet deliver. It raised a $100M Series B (Bain Capital Crypto, April 2025), ~$123M total, 43M+ users, with a 2025 founder-to-CIO and commercialization-hire pivot that sharpens rather than softens the VC-capture concern. Its custom feeds and composable moderation are the closest prior art to Tentausando and deserve real credit. But in late 2025 a user banned by the central team could not, in practice, "just move" — the decentralization is by design, centralized in operation, and a single point of political pressure. The operator can still remove you from where everyone gathers.

The common failure mode: a central actor can remove you, and therefore controls what you see. Tentausando's substrate — your own pages — cannot be deplatformed. Appendix A compares all five at a glance, led by a "who can remove you" row.

2. The On-Ramp — bridges as the seeding strategy

A protocol with no network on it is dead on arrival. The hardest problem Tentausando faces is not design; it is the cold start (§9.2). The answer is to build on top of the networks that already exist rather than wait for a new one to form.

A bridge is opt-in and self-service: an individual on Mastodon, Threads (via ActivityPub), or Bluesky (via the AT Protocol) joins Tentausando and maps their own public content into the index — keeping their existing accounts. "No cooperation required" means the platform — Meta, Mastodon gGmbH, Bluesky PBC — need do nothing; the individual consents by joining. This is deliberately not a firehose scrape: indexing non-consenting accounts is the move the fediverse has repeatedly shut down, and it would contradict the protocol's own curator-allow consent principle.

This is the project's cheapest content-seeding lever and its primary adoption strategy, not a courtesy feature. Done right, the bridge converts the open networks from rivals into a distribution on-ramp: people carry their existing audience and back catalogue in without abandoning anything, the index populates from day one, and the first curators have something to curate before the native publishing base exists. The technical bridge specification (what a bridge can and cannot attest, and how it proves account control without overclaiming origin-signing) lives in §5.4; the strategic point is stated here because it carries the launch.

The walled-garden case — closed platforms with no open API and no opt-in path — is out of scope.

3. Product Overview

Tentausando is a lightweight, open syndication and discovery protocol paired with a user-owned ranking system. It occupies the gap between RSS (too primitive — a dumb pipe with no structure, no discovery, no curation) and ActivityPub/Mastodon (overbuilt — heavy server requirements, protocol lock-in, and an instance model most publishers never adopt).

┌─────────────────────────────────────────────────────────────────┐
│                         AUTHOR'S ORIGIN                            │
│   any static or dynamic page + embedded ASM descriptor (XML)       │
│   + reactions.xml at origin; comments live on commenters' pages    │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ crawled / self-registered / bridged
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                          THE INDEX (federatable)                    │
│   stores ASM metadata + pointers only — NOT canonical content       │
│   exposes a public query API                                        │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ queried by
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                     AGGREGATORS (also ASM nodes)                    │
│   editorial / topical / institutional curated feeds + bridges       │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ candidate pool
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                       RANKING ENGINE (open source)                  │
│   Tier 0: declarative signal weights                                │
│   Tier 1: learning-to-rank (Metarank)                               │
│   Tier 2: collaborative filtering (Gorse / LightFM)                 │
│   configured by ↓                                                   │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │  THE ALGO STUDIO (GUI) — addiction dial, topic weights,      │  │
│   │  learning throttle, source trust, "why am I seeing this?"    │  │
│   │  publish · fork · subscribe · feed-composition profile      │  │
│   └─────────────────────────────────────────────────────────────┘  │
└───────────────────────────────┬───────────────────────────────────┘
                                 │ ranked feed
                                 ▼
┌───────────────────────────────────────────────────────────────────┐
│                        THE READER APP                               │
│   identity = Tentausando ID · feed · comments client                │
│   read/click/skip signals fed back to the ranking engine ──────────►│
└───────────────────────────────────────────────────────────────────┘

The system has three pillars:

  1. ASM (Annotated Syndication Markup) — a small XML descriptor any text page can embed, with no CMS, server, or platform dependency. A static HTML file qualifies. Hosts emit it for their users automatically, so nobody hand-writes markup.
  2. The Tentausando ID — a portable, self-generated identity that most people experience as an ordinary, recoverable account with a normal handle, and that anyone can export to full self-custody to become uncancellable.
  3. The Algo Studio — a GUI that lets any user design their own ranking algorithm — including a literal addiction dial — and then publish, fork, and subscribe to algorithms the way people now follow accounts.

Joining is designed to be as easy as signing up for any app — one tap, a good default feed immediately, existing Mastodon/Bluesky/RSS accounts connected in one tap, with no instance to choose, no key to memorize, and no file to edit. The instance-choice maze that stranded Mastodon's newcomers is treated as an anti-pattern, not a rite of passage.

The protocol and reference implementations are open source; there are no ads and no sale of user data, because both would corrupt the legible ranking that is the entire point.

The product name derives from its identity layer. A tentausando is the number 10^1000 — one followed by a thousand zeros — and the name evokes that scale the way Google evokes googol. The identity primitive itself is a 256-bit Ed25519 keypair whose ≈10⁷⁷ key space is already vast enough to be effectively uncollidable; the 10^1000 is the name's poetry, not a literal entropy claim (see §5.2).

4. Goals and Non-Goals

4.1 Goals

  • Make joining as easy as any consumer app for a non-technical person — a hard requirement, not a nicety. No one is ever required to choose a server, edit a file, manage a cryptographic key, or understand the protocol to participate; the technical machinery is the host's job, not the user's.
  • Define an XML descriptor (ASM) that any page can embed with zero server requirement.
  • Define a self-sovereign identity token (Tentausando ID) requiring no signup, email, or central authority.
  • Specify a federatable index/crawler that stores pointers and metadata, never canonical content.
  • Specify an aggregation/curation layer where aggregators are themselves first-class ASM nodes, and opt-in bridges are a leading adoption on-ramp.
  • Specify identity-anchored, decentralized comment federation (signed comment objects on the commenter's own substrate, assembled by reference).
  • Deliver a ranking engine built on open-source components, exposing every ranking decision to inspection.
  • Deliver the Algo Studio: a GUI for designing, publishing, forking, and subscribing to ranking algorithms, each carrying a legible feed-composition profile.
  • Keep the protocol and reference implementations open source under a license to be determined in §11.

4.2 Non-Goals

  • Not a social network with a follower graph as the primary primitive. The primitives are content, identity, and algorithm.
  • Not an ActivityPub or AT Protocol competitor. Tentausando does not replace the open networks; users opt in to bridge their own content from them (§2, §5.4, §9.7), keeping their existing accounts.
  • Not an ad-supported product. Engagement-maximizing monetization is explicitly excluded because it is incompatible with a legible, user-owned ranking system.
  • Not a hosting platform for content. Canonical content always remains on the author's origin.
  • Not a content moderation authority. Moderation is addressed as a federated, curator-level and reader-level concern (see §9.6), not a central function.
  • Not an onboarding that offloads complexity onto the user. The instance-choice maze, hand-editing markup, and "here is your private key, don't lose it" are the explicit anti-patterns; any of them appearing in the default join flow is a defect, not a power feature.

5. Component Specifications

5.1 ASM — Annotated Syndication Markup

Purpose. A small, embeddable descriptor that makes any page discoverable, attributable, and curatable with no server required.

<asm xmlns="https://tentausando.org/ns/asm/1.0">
  <author>
    <handle>areed</handle>
    <identity>tnt:8417…</identity>
  </author>
  <content>
    <title>What the Open Web Lost When Reader Died</title>
    <canonical>https://example.com/posts/open-web-discovery</canonical>
    <type>essay</type>
    <published>2026-05-28T14:00:00Z</published>
    <updated>2026-05-28T14:00:00Z</updated>
    <tags>open web, syndication, discovery</tags>
    <license>cc-by-nc-4.0</license>
  </content>
  <syndication>
    <comments>https://example.com/posts/open-web-discovery/comments.xml</comments>
    <reactions>https://example.com/posts/open-web-discovery/reactions.xml</reactions>
    <curator-allow>*</curator-allow>   <!-- * = open, or whitelist of index/aggregator IDs -->
  </syndication>
  <signature alg="ed25519">…(signature over the descriptor's canonical serialization, keyed to author identity)…</signature>
</asm>

Design principle. The index and aggregators receive metadata and pointers. The canonical body stays on the author's origin. This keeps authors in control of their content, keeps the index cheap to operate, and sidesteps the largest class of copyright and content-liability problems.

Who actually writes ASM — almost never the user. ASM is plumbing, and a non-technical user never sees it. The expected path is that a host emits ASM on the user's behalf — exactly as a blogging platform emits RSS without its writers ever knowing what RSS is. Hand-authoring an ASM file, or dropping one on a static site you run, is the power-user / self-hoster path — fully supported, never required.

Requirements:

  • REQ-ASM-01 — The descriptor MUST be valid against the published ASM XML schema (asm-1.0.xsd).
  • REQ-ASM-02 — author.identity, content.title, content.canonical, and content.type are REQUIRED. All other fields are OPTIONAL.
  • REQ-ASM-03 — The descriptor MUST be embeddable in a fully static page with no server-side processing.
  • REQ-ASM-04 — The descriptor SHOULD carry a signature keyed to the author's Tentausando ID, enabling consumers to verify authorship integrity.
  • REQ-ASM-04b — When a signature is present it MUST be computed over a deterministic serialization of the descriptor (a defined canonical byte form — e.g. canonical JSON/CBOR of the descriptor fields — not a c14n-dependent XML-DSig), and verifiers MUST reject non-canonical Ed25519 signature encodings.
  • REQ-ASM-05 — curator-allow MUST be honored by conforming index/aggregator implementations; absence defaults to open (*).
  • REQ-ASM-06 — A reference validator MUST be published so authors can confirm conformance before deployment.
  • REQ-ASM-07 — ASM MUST be expressible both as an Atom namespace within an existing feed and as a standalone page descriptor; the two forms MUST carry identical semantics.
  • REQ-ASM-08 — A conforming host MUST be able to generate, sign, and serve valid ASM on behalf of its users, so that becoming discoverable requires no markup authoring or file handling by the user.

5.2 Tentausando ID — Self-Sovereign Identity

Purpose. Give every participant — author, commenter, curator — a portable identity that requires no signup, no email, no platform account, and no central issuer, while still being strong enough to authenticate actions.

Mechanism. Under the hood, identity is a 256-bit Ed25519 keypair; the public half can be rendered as a base-10 integer whose key space (≈10⁷⁷) is already far beyond any feasible collision or brute-force attack. But that number is machinery, not the user's face. What a normal user sees and shares is a human handle — you@host for a host-managed account — while the underlying integer stays under the hood. The private half signs comments, proves ownership of a published algorithm, and signs ASM descriptors; on the default host-managed account the host holds it, so the user never handles a key at all. The name Tentausando evokes 10^1000 the way Google evokes googol — branding for vastness, not a literal entropy figure.

The honest tradeoff — and how the default avoids it. Self-held keys mean no one can lock you out — and no one can let you back in. Most people will never want that responsibility, and the protocol does not force it on them. The default experience is an ordinary account: a user signs up with a host, the host custodies their key, and recovery, key rotation, and a legible handle all work the way they do on any app. The key is exportable at any time: a user who wants full portability exports it and self-custodies, at which point the deal flips — they hold the key, they write it down, and the loss is theirs. Crucially, custody is about the key, not the content: a host holding your key cannot take down your origin pages, so the substrate stays uncancellable regardless of where the key lives. Key custody is addressed candidly in §9.4.

Three ways to hold an identity (custody and anchoring are independent axes):

  • Host-managed (default). A host custodies the key. Easy, recoverable, with a human-legible handle. What most people use.
  • Self-custodied. The user exports the key and holds it themselves. Maximum portability and the strongest deplatforming resistance; the user owns the key-loss risk (§9.4).
  • Host-anchored (optional, additive). Independently of who holds the key, a user can publish their public ID at a location on a domain they control (e.g. /.well-known/tentausando), binding the identity to that origin as a reputational anchor and enabling key rotation.

Requirements:

  • REQ-ID-01 — IDs MUST be generated client-side using a CSPRNG (e.g. crypto.getRandomValues, never Math.random), with no registration.
  • REQ-ID-02 — In self-custody, the private key MUST NOT leave the client and signing MUST happen locally. A host-managed identity MAY escrow the key for recovery, but it MUST remain exportable at any time.
  • REQ-ID-03 — The public ID MUST be representable both as a base-10 integer (human-shareable) and in a compact canonical encoding (machine form).
  • REQ-ID-04 — The user MUST be able to export their key and import it into another client or host.
  • REQ-ID-05 — Host-anchoring MUST be optional and additive; an unanchored ID is fully valid.
  • REQ-ID-06 — Host-managed identities MUST provide account recovery and key rotation. A self-custodied identity has no recovery path; the product MUST state this plainly at the moment of export.

5.3 The Index

Purpose. The discovery layer. A queryable store of ASM metadata.

Behavior. The index crawls ASM-bearing domains (discovered via crawl or self-registration), stores the structured metadata and pointers, and exposes a query API such as:

GET /index?author=areed&type=essay&tag=open-web&since=2026-05-01
GET /index?id=tnt:8417…
GET /index?canonical=https://example.com/posts/open-web-discovery

Federation. Anyone can run an index. Conforming indexes can exchange records, and trusted hubs are expected to emerge organically. No single index is privileged by the protocol.

Binding a URL to a key (possession), and resolving conflicting claims. A signature proves who signed, not who controls the URL. The index therefore binds a URL to a key by proof of possession: at crawl time it confirms the ASM is reachably served from (or rel-linked by) the canonical origin, and the first key to validly claim a URL holds it (first-key continuity / trust-on-first-use). A later descriptor for the same URL signed by a different key requires continuity from the incumbent key (a rotation signed by the old key) — which prevents an attacker who seizes a lapsed domain from silently overwriting authorship. Bridged URLs are resolved through the §5.4 authorship-assertion plus account-control proof instead, and remain distinguishable as asserted rather than origin-signed.

The central risk is centralization, not cost (see §9.1). Because the index stores pointers and metadata only, even a multi-million-item index runs on a modest VPS. Federation buys resilience — no single index whose death is fatal — rather than cheaper infrastructure, which the architecture already makes cheap.

Requirements:

  • REQ-IDX-01 — The index MUST store only metadata and pointers, never canonical content bodies.
  • REQ-IDX-02 — The index MUST expose a public, documented query API.
  • REQ-IDX-03 — The index MUST honor curator-allow directives.
  • REQ-IDX-04 — The index MUST be runnable as a self-hostable reference implementation with modest resource requirements.
  • REQ-IDX-05 — Indexes SHOULD support record federation with other conforming indexes.
  • REQ-IDX-06 — Records MUST be keyed on canonical URL with last-write-wins by updated; the signed ASM descriptor — not index state — is authoritative.
  • REQ-IDX-07 — The index MUST bind a canonical URL to a key by proof of possession and MUST apply first-key continuity.
  • REQ-IDX-08 — The index MUST reject descriptors whose updated timestamp exceeds the crawler's clock by more than a bounded skew.
  • REQ-IDX-09 — Published algorithms MUST be storable and queryable as a first-class index record type under an algorithm: namespace, addressable by author ID plus algorithm name and carrying the author's signature.

5.4 Aggregators and Bridges

Purpose. The editorial/curation layer. Aggregators query the index and assemble curated feeds with their own identity and point of view.

Behavior. An aggregator is a named, curated lens over the index — topical, editorial, or institutional. Critically, aggregators are themselves ASM nodes: an aggregator publishes its own ASM feed, so aggregators can be discovered, subscribed to, and aggregated by other aggregators. Curation composes.

Bridges (the on-ramp — strategy in §2). A bridge is an aggregator whose source is another network rather than ASM-bearing pages — opt-in and self-service. A person on Mastodon, Threads, or Bluesky joins Tentausando themselves, after which their own public posts are mapped into ASM descriptors and indexed. This is the Bridgy Fed model, deliberately not a firehose scrape.

Signing bridged content — what a bridge can and cannot attest. A bridge cannot sign content it does not host. So it does not pretend to. Instead the user — or, for a host-managed identity, the user's host on their behalf — issues a signed authorship assertion: "Tentausando ID X claims canonical URL Y, observed at time T," served from the user's anchor, not faked as origin-served. To bind the assertion to the real account, the bridge requires a one-time proof of control of the source account — a rel="me" link or a signed nonce — performed by the app as a one-tap connect and verify (OAuth where available, or auto-posting the verification link). Bridged records are flagged authorship-asserted (content at origin), distinct from self-hosted origin-signed records, and readers and aggregators may weight the two differently.

Requirements:

  • REQ-AGG-01 — An aggregator MUST publish its own conforming ASM feed.
  • REQ-AGG-02 — Aggregators MUST respect author curator-allow directives.
  • REQ-AGG-03 — Aggregator feeds MUST be subscribable by both reader apps and other aggregators.
  • REQ-AGG-04 — An aggregator MUST be operable without author permission for any content marked open, and MUST exclude content that has not whitelisted it where a whitelist is specified.
  • REQ-AGG-05 — A bridge MUST be opt-in: it ingests only the records of individuals who have explicitly joined, operates read-only against the source, honors source-network opt-out signals (e.g. #nobot, no-index flags), and requires no cooperation from the source platform. It MUST NOT scrape non-consenting accounts.
  • REQ-AGG-06 — A bridge MUST NOT produce ASM that falsely attributes origin-signing to bridged content. Bridged items MUST carry a signed authorship assertion, MUST be backed by a one-time proof of control of the source account, and MUST be flagged as authorship-asserted. The proof of control SHOULD be performed by the client or host on the user's behalf, never handed to the user as a manual step.

5.5 Comment Federation

Purpose. Replace the dead/dying central comment silo with identity-anchored, author-hosted comments.

Mechanism. A comment is itself a signed object that lives on the commenter's own substrate and references the canonical URL it responds to. Each comment is signed by its author's Tentausando ID, so authorship is verifiable without a central account system. A target's thread is assembled by reference: the index and readers gather the signed comment-objects that point at a given URL. This accepts higher latency and assembly cost as the price of staying decentralized; it also dissolves the static-site problem — comments are not POSTed to an author who has no write endpoint, but published by commenters and discovered by reference.

<comments for="https://example.com/posts/open-web-discovery"
          xmlns="https://tentausando.org/ns/comments">
  <comment id="c001">
    <author-handle>mreyes</author-handle>
    <author-id>tnt:5521…</author-id>
    <posted>2026-06-01T10:15:00Z</posted>
    <reply-to/>
    <body>This matches what the post-Reader discovery data shows about…</body>
    <signature alg="ed25519">…</signature>
  </comment>
</comments>

The protocol explicitly rejects routing comments through a single hosted comment service: that would re-centralize exactly what the protocol exists to decentralize. A reader app may cache or aggregate threads for speed, but caching is never authoritative.

Requirements:

  • REQ-COM-01 — Each comment MUST be a signed object on the commenter's own substrate, referencing the canonical content URL, with no central comment store.
  • REQ-COM-02 — Each comment MUST be signed by the commenter's Tentausando ID.
  • REQ-COM-03 — The author MUST control which referencing comments (if any) are displayed alongside their content; the author does not host or own the comments themselves.
  • REQ-COM-04 — Comment threading MUST be supported via reply-to.
  • REQ-COM-05 — Conforming implementations MUST NOT depend on a single central comment service; caching for performance is permitted but MUST NOT be authoritative.
  • REQ-COM-06 — Moderation hooks (author-level allow/block by ID, reader-level muting) MUST be specified (see §9.6).

5.6 The Ranking Engine

Purpose. Turn a candidate pool into a ranked feed, with every ranking decision inspectable. This is the ranking layer of §0, made open-source and legible.

The engine is tiered, with the same configuration object describing the user's intent at every tier.

Tier 0 — Declarative signal weights (no ML). The honest baseline. The user sets explicit weights; ranking is a transparent weighted sum. This tier alone is a complete, shippable product and the philosophical heart of the system.

ranking:
  recency_weight:        0.6
  topic_affinity_weight: 0.3
  curator_trust_weight:  0.1
  penalties:
    already_read: -1.0
    author_muted: -999

Tier 1 — Learning-to-rank (Metarank). Metarank ingests engagement signals and reranks in real time, configured through a YAML DSL. Because the configuration is YAML, the user-visible algorithm and the auditable machine configuration are the same artifact.

Tier 2 — Collaborative filtering (Gorse / LightFM). For cross-user discovery. Optional and additive.

The moat is the experience and the network, not the algorithm. Every ranking component is open source.

Retrieval vs. reranking — what the user actually controls. Everything above is reranking. Retrieval — generating the pool — is the expensive half; the reference architecture does not solve global retrieval, and aggregators are the retrieval layer. The user controls both stages: their subscriptions are their retrieval policy and their algorithm is the ranking. The one true bound is source diversity — your algorithm can only rank what your subscriptions admit — which is a defaults problem (ship broad, good default sources), not a structural defect.

Requirements:

  • REQ-RANK-01 — At Tiers 0 and 1, every ranked item MUST explain its position in the terms the user configured.
  • REQ-RANK-01b — At Tier 2, the per-item explanation MAY be an honest taste-overlap statement; Tier 2 MUST be individually switchable off.
  • REQ-RANK-02 — The Tier 0 declarative engine MUST be fully functional with no learning component enabled.
  • REQ-RANK-03 — The configuration object MUST be the same artifact the GUI edits, the engine consumes, and the user can publish.
  • REQ-RANK-04 — Engagement signals MUST be collected locally and used only as the learning-throttle setting permits.
  • REQ-RANK-05 — No engagement signal may be sold, shared, or used for advertising. (Hard constraint.)
  • REQ-RANK-06 — Sovereignty spans two stages: subscriptions determine candidate scope, the algorithm determines ordering. The product MUST make that scope visible rather than implying the algorithm surfaces everything.

5.7 The Algo Studio

Purpose. The differentiating product. A GUI that lets any user design their own ranking algorithm, see exactly what it does, and then publish, fork, and subscribe to algorithms. The algorithm becomes a first-class, ownable, shareable object — and an accountable one.

Core controls:

  • The Addiction Dial — a private instrument. A single, explicitly named slider from monk mode (0) to give me the good stuff (10). The dial scales engagement-correlated content features — length, recency, novelty, and virality defined as the open web's own citation graph (how many other ASM authors and aggregators reference an item), computed from index metadata rather than from anyone's clicks or dwell time. These are properties of the item and its public reception, not records of your behavior, so the dial requires zero behavioral tracking of the user. Naming the dopamine variable and handing the user conscious control over it is the anti-dark-pattern; every engagement-optimized product pins this value to maximum and hides it. The dial is designed as a control you set for your feed; its value as a public badge is deliberately not promoted (see "On making the dial a public number," below).
  • Topic Weights. Explicit gravity per tag/type — declared, not inferred.
  • Learning Throttle. A separate control governing whether the system models you: off (declared preferences only), slow learn (periodic batch), active learn (real-time), forget mode (periodic decay to counter filter-bubble entrenchment).
  • Source / Curator Trust. Per-aggregator and per-author trust weights and mutes.
  • "Why am I seeing this?" Every item exposes its ranking rationale in the user's own configured terms.

The dial and the throttle are orthogonal — and that is the point. Because the dial acts only on content features, every dial setting is coherent at every throttle setting. This decomposition yields the product's strongest privacy story: maximum addictiveness requires zero surveillance of the individual, because virality and freshness are facts about the item, not about you.

On making the dial a public number (a deliberate restraint). A published algorithm's addiction setting may be displayed, but visibility is opt-in, never mandatory or default. The reason is behavioral: the moment a low dial setting becomes a public badge, the dial stops being a setting people use and becomes a status display — people perform "my addiction level is 2/10" while quietly subscribing to a spicier fork. That turns a self-regulation tool into a performance, the exact dynamic the product exists to counter. The dial's power is as a private instrument; its public-signal value is treated as a hazard to be contained, not a feature to be amplified.

Publish · Fork · Subscribe — the second product layer. An algorithm is a portable configuration artifact, signed by its author's Tentausando ID.

  • Publish. Make your algorithm public, addressable by your ID plus an algorithm name (tnt:8417…/slow-geopolitics).
  • Subscribe. Adopt someone's published algorithm as your feed ranker — because their algorithm produces a better feed than yours, and you can inspect exactly why.
  • Fork. Copy an algorithm you mostly like, tune it, republish your variant with provenance/lineage preserved. Version control for epistemology.

Accountability — the algorithm author owns the feed they shape. A published ranking function shapes the feed of everyone who subscribes to it. The author should own that, the way the rest of the protocol owns its claims through legibility. Every published algorithm therefore carries a computed feed-composition profile — not the author's marketing copy, but metrics derived from the algorithm's behavior over a reference candidate pool:

  • Source concentration — how much of the resulting feed comes from how few origins (a high number flags an echo chamber).
  • Diversity — spread across topics, source types, and viewpoints the feed admits.
  • Addiction profile — where the algorithm actually sits on the engagement-feature axis in practice, computed independently of the author's claimed dial setting.
  • Freshness/recency skew — how heavily the feed favors the new over the durable.

This makes an algorithm's effects legible the same way ASM makes a page's authorship legible, and gives subscribers a basis for trust that does not depend on the author's self-description. It is the responsibility half of sovereignty: you may shape what others read, but you do so in the open.

This produces emergent layers the protocol does not hand-build: algorithm-as-identity, algorithm marketplaces (an EFF "surveillance-aware" algorithm; a university "slow read" algorithm; a journalist's breaking-news algorithm), and algorithm trust graphs built around revealed intellectual values rather than platform-assigned categories.

Requirements:

  • REQ-STUDIO-01 — The Studio MUST present the Addiction Dial as a single, plainly labeled control that scales engagement-correlated content features only; it MUST NOT require or trigger behavioral tracking at any setting.
  • REQ-STUDIO-01b — The Addiction Dial and the Learning Throttle MUST be independent controls; any combination MUST be valid and coherent.
  • REQ-STUDIO-02 — All controls MUST compile to the same configuration object the ranking engine consumes (REQ-RANK-03).
  • REQ-STUDIO-03 — A user MUST be able to publish an algorithm addressable by their Tentausando ID and an algorithm name.
  • REQ-STUDIO-04 — A user MUST be able to subscribe to a published algorithm and use it as their active ranker.
  • REQ-STUDIO-05 — A user MUST be able to fork a published algorithm; forks MUST retain provenance/lineage metadata.
  • REQ-STUDIO-06 — A published algorithm's addiction-dial setting MAY be displayed publicly, but such display MUST be opt-in and MUST NOT be the default; the product MUST NOT rank, leaderboard, or otherwise gamify dial settings across authors.
  • REQ-STUDIO-07 — Published algorithms MUST be signed by the author's Tentausando ID and verifiable.
  • REQ-STUDIO-08 — Default algorithms (sensible presets and a curated starter set) MUST ship so a non-configuring user gets a good feed without building anything (see §9.3).
  • REQ-STUDIO-09 — A published algorithm MUST carry a computed feed-composition profile (at minimum: source concentration, diversity, measured addiction profile, recency skew), derived from the algorithm's behavior over a reference candidate pool rather than from author self-description, and displayed alongside the algorithm wherever it can be subscribed to.

5.8 The Reader App

Purpose. The consumer surface — feed reader, comment client, identity holder, signal source.

Behavior. The app holds the user's Tentausando ID, subscribes to aggregators and to a chosen ranking algorithm, renders the ranked feed and comment threads, and feeds read/click/skip signals back to the ranking engine subject to the learning-throttle setting. It optionally lets the user be a curator and be an algorithm author. Onboarding is deliberately trivial: a new user taps to join, is handed a host-managed identity and a good default feed, and can connect any existing Mastodon/Bluesky/RSS accounts in one tap.

Requirements:

  • REQ-APP-01 — The app MUST function as a reader against any conforming index/aggregator.
  • REQ-APP-02 — The app MUST hold and use the Tentausando ID for identity, signing, and algorithm ownership.
  • REQ-APP-03 — The app MUST render and submit federated comments.
  • REQ-APP-04 — The app MUST surface the active algorithm's controls (or a link into the Algo Studio), the per-item ranking rationale, and — when subscribing to a published algorithm — its feed-composition profile.
  • REQ-APP-05 — Engagement-signal collection MUST be local and governed by the learning-throttle setting.
  • REQ-APP-06 — First run MUST produce a usable, well-ranked feed with zero configuration; all configuration is strictly opt-in afterward.

6. User Personas

The Refugee. Left a collapsing or hostile platform; wants control without running a server. Subscribes to a starter algorithm, tunes the addiction dial down, and reads in peace.

The Curator. Has taste and wants reach. Publishes an algorithm; builds reputation on feed quality — and on a clean feed-composition profile — rather than follower count. The algorithm is the product.

The Publisher. A writer who wants distribution without surrendering it. The non-technical path: sign up with a host, write, and the host publishes ASM automatically. The power path: drop an ASM descriptor on a site they already run.

The Institution. A library, university, or organization like the EFF that publishes a values-aligned algorithm or aggregator as a public service — a "surveillance-aware" or "slow read" lens others can adopt, inspect, and trust against its published impact profile.

The Monk. Wants the minimum-addiction, declared-only feed. Sets the dial to 0 and learning to off, and the system honestly gives them exactly that.

7. User Stories (illustrative)

  • As a non-technical newcomer, I join in one tap, connect the Bluesky account I already have, and immediately get a good feed.
  • As a non-technical writer, I sign up with a host and just write; my posts become discoverable without my ever seeing a line of markup.
  • As a publisher, I add an ASM descriptor to my static site so my essays are discoverable without joining a platform.
  • As a reader, I generate a Tentausando ID in one tap, with no email, so I have a portable identity I fully own.
  • As a reader, I subscribe to a curator's published algorithm, inspect the config, and check its feed-composition profile before I adopt it.
  • As a reader, I set my addiction dial to 2/10 and turn on forget mode so my feed stays calm and my preferences don't ossify.
  • As a curator, I publish my algorithm and stand behind its impact profile.
  • As a tinkerer, I fork an algorithm I mostly like, raise the weight on my niche topics, and republish my variant with lineage intact.
  • As a commenter, I sign a comment with my Tentausando ID so my authorship is verifiable without any account.
  • As an institution, I publish a values-aligned algorithm as a public service that anyone can subscribe to and audit.

8. Business Model and Why-Now

Why-now. Two tailwinds converge. First, regulatory pressure toward algorithmic transparency (the EU DSA and analogous momentum) is moving "let users see and control the algorithm" from a niche demand to an expectation. Second, the post-platform-collapse environment has produced genuine appetite for alternatives — but the alternatives on offer are either black boxes or RSS readers. The integration layer is missing, and the moment for it is open.

Revenue (explicitly non-advertising). Advertising is excluded because it corrupts the very thing being sold. The model is the open-protocol / premium-flagship pattern proven by mastodon.social, WordPress.com, and Element/Matrix: the protocol is free and anyone can self-host, and the business is the flagship hosted experience — the polished app, a hosted home where non-technical users publish without running a website, the curated default aggregators, and a starter library of high-quality published algorithms. The flagship's revenue also funds the crawler and index it runs — which answers "who pays for discovery." Adjacent lines: hosted index/comments, and enterprise/institutional deployments. For the public-good layer, endowment or grant funding from aligned partners — Mozilla, Wikimedia, the EFF — is the natural fit. The bar is sustainability, not venture-scale returns.

The protocol and reference implementations stay open. The commercial layer is the experience and the managed infrastructure — never the ranking logic, never user data, never ads.

Positioning sentence. What if the ranking of your feed was yours — designed by you, legible to you, and publishable as an expression of how you think the world's information should be weighted? That is the open web's answer to the For You page: not a better black box, but a transparent, personal, accountable one.

9. Risks and Open Questions

9.1 Index centralization (central risk)

Reader did not die of cost; it died because a single operator discontinued the one index everyone depended on, and centralization meant no fallback existed. Because the index stores pointers and metadata only, even a multi-million-item index runs on a modest VPS — the cost problem is largely dissolved. The real existential risk is centralization: that one index becomes load-bearing enough that its death is fatal. Mitigations: keep the reference index lightweight; federate many cheap nodes; treat any "canonical hub" as one node among many. Where commercial hosted indexes contribute to public-index upkeep, that contribution must be made socially sticky — a visible "supports the public index" certification — or "voluntary" resolves to "nobody." One index can't equal a hundred — and it doesn't have to. Google degraded its own search into an ad-choked, SEO-spam product and abandoned quality open-web discovery; in the decade since Reader died no one built the replacement. The bar is to index open-web content better than a search engine that has stopped trying, not to beat the Google that still cared. Open question: the governance structure that keeps the network multi-homed as it grows.

9.2 Adoption chicken-and-egg (the existential risk — strategy in §2)

Readers need content; publishers need readers; curators need both. A high-quality protocol with no network on it is a dead protocol. Mitigations: seed with publishers already motivated to escape platform lock-in; let users opt in to bridge their own Mastodon, Threads, and Bluesky content (and ingest RSS/Atom) so the index populates without anyone abandoning their current accounts (§2, §5.4, §9.7); make the publisher cost near-zero. Self-service bridging is the cheapest content-seeding lever the project has and the primary launch strategy, which is why it is stated up front in §2 rather than treated as a feature. Open question: which source network seeds the densest, most curatable initial pool — and which single curator-community is the first beachhead.

9.3 Revealed vs. stated preference on configuration

Users say they want algorithmic control; most don't configure anything. Mitigation: the publish/subscribe layer resolves this — most users never build an algorithm, they subscribe to a good one. Configuration is for curators; subscription is for everyone. Strong defaults ship regardless (REQ-STUDIO-08). The related hazard — that the addiction dial becomes a performative badge rather than a practice — is contained by REQ-STUDIO-06 (no default public display, no gamification).

9.4 Key custody (the real identity risk)

This — not how the ID is represented — is where the identity model is genuinely exposed, and the design's answer is to not put the cliff in front of most users. The default is a host-managed, recoverable account. The key is exportable to self-custody at any time — and self-custody is where the industry's unsolved problem lives: a lost self-held key is identity death, and a stolen one has no clean revocation (the PGP/DID limitation). That cost is borne only by users who deliberately choose portability, stated plainly at the moment of export. Mitigations for self-custody: documented backup/restore; host-anchoring as a rotation anchor; optional social recovery (a Shamir quorum of trusted contacts); a hardware-backed key option. Custody never gates the content, which lives on the author's own pages regardless. Open question: which self-custody recovery patterns ship first-class vs. documented-only.

9.5 Sybil and spam in the algorithm marketplace

Cheap identities enable spam algorithms and fake reputation. Mitigations (native web-of-trust): reputation weighted by host-anchoring and by subscription provenance from already-anchored identities; lineage/forking history as a trust signal; the feed-composition profile (REQ-STUDIO-09) as a spam-resistant quality signal that does not depend on self-description; reader-level muting. Explicitly rejected: issuer-based "verified human" credentials, which reintroduce a central authority. Open question: how much of the trust-graph computation belongs in the protocol vs. in clients.

9.6 Moderation in federated comments (hard problem)

Decentralized comments raise the standard federated-moderation difficulties. Approach: moderation is layered, not central — author-level allow/block by ID, reader-level muting, and curator-level exclusion. Open question: minimum viable shared blocklist/labeling mechanism without recreating central control.

9.7 Interoperability — talk to the networks you can't fix

The three destinations each fail structurally (§1.1), but a user need not abandon them to adopt Tentausando. A bridge is opt-in and self-service (§2, §5.4). "No cooperation required" means the platform need do nothing; the individual consents by joining. This is deliberately not a firehose scrape. Decision: opt-in bridges are an early-phase priority (§10); the core protocol does not depend on them. The walled-garden case is out of scope.

10. Roadmap (phased)

Phase 0 — Specification. Publish ASM schema v1.0, the Tentausando ID specification, and a reference ASM validator.

Phase 1 — Index. Ship the reference self-hostable index and crawler with the public query API.

Phase 2 — Reader + Bridges (the seeding phase). Ship the reader app: Tentausando ID generation/import, aggregator subscription, feed rendering. Ship opt-in, self-service bridges (Mastodon/Threads via ActivityPub, Bluesky via AT Protocol) plus RSS/Atom ingestion, so the index populates without anyone leaving their current accounts. Per §2 and §9.2, bridges are the launch's load-bearing adoption mechanism, not a later add-on — this phase is where the network either takes root or does not.

Phase 3 — Algo Studio (Tier 0). Ship the declarative ranking engine and the Studio GUI: addiction dial, topic weights, learning throttle (off/slow at first), source trust, "why am I seeing this?", and the feed-composition profile computation (REQ-STUDIO-09).

Phase 4 — Learning tiers. Integrate Metarank (Tier 1); integrate Gorse/LightFM (Tier 2) as an optional layer.

Phase 5 — Publish/Fork/Subscribe. Ship algorithm publishing, subscription, forking with lineage, the impact-profile display, and the marketplace surface.

Phase 6 — Comment federation (deferred; no earlier than Phase 4). Ship identity-anchored comments per §5.5 and the moderation hooks of §9.6, only after the core loop is proven. This layer MUST stay decentralized even at the cost of latency.

11. Open Decisions

  • Licensing. Permissive (Apache-2.0/MIT) vs. copyleft (AGPL-3.0). AGPL is attractive for the index to keep hosted forks open; permissive lowers client-integration friction. To be decided per-component.
  • Signature/keypair primitive. Ed25519 is the working assumption; confirm against the base-10 human-shareable representation.
  • Canonical hub governance. Foundation, federation-only, or partner-hosted. Ties directly to §9.1.
  • Reactions model. Whether reactions.xml ships in v1 or follows comments.
  • Feed-composition profile. Which metrics are normative (required of every published algorithm) vs. optional, and what the reference candidate pool is for computing them comparably across algorithms.

Appendix A — Comparison Matrix

Capability RSS/Atom Mastodon Threads Bluesky Tentausando
Who can remove you nobody your instance admin Meta Bluesky (in practice) nobody — you own the pages
Who controls your ranking nobody (no ranking) instance default Meta Bluesky app view (feeds emerging) you — own, fork, subscribe
Content scope any web page microblog posts microblog posts microblog posts any open-web page
Identity none instance-bound Meta / Instagram portable (atproto) self-sovereign, portable
Discovery none (post-Reader) instance-based Meta-controlled Bluesky app view federatable index
Algorithm choice none chronological custom feeds (new, copied) custom feeds (mature) publish · fork · subscribe + impact profile
Structured metadata minimal moderate moderate moderate rich (typed ASM)
Comments absent native, siloed native (Meta) native federated, signed
Talks to other networks no partial (AP) partial, gated (AP) no yes — opt-in (AP/atproto/RSS)
Monetization — donations ads VC-backed ($100M+); model TBD no ads; hosted flagship

The first two rows are the whole argument: every social destination has an operator who can evict you and who controls the ranking of what you see; an open-web substrate has neither.

Appendix B — Glossary

  • ASM — Annotated Syndication Markup; the embeddable XML content descriptor.
  • Tentausando ID — a self-generated keypair whose public half, rendered as a base-10 integer, is a participant's portable identity.
  • tentausando — the number 10^1000; an evocation of vastness and the source of the product name (the identity primitive is a 256-bit Ed25519 keypair, ≈10⁷⁷ key space — see §5.2).
  • Index — the federatable metadata/pointer store providing discovery.
  • Aggregator — a curated lens over the index; itself an ASM node.
  • Bridge — an opt-in, self-service aggregator that maps a joining individual's own content from another network into ASM.
  • Algo Studio — the GUI for designing, publishing, forking, and subscribing to ranking algorithms.
  • Addiction Dial — the explicit, user-set control that scales engagement-correlated content features (length, recency, novelty, and virality measured as the open-web citation graph); independent of the Learning Throttle and requiring no behavioral tracking. Treated as a private instrument, not a public badge (REQ-STUDIO-06).
  • Learning Throttle — the control governing how much the ranking adapts to behavior (off / slow / active / forget).
  • Feed-composition profile — computed metrics (source concentration, diversity, measured addiction profile, recency skew) published with every algorithm, making an algorithm author accountable for the feed they shape (REQ-STUDIO-09).

Appendix C — Revision History

v0.10 (this revision) — structural re-sequence. Four moves, no architecture change: (1) new §0 ranking thesis as the opening, deferring machinery; (2) bridges promoted to §2 as the seeding strategy; (3) addiction-dial public-number theater demoted — REQ-STUDIO-06 makes dial-setting display opt-in and bans gamification; (4) author accountability added — REQ-STUDIO-09 requires a computed feed-composition profile per published algorithm. Prior history retained below.

v0.9 — §9.1 index-economics framing added (rebuild discovery on the ashes of big-tech decline).

v0.8 — White Paper Summary added as opening front matter (superseded by §0 in v0.10).

v0.7 — Onboarding made a hard requirement ("barely an inconvenience"); identity handle-first; bridge verification one-tap; zero-configuration first run.

v0.6 — Bridge signing fixed (authorship assertion + proof of control); identity custody model made explicit (host-managed default, exportable to self-custody); signing and index integrity hardened; virality redefined as the open-web citation graph; comments deferred and re-grounded as decentralized.

v0.5 — Bluesky facts corrected ($100M Series B, ~$123M total, 43M+ users); teardown balanced with a "what each does well" beat; failure modes named (Threads = walled garden in open clothes; Mastodon = feudal decentralization; Bluesky = centralized in practice).

v0.4 — "Why the existing networks fail" case added; Appendix A comparison matrix led by "who can remove you."

v0.3 — ASM repositioned as Atom-expressible; identity entropy stated honestly; key custody named the real identity risk; retrieval/reranking split made explicit.

v0.2 — Addiction Dial decoupled from Learning Throttle; index risk reframed from funding to centralization; native web-of-trust for Sybil resistance.

End of document — Tentausando PRD v0.10 (Draft, structural re-sequence). Red Anvil Creative.

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)