Support linking of Objects between Spaces. Specifically, allow the use of inline links (“@”) and /LinkTo to create a link to an object in another Space. Clicking on the link would open a new window with the target Object open in the other Space.
HOW COULD IT BE DONE
Extend the inline link “@” and /Link commands to select a different Space. When that Space is selected, provide a MRU list of the Objects in that Space.
REAL WORLD USE CASES
I like the separation that Spaces provide, and want to use them for separating domains such as “Task Management” and “Standard Operating Procedures”, “Marketing”, “Personal”, “Legal”. It keeps things from getting incredibly cluttered with irrelevant information when performing a search (or looking at a Graph view). But it’s too restrictive. Treating Spaces as name spaces, to extend the (Object/Type/Graph metaphor) would be constant with the current mental model of Anytype, as well.
RECOMMENDED ALTERNATIVES
A less elegant solution would be to allow copy of a local URL to an object in the target Space/Object, and then paste that within the Object.
May I add the ability to move or copy objects between Spaces?
I figure in detail it might be complex to implement, particularly how to deal with Relations and Types that exist in one space but not in the other.
However, the basic functionality to select, copy & paste multiple objects from one set or container in one space across to another space (while simply warning of missing relations and types) would already be really helpful.
Later then, a refined functionality could offer to recursively re-create all related and necessary types and objects.
Essential use cases for this would be
re-factoring how I organize notes, e.g. when I decide one day to separate work and private notes, or to implement an approach like PARA
migrating from my current “test version” of Anytype to a “production” system that I really want to use.
cleaning up my Anytype system from clutter and useless relations, by moving only the “good” objects and their dependencies to a new space, instead of having to manually delete thousands of “unwanted” ones.
Actually, after nearly a year of testing Anytype, I’m ready to go all-in with Anytype now and make Anytype my central tool for note-taking and project management. However, I see now how I’m stuck with the “good” data in my test system already, struggling to get it separated from all the useless test and sandbox objects and relations that have amassed in Anytype already.
I know one way to migrate objects between spaces is to export and import all objects, and then delete all of the unwanted objects and relations from the copy. However that seems to be a crazy procedure to do multiple times. Moving individual objects with their essential relations appears to be the far less intimidating approach.
I just noticed that linking between Spaces actually works — but it feels like a hack and may “work” in an unintended way:
STEPS TO REPRODUCE
Create a new Space A. Designate it to use case “projects”.
go to the automatically created sample project, and add a new task
copy all blocks of that sample project object to the clipboard
go to some page in another Space B, and paste the clipboard
the pasted project appears, but with a missing “Project tasks” Set
click the “Project tasks” header > Open source set
the source Set opens, back in Space A where the link still points to.
=> so this click shows that technically it’s possible to click a link in one space that opens a defined object in another space. Not that this does not demonstrate how to use the linked Source set content from one Space within another Space, but Anytype can link to that object in the other Space. So we’re capable of relating, but not yet of transcluding.
This is great, as it seems to show the feasibility of this FR. What’s still missing is a simple way to implement it properly:
HOW COULD IT BE DONE
As with any other web link that we paste somewhere, the user could:
go to the destination object (or ideally, for #deeplinking, to the destination block) in the destination space
there, e.g. right click to copy some “object link” (ideally a URL)
go to the page where to place the link.
paste the “object link” there
if necessary, rename the link so that it shows with a good wording
This is not as perfect as the suggested MRU list of Objects in the destination Space. But it’s definitely a MVP — and IMHO a truly viable solution.
I have the same question and was hoping someone had brought it up here since it has not been addressed on the roadmap. There, I wrote: I agree that both linking and copying are crucial and would love an update on this. I signed up as a co-creator anticipating the linking between spaces!
Can someone provide some insight? Links and relations between spaces seems quite different from copy/paste between spaces. What is the plan for this, and will links/relations be supported?
Hey @klm! Thank you for your interest in this topic. We plan to implement this use case in three stages. We’ll start with the most obvious and easy-to-implement scenario: copying and pasting files. After that, we’d like to support copying and pasting objects that are not files. As a final step, we’ll provide a different menu (copy-to: another-space etc.). It’s important to approach this project step-by-step to identify and address potential bugs, which is why the project was divided. Now you see the first iteration in our RM.
Hello. Thank you for the additional info This is the explanation that I think some of us in the roadmap discussion and here lacked. However, unless I misunderstood, this explains how the implementation of copying between spaces is going to be handled, but what about linking and relations between spaces? Are there any plans for this, is it on the back burner until the copying is implemented to your satisfaction, or is it entirely dropped from the plan?
I reiterate my opinion from the roadmap discussion linked above, without these kinds of information in the roadmap issues (what the issue encompasses, whether it links to any of the FRs here in the forum, etc.), the roadmap is unusable for us, users, if we cannot know what an issue copying between spaces, which has even been a different issue entirely in the beginning (linking between spaces), in the roadmap encompasses. (Please do not use the same issue instance for different features, it creates only confusion, in my opinion.) For example, for me this means that I will have to ignore spaces and collaboration for the foreseeable future until the linking is implemented. That is fine, but I think the users need to be aware of this. This means that I know I can continue implementing my system in the single space I have for a single user use cases. I do not have to postpone polishing and improving my space until every new update drops to see whether I can try to move more people around me to Anytype where we could share spaces and each of us would have their own view of the shared data in their own spaces. This is, I think, a very important aspect in deciding whether to adopt Anytype for at least some of us.
Furthermore, I think @y0ur1’s answer should not be marked as a solution to this FR about linking between spaces. This is not a solution for a FR (nothing is implemented), and it is not even relevant to linking between spaces, it is about copying.
Hey. Thanks for trying to help It is a good first step towards the goal of this and other FRs, and it and of itself, it works as expected, I would say. But it is definitely not what I need/want from spaces for me to consider them usable for my use cases and to try to get other people to use Anytype, either.
This is the explanation that I think some of us in the roadmap discussion and here lacked. However, unless I misunderstood, this explains how the implementation of copying between spaces is going to be handled, but what about linking and relations between spaces? Are there any plans for this, is it on the back burner until the copying is implemented to your satisfaction, or is it entirely dropped from the plan?