Idea

Worked for 12s

Research findings: Cross-posting and federated discussions in Talkyard

I haven't found an existing Talkyard feature that synchronizes a topic and its replies between two independent forums. I searched the Talkyard source repository and its public support forum for cross-posting, federation, remote forums, and ActivityPub.

What you're proposing is more sophisticated than ordinary cross-posting: one logical discussion appearing in multiple independently administered communities, with replies from either community visible in the others.

That's a feature worth distinguishing from Talkyard's existing multi-site hosting.

What I could establish

Capability	Finding
Multiple forums on one Talkyard installation	Supported
Shared forum and embedded blog comments	Supported within a site
Link from one forum to a topic on another	Possible using ordinary links
Copy a topic to another forum	No verified built-in cross-post action
Automatically synchronize replies between forums	No implementation found
Federate discussions with another Talkyard server	No implementation found
ActivityPub federation	No implementation found

Talkyard explicitly advertises that one installation can host many communities, and that a forum's accounts can also work for its embedded blog comments. But those features don't establish cross-site topic synchronization. talkyard.io

1. Your two use cases are technically different

Case A: Your forum and Magnus's support forum

Ivan the Geek

Your Talkyard category

Talkyard Support

Magnus's forum

Proposed federated discussion

One logical topic

Replies, authors, timestamps, and moderation metadata exchanged across sites

This requires communication between independently operated Talkyard installations, along with trust, identity mapping, and authorization.

It would be a genuine federation feature.

Case B: Ivan the Geek, Hardwareology, and Cheddar forums

If all three are hosted by the same Talkyard deployment, you could potentially implement a simpler form of cross-posting entirely inside Talkyard.

For example, a topic could have one canonical discussion record but multiple placements:

Topic	Visible in
OpenWrt hardware evaluation	Ivan the Geek + Hardwareology
CheddarBooks architecture	Ivan the Geek + Cheddar
General Talkyard improvement	Ivan the Geek + Talkyard category

Instead of copying posts, both forum views could reference the same underlying discussion.

That would avoid synchronization conflicts, duplicated posts, and delayed updates.

However, Talkyard would need changes to its site-level data access, permissions, topic placement, and rendering logic. Merely hosting the sites in the same containers doesn't make their topics shared.

2. A relevant existing Talkyard discussion

I found a support-forum discussion titled “Comment section being equal to a forum” from March 2021.

The user wanted a podcast episode's comment section to be the same discussion thread visible in their forum. forum.talkyard.io

That's conceptually related to your idea of one discussion appearing in multiple places, although it concerns embedded comments and a forum rather than federation between independent forums.

Talkyard already has mechanisms for connecting embedded discussions to forum topics. That may provide reusable UI concepts, but it doesn't solve cross-site identity and synchronization.

I did not find a clearly documented Magnus proposal for two-way federation between independent Talkyard forums in the public discussions searched.

3. There is an existing federation ecosystem worth considering

This problem has already received attention in ActivityPub-based forum software.

For example, NodeBB has been developing federated cross-posting, including discussions about synchronizing content between remote communities.

A 2025 discussion explored how different forum platforms represent cross-posts, and 2026 discussions describe the social and moderation challenges of sharing discussions across instances. SocialHub +1

There is also a proposed specification, FEP-d36d: Sharing Content Across Federated Forums, which addresses shared content between federated communities. fep

This is worth studying before designing a Talkyard-specific protocol.

4. What I would propose for Talkyard

I'd separate the functionality into two features.

Feature 1 — Shared topic placements

A topic can appear in multiple categories or sites hosted by the same Talkyard installation, without duplicating its replies.

Feature 2 — Federated topic sharing

An administrator or authorized user can propose sharing a topic with another Talkyard installation. The receiving community accepts or rejects it. Once accepted, the two instances exchange permitted posts and replies.

For the federated version, I would establish these rules:

• Each post has one originating authority and a globally unique identity.

• Replies retain their original authorship and parent relationships.

• Replication is idempotent, so retries don't create duplicates.

• Each community retains independent moderation and visibility controls.

• Private content is never federated without explicit authorization.

• Deleted or edited posts have defined propagation behavior.

• Federation relationships can be revoked without corrupting historical discussions.

The identity federation we've been discussing would help authenticate authors, but it would not by itself authorize another forum to publish or replicate their content.

5. How this fits your event-sourced architecture

This could be modeled as an extension rather than a traditional database synchronization mechanism.

For example:

TopicShareProposed
TopicShareAccepted
TopicFederationEstablished
PostPublished
PostFederated
RemotePostReceived
RemotePostAccepted
TopicShareRevoked

Each forum would maintain its own local projection of the shared discussion.

That would align with your event-sourcing approach, although Talkyard itself is not built around this event model, so integration would require an adapter or modifications.

6. My recommendation

For your immediate needs, I'd start by proposing shared topic placements within one Talkyard installation, because it's simpler to implement and would be useful for your Hardwareology and Cheddar communities.

Then design cross-instance federation as a separate feature, ideally using existing ActivityPub conventions rather than inventing an entirely new protocol.

The most interesting architectural question is whether you want one shared discussion with a single authoritative copy of every post, or separate discussions that exchange replies while maintaining independent moderation.

I favor one authoritative origin per post, with each participating forum maintaining its own view. That provides a cleaner model for authorship, edits, deletion, synchronization, and recovery.

The official resources are Talkyard source repository and Talkyard development and support forum.

I would treat the current status as not implemented, but architecturally feasible, with the intra-installation sharing feature being the simpler starting point.