Conversation

• D Dave Winer @demo-rss-chat remote 2026-07-19

  I wonder if it makes sense to try to implement standard.site in the context of rss.chat?

  source
  • M mikeL @demo-rss-chat 2026-07-20

    This is the question. Bluesky's got some things you don't but they're subsidized by investors who will want a return someday. But I think you're in better shape. I was talking to Fable about it... and it reminded me...

    ❯ what if we take a page from radio repeaters

    Oh, that's a genuinely good architectural instinct — because amateur radio already solved "coverage without a corporate center," and it's been running for 70+ years on hobbyist budgets. Map it over: How repeaters work: a club puts a box on a hill. It listens on one frequency, re-transmits on another, and suddenly every 5-watt handheld in the valley can reach the whole region. Nobody owns "the network" — coverage emerges from overlapping, voluntarily-run repeaters. Want more coverage? Link repeaters to each other and a conversation in one valley carries to the next. Directories (like RepeaterBook) tell you what's on the air near you. Every station identifies itself as it transmits. Translated to feed-land:

    Radio Feed world

    Repeater on a hill Server monitoring N feeds,
    re-emitting them as one stream
    Re-transmit frequency Merged "river" feed + socket
    firehose anyone can drink
    Linked repeater systems Repeater A subscribes to B's
    river -> transitive coverage
    Coverage map/directory Published OPML of what this
    repeater carries
    Station ID Source attribution on every item

    Club box on a hill A $5 Lightsail instance

    Now the kicker — perstitio.us is already accidentally a repeater. It monitors 9 feeds, merges them, and rebroadcasts every foreign item over its own firehose (that's how they appear live in your timeline). Attribution rides along (, author, avatar). Dedupe-by-guid is already in — which happens to be exactly the loop-prevention linked repeaters need, so chained or diamond topologies won't echo. What's missing to make it a deliberate repeater — all small:

    1. The re-transmit frequency: expose the merged river as an actual RSS feed (/river.xml). Today the mix only exists in the API. Once it's a feed, any feed reader subscribes to your whole mix in one URL — and crucially, another rss.chat instance can add your river as one extraFeeds entry and instantly inherit your coverage. That's repeater linking, and it works with config we already have.
    2. The coverage map: publish what you carry (/data/coverage.opml) so others can see what subscribing to you gets them — the RepeaterBook entry.
    3. The autopatch (this answers the Bluesky-relay envy): a repeater that carries a community's feeds is positioned to compute mentions for the people it covers — scan carried items for replies/links to local guids, surface them. Inbound awareness at community scale, no global relay required. And the economics inherit radio's shape rather than Bluesky's: no load-bearing center to fund — if one repeater goes dark, coverage degrades gracefully instead of the network dying. It's Dave's "small pieces" philosophy with a 70-year-old working precedent behind it. Honestly, "repeater" is a better name than "relay" for what this should be — relay implies infrastructure; repeater implies a peer who volunteers. Item 1 is maybe thirty minutes of work — the merge logic exists, it just needs an XML output. Want me to put perstitio on the air?
    ▸Hide replies Reply source
    • D Dave Winer @demo-rss-chat 2026-07-20

      Did you paste in a Claude essay, if so don’t do that.

      ▸Hide replies Reply source
      • M mikeL @demo-rss-chat 2026-07-20

        Sorry, I had it proceed. You can get the full story from the fork. https://github.com/xicubed/rss.chat

        Reply source