It would be useful to be able to make a local copy of a “thread” from another node without participating in that other other thread. Think of it as a git branch.
Rationale:
-
Resilience to bugs & failures. When the other node is up and down with sketchy reliability, that seems to impact external users from participating in a thread. e.g. I get “error 500” in some cases when trying to read lemmyWorld threads. A reliable node should not impose a bad UX in situations where there is a dependency on an unreliable node.
-
I am prejudiced against some threadiverse nodes, as I’m sure many people are. E.g. I want no participation with lemmy.ml because I do not want to support their oppressive management style. That means I’m only interested in some minimal consumption of content from lemmy.ml, not production of content. So if an interesting thread emerges on lemmy.ml, there’s some benefit to being able to create a local branch where local replies are not copied back to the parent.
This feature could perhaps be called mirroring, ophaning, or branching.
It would be useful if on a case-by-case basis the user who starts a new branch can specify whether or not parent comments are also copied locally and somehow indicated as read-only.
You can create a new thread linking to the old one (or the url the old threads is linking to).
Yeah, that’s a decent hack. Though it requires creating the same magazine locally (fair enough), but if there already is a local magazine that’s federated to that other instance, then it’s complicated.
I guess I’m not clear on how federated magazines work. Suppose we have:
- domainX.social/m/immigration
- domainY.social/m/immigration
- domainZ.social/m/immigration
and someone locally creates a local.social/m/immigration@domainX.social. Does that mean we can still create a an unfederated local.social/m/immigration? Or can multiple federated magazines be combined in the same local mag?
And what if domainY has a right wing extremist anti-immigration slant which we don’t want. But we want domainZ’s version but domainZ has federated with domainY?
In your example, it wouldn’t be
local.social/m/immigration.social. If a user on local.social created a immigration magazine it would belocal.social/m/immigrationThepart is only for remote magazines. So that same magazine viewed from domainX would bedomainX.social/m/immigration.social.local.social/m/immigration.socialis an immigration magazine hosted on domainX.social and accessed from local.socialOr can multiple federated magazines be combined in the same local mag?
Not currently. There are multiple proposals for grouping magazines that are being discussed.
And what if domainY has a right wing extremist anti-immigration slant which we don’t want. But we want domainZ’s version but domainZ has federated with domainY?
You can subscribe to whichever one you want. domainZ.social/m/immigration is not affected by whatever the users on domainY post to domainY.social/m/immigration. They are two separate communities.
