I currently have a topic one one site, which I would like to also have on another site. Whilst I could hyperlink it, what I would really love is the ability to edit it on either site, and have the changes reflected on both. This saves me from having one version of the topic which is vastly out of date, and instead keeps both topics constantly up to date. It also provides a way for me to decentralise the information from my site.
Some thoughts on functionality
As a starting point, one site would remain as host/owner of the topic, and the other(s) would essentially mirror it. Going further, I even wonder if a topic could somehow be inherited by a mirror topic if the original is deleted.
The topic should retain the ability to be hidden, closed etc on the mirror sites
The replies should not be synchronised – each site has a different userbase, so I can’t see how synchronising replies would work
I understand the implementation of such a feature is very far from trivial, but I’m wondering if this has ever been looked into, and what results/experiments already exist?
Could you give a bit more information on this? From my perspective this would recuce the duplicate content.
Backup is not the objective, rather to create a single point of truth for topics which would make sense on more than one site.
To give a concrete example, I’m looking at changing my Visa. I have a Topic in my private Discourse which is basically a checklist of what needs to be done. However, my friends may also find this useful so I create the same topic on our shared Discourse. The problem is, that I need to synch the information of both topics separately instead of just updating a single topic. This means I often have one of the topics missing key information.
I guess this might even be possible with just an api key to the other site? Perhaps something like a button/section in the editor where a list of api keys and urls for the target topic can be created. When you make changes to a source topic, you can click something like “push changes to clones of this topic”. All this would do is push the update to the topics on other instances.
Put the information in exactly one place where everyone can see it. A link is how to do that.
But you have secret information that you want to make available somewhere else. That’s something else. It’s quite possible with a plugin. It’s the kind of problem where the contrived solution requires 10X the work that the actual problem would require. (I often spend hours automating a task that needs to happen only once, for example.)
But you’d need to put it somewhere that it would be available only to the user that posted it. Or make it site-wide?
Again they need to be per-user and in the serializer just for the current-user (or maybe store it in the user profile?). And you’d need some data structure to map API keys to the different sites. Seems like something I’d think I could do in 2-5 hours.
So you somewhere need to store the URL for the other sites that are supposed to have this topic. How to create that post could be complicated too; the easiest way is to just create it by hand and include the URL of that topic in the source site. You could probably store that in the raw post in some kind of BBcode or something like that. That would let you create a component that would create the button and link for each of them and then you’d have Rails code that would queue a job that would try to post it to the other site(s). But the receiving sites wouldn’t need any code–you could use the api to push an edit to the post.
Seems like the kind of thing that I’d think I could do in 5-10 hours but would likely take twice that. If that’s fun for you, then it could be a cool project.
This could also be done through an external little app which would listen for a webhook sent on edits on your source site, and then use the api to post on the mirror site.
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.