The central site could pull RSS from the regional sites.
Perhaps better would be for the regional sites to give the central site API access.
Note that I question the wisdom of having “cross posting”. In addition to there being duplicate content issues there is the potential of having divergent discussions which IMHO tend to be confusing and messy much more often than not.
I have a similar use case with independent local groups under an umbrella (national) organization. Much of the documentation (training, standards, policy, education) and downloads (template documents) are global but day to day operations are almost exclusively local. Our intention is to encourage cooperation and discussion between all groups so a key driver is to have all users able to participate globally.
If I had multiple instances of Discourse then I’d very quickly discover that category management is nowhere near as important as user management. Each post has an owner and it is generally important to retain that relationship particularly if I want global topics to flow naturally from local topics.
That’s why my prototype used one Discourse instance with each group owning its own category. The only reason that I might not consider doing it this way is if the number of local groups exceeded Discourse’s capacity to process that many categories. I only have 200 local groups in my country and even worldwide there are only 400 so this is not a problem for me.
There are several cost benefits from using one Discourse instance:
not paying for all those local instances
centralizing Discourse expertise and standardizing processes, e.g. making it easy to add any new groups
emphasizing that all local groups are part of the global group, e.g. making it easy for users to transfer to another group
My use case involves Discourse instances for local communities in London (I have three instances at the moment and want to branch out further)
Sharing certain discussions between instances would be great!
No doubt a difficult change from a technical point of view (two way syncing, user accounts, security, edge cases etc), but if it worked, it would massively help my forums bring neighbouring local communities together in London. It would also allow me to seed content more easily on new forums.
A couple of ideas (apologies if they are naive from a technical PoV):
One or more categories on Forum B are configured to “mirror” chosen catgeories of Forum A.
New topics created on Forum A would be automatically created on Forum B (authored by a staged user unless a user with the same email address already exists).
Replies to the mirror topic on Forum B would be synced back to the topic on Forum A, and vice versa.
“Live Topic Links” to Discourse Instances
When a topic is created on Forum A by pasting a URL to a topic on another Discourse instance (Forum B), the user is prompted “would you like to sync replies between this forum and the forum you’re linking to?”
If the user clicks “yes,” replies to the mirror topic on Forum B would be synced back to the topic on Forum A, and vice versa (if Forum B has “whitelisted” Forum A)
@eviltrout brought up the idea of federation a few months after Discourse launch, its a very complex problem socially. It is an “invasion of a community” to have proper read write shadowed. Who owns the data? and so on.
This however I find much more appealing. Integrating “embed” has a lot less downsides cause information ownership is much clearer.
I like that this topic discusses specific use cases (which, to me, seem to be not so uncommon). Trying to solve these cases could be a way of creating/improving some workarounds for two frequently recurring issues:
I suppose this belongs to the NGI0 Discovery grant obtained recently. Using ActivityPub would probably solve a lot of headaches differentiating local and remote content and apply different rules… It would indeed help rethink the #discourse_hub…