# Byline (RSS/Atom/JSON Feed extension)

Byline is an open specification by [Terry Godier](https://terrygodier.com/) that adds structured author context to syndication feeds. It's a new XML namespace (`https://bylinespec.org/1.0`) layered on top of RSS 2.0, Atom, or JSON Feed — feeds without it keep working, readers without it keep working.

The framing on bylinespec.org calls the gap it fills "the context problem": once a reader pulls personal blogs, journalism, corporate posts, and satire into the same timeline, every item renders identically and the human has to remember who's who. Existing `<author>` (RSS) and `<atom:author>` carry name/email/uri at most — not enough to render an author card or tell an opinion piece apart from a news report.

## Elements

- **`<byline:contributors>`** — channel-level container holding one or more author definitions.
- **`<byline:person id="…">`** — an author, addressable by `id` from items.
  - `<byline:name>` — display name.
  - `<byline:context>` — one-sentence bio, ≤ 280 chars.
  - `<byline:url>` — the canonical URL for this person.
  - `<byline:avatar>` — profile image URL.
  - `<byline:profile href="…" rel="…"/>` — external profile links keyed by `rel` (`mastodon`, `github`, …).
  - `<byline:now>`, `<byline:uses>` — pointers to IndieWeb `/now` and `/uses` pages.
  - `<byline:theme color="…" accent="…" style="light|dark"/>` — author-side hints for reader visual customisation.
- **`<byline:author ref="…"/>`** — per-item reference to a defined person.
- **`<byline:perspective>`** — per-item content-type tag from a controlled vocabulary: `personal`, `news`, `review`, `satire`, `official`, `sponsored`.

## Example

```xml
<rss xmlns:byline="https://bylinespec.org/1.0">
  <channel>
    <byline:contributors>
      <byline:person id="annie">
        <byline:name>Annie Park</byline:name>
        <byline:context>Designer and photographer based in Portland. Previously design lead at Figma. I write about creative tools, process, and the indie web.</byline:context>
        <byline:url>https://annie.example.com</byline:url>
        <byline:avatar>https://annie.example.com/avatar.jpg</byline:avatar>
        <byline:profile href="https://mastodon.social/@annie" rel="mastodon"/>
        <byline:profile href="https://github.com/anniepark" rel="github"/>
        <byline:now>https://annie.example.com/now</byline:now>
        <byline:uses>https://annie.example.com/uses</byline:uses>
        <byline:theme color="#4A90A4" accent="#FF6B6B" style="light"/>
      </byline:person>
    </byline:contributors>
    <item>
      <byline:author ref="annie"/>
      <byline:perspective>personal</byline:perspective>
      …
    </item>
  </channel>
</rss>
```

## Design principles

From bylinespec.org:

- **Progressive enhancement** — feeds and readers without Byline support keep working.
- **Decentralised identity** — URIs and IndieWeb conventions, no central registry to "claim your byline."
- **Format-agnostic** — same data model maps to RSS 2.0, Atom, and JSON Feed.
- **Privacy-respecting** — no tracking, pseudonymous identities supported.

The decentralised identity is the key political choice — there's no Bluesky-shaped DID layer, no namespace authority, no account anywhere. Your domain is your identity, the same way `rel="me"` works in HTML.

The controlled-vocabulary `<byline:perspective>` is the load-bearing part for reader behaviour: a free-form tag would let a reader display the value but not act on it; a closed list lets the reader filter, group, or restyle by category. Also the part most likely to attract spec push-back ("where's `interview`? where's `tutorial`?").

## Status

Under consideration, expected to be accepted and published by the end of 2026 per [[coywolf-byline-rss|Henshaw's writeup]]. Maintained at [bylinespec.org](https://www.bylinespec.org/), released under **CC0 1.0**. Companion tools include a validator and a generator.

The spec is coming from a reader-app developer (Godier ships [Sourcefeed](https://www.sourcefeed.app/) and [Current](https://www.currentreader.app/)) rather than a publisher coalition — the same shape as how `<podcast:*>` extensions arrived through podcast-app developers needing better data to render.

## Related

- [[coywolf-byline-rss]] — the article that brought this into the vault.
- [[digital-garden]] — the publishing surface most likely to want richer author context.
- [[filesystem-is-graph-database]] — small data formats grow when adjacent tools start needing them; same pattern.