Future: additional Connection_Providers (Threads, Nostr, email newsletter)

> Stub — flesh out later when the Radical Month MVP epics ship and we have signal on which silos matter.
>
> Internal tracking: [DOTCOM-16922](https://linear.app/a8c/issue/DOTCOM-16922/future-additional-connection-providers-threads-nostr-email-newsletter)

## Context

FOSSE today ships two `Connection_Provider`s: ActivityPub (Mastodon and the wider fediverse) and atproto (Bluesky). The `Connection_Provider` architecture introduced in [PR #27](https://github.com/Automattic/fosse/pull/27) was deliberately pluggable so we can add more.

POSSE's framing — *Publish (on your) Own Site, Syndicate Elsewhere* — implies the value of a POSSE hub scales with how many "elsewheres" it reaches. Three concrete near-term candidates surfaced from the [Citation Needed](https://www.citationneeded.news/posse/) / [IndieWeb wiki](https://indieweb.org/POSSE) / [Molly White micro-blog](https://www.mollywhite.net/micro/entry/202403091817) reading:

1. **Threads** — Meta now exposes ActivityPub federation on Threads. Likely cheapest add: probably falls out of the existing AP path with minimal FOSSE-side work, but worth confirming end-to-end (handle discovery, reply backfeed, deletion semantics).
2. **Nostr** — protocol with a clean "your domain *is* your identity" story (NIP-05) that pairs naturally with WebFinger / `did:web` work. Smaller user base than Bluesky but high alignment with FOSSE's self-hosted-first ethos.
3. **Email newsletter** (Buttondown / listmonk / native) — Molly White explicitly calls RSS the original POSSE channel. Email subscribers are the next tier up: a real syndication target, not just a feed. Could ship as "every published post fans out to your list" with per-post opt-out.

## Why deferred

- The Radical Month MVP is self-hosted-first with AP + atproto. Adding providers before that is demoable would dilute the demo.
- We don't yet know which silos FOSSE users actually want next. Adoption signal from FOSSE usage tracking should drive the order.
- Threads via AP may "just work" once the MVP epics ship — would change the scoping significantly.

## When to flesh this out

After the Radical Month demo, when:
- The MVP epics are shipped and stable.
- Adoption / metrics work is producing real signal.
- We have at least one external partner running FOSSE in production and surfacing concrete silo asks.

## Out of scope here

- Routing / per-post-type targeting → tracked separately in #43.
- Hosted relay infrastructure → tracked as a separate exploration.
- AT Protocol niche lexicons (standard.site etc.) → tracked as a separate exploration.

## References

- https://www.citationneeded.news/posse/
- https://indieweb.org/POSSE
- https://www.mollywhite.net/micro/entry/202403091817

---

This is intentionally a long-horizon idea — not on our near-term plate, but external interest and contributions are welcome. Discussion happens here; internal Automattic tracking lives in Linear.

No implementation file or test is named; start by reviewing PR #27 and the existing ActivityPub and atproto Connection_Provider implementations. Revisit this issue after the MVP and adoption work provide a selected provider and concrete requirements, then define completion around end-to-end syndication behavior and its tests.

Written by the indexing model from the issue text.