Build threadiverse group federation example and tutorial (Next.js + Node.js)

[dahlia]

Sub-issue of #99. Deliver the threadiverse group federation scenario as a paired example repository and fedify.dev tutorial.

The purpose of this example is not to clone Lemmy, Mbin, or NodeBB feature-for-feature. The point is to implement the smallest useful threadiverse-shaped application that interoperates cleanly with existing software in that family and teaches the patterns that the current Creating your own federated microblog tutorial does not cover.

That existing tutorial is actor-centric and timeline-centric. This one should be community-centric: users participate in shared federated communities, create threads inside them, and reply inside those threads. The central lesson is how to model a community as an ActivityPub Group, how users interact with that group as Person actors, and how community-side redistribution works via Announce.

Scenario

A federated discussion platform organized around communities. Local users can sign up, create communities, follow remote communities, create threads inside communities, and reply to existing threads. Threads may be either text posts or link posts.

This should be designed around the common denominator already shared by threadiverse software such as Lemmy, Mbin, and NodeBB:

• communities / magazines / categories as Group actors
• users as Person actors
• top-level discussion threads as Page-like objects
• replies as Note
• subscriptions as Follow(Group) and Undo(Follow)
• community-side redistribution via Announce

The scenario should feel recognizably threadiverse-like, not like a larger variant of the existing microblog tutorial.

Stack

• Framework: Next.js (App Router)
• Integration package: @fedify/next
• Runtime: Node.js
• ORM: Drizzle ORM
• Database: PostgreSQL

Feature checklist

• Signup/login: minimal username-and-password auth sufficient to distinguish local users.
• Local user actors (Person): persisted key pair per user, WebFinger, and a minimal public profile page.
• Community actors (Group): persisted key pair per community, canonical community URL, inbox, outbox, followers collection, and WebFinger-discoverable handle.
• Community creation: local users can create a community with a name and description.
• Community subscription: local users can follow and unfollow local or remote communities using Follow and Undo(Follow).
• Follow acceptance: local communities automatically respond with Accept(Follow).
• Thread creation: local users can create either a text thread or a link thread inside a community. Threads are federated as Create(Page) to the target community.
• Reply creation: local users can reply to a thread or to another reply. Replies are federated as Create(Note).
• Thread editing/deletion: Update(Page) and Delete(Page) with Tombstone.
• Reply editing/deletion: Update(Note) and Delete(Note) with Tombstone.
• Community inbox handlers: Follow, Undo(Follow), Create, Update, and Delete for threads and replies addressed to the local community.
• Community announce flow: when a local community accepts a thread or reply, it redistributes that activity to its followers as Announce.
• Community listing page: ordered list of recent threads in the community.
• Thread page: thread content plus replies rendered in a reply tree.
• Subscribed front page: recent threads from communities the viewer follows.
• Local communities index: list communities hosted on this instance.

Interoperability constraints

• Model communities as Group actors, not as user-like Person actors.
• Use Page for top-level threads. The implementation may also accept Article for inbound compatibility, but the example should emit Page for its own thread objects.
• Use Note for replies.
• Attach thread and reply objects to their community via audience and appropriate to/cc addressing.
• Keep the first pass close to FEP-1b12-style group federation patterns.
• Prefer broadly interoperable ActivityPub semantics over software-specific extensions.

Deliverables

1. Create fedify-dev/next-threadiverse under the fedify-dev org. Full runnable Next.js app implementing the feature checklist above.
2. Write docs/tutorial/threadiverse.md on fedify.dev as a step-by-step walkthrough of building the example from scratch. The tutorial should cover @fedify/next setup in App Router, modelling Person and Group actors, representing top-level threads and replies, and implementing community-side Announce redistribution.
3. Add the new tutorial to TUTORIAL.items in docs/.vitepress/config.mts so it appears in both the top navigation and the sidebar.
4. README of fedify-dev/next-threadiverse links back to the tutorial.
5. Tutorial cross-links the Node.js section of the Deployment docs (Best practices for production deployments #689) and the @fedify/next integration docs for running the example in production.
6. Add an entry to CHANGES.md.

Out of scope

• Votes, downvotes, ranking algorithms, hot/active sorting, or karma.
• Moderator roles, removals, bans, reports, or other moderation workflows.
• Media uploads and galleries.
• Direct messages.
• Private communities.
• Deeply nested reply UX beyond a simple reply tree.
• Cross-community synchronization features beyond basic follow-based federation.
• Direct-address posting to a community handle as a required feature.
• Full support for every software-specific extension used by Lemmy, Mbin, or NodeBB.