I’ve been thinking again about this.
A plugin could add a custom topic field for the URL of the source of the primary document. (I guess it would also need fields for a remote username and api key if the main document is to be hidden, as I think is your use case, but that piece could wait. Or perhaps they could live in a user custom field. It would be up to whoever generated the key to see that the api key has read-only privileges).
When creating a topic you would enter something like "remote: https://meta.discourse.org/t/synchronising-crossposting-topics-across-different-discourse-sites/263269" and when the topic was created, Discourse would pull the remote topic’s raw text, insert it into raw as an edit and instantiate the topic_custom_field with the remote URL, perhaps adding a “copied from url” at the top.
At this point you’ve copied the remote topic locally and have a record of it.
There could then be a “check source” button that would pull the remote topic and save the remote topics’ updated_at and maybe even the raw in other custom fields (a job could also do this periodically, saving a bit of UX). You could then have a an update button that would replace the existing raw with the remote one as an edit.
If the primary site is public, then this part is really easy. Adding API an API key to pull from a private site complicates things, managing a set of API keys across multiple sites, complicates it more. If the original source needed to be replaced you could maybe do that with the remap rake task, or add the ability to edit the custom field with the remote URL when you had need to.
This part comes for free, since this solution has the secondary sites pulling the data from the primary one.
Right. And there can be a link back to the source site, so people could go to the source to see those comments, or perhaps even embed them via Embed comments from Discourse in your single page app.
If you’ve got any budget at all for this, feel free to contact me.