This is the part that wasn’t clear in previous communication. It’s great to know that per-object sharing is in the work!
Awesome!
@anton thank you for these responses, Makes me feel great about buying into the Co-creator membership from the beginning 
Keep it up! I hope that one day I can proudly say that I witnessed the birth of this amazing product!
And also…
Recently, I’ve shared some criticism about Anytype. I hope it doesn’t discourage the team. I’m truly grateful to you all for developing this product from the bottom of my heart.
@anton Would it be relevant to create a post to gather all the suggestions/needs on the dashboards? Or is it better to wait for a future first release?
2025 is Anytypes year of advancement! This is the year, where the problems of before, become the benefits of today!
Thanks for the update @anton ! I think it’s great! Look forward to seeing the progress this year!
thank you!
Hello. I’m grateful for your work.
Recently, I started using Anytype, beginning with the PARA template (slightly modified) to manage personal projects.
I’m eagerly anticipating the implementation of “Collections + Sets = Lists (+ UX improvements)” since currently, some features are available in Sets, while others are in Collections.
Additionally, the ability to group by property in Collections or Sets is lacking.
Thank you! Not this year 100%, but in the next the chance is high.
Yes, I think it’s a bit too early. Closer to autumn I think it would be right time to talk it over.
@anton I’ve two questions about the planned combination: Set + Collection = List:
It’s important for me to know that, because I need to restructure not only my whole main Space, but also a Space that I want to share with my study colleagues.
At the moment there are everywhere hard to explain, time consuming, ugly workarounds necessary, caused by needed but non existing features.
Waiting for the new “List” would theoretically be the best solution, if I can relay on that it offers lots of Views – and if comes in less then four months (no pressure; it’s simply needed in our study group).
What I’m really looking for, are nested or stacked Views:
Main category View → under category View
Example:
Hobbies
--> Football
--> Chess
--> Cooking
Projects
--> Renovation
--> Project B
--> Project C
Study
--> Anatomy
--> Skin diseases
--> Eye diseases
--> Heart diseases
Office
--> Tax
--> InvoicesAt the moment I solve it with Sets, stacked into Collections.
It mostly works, but it comes with complicated problems in detail that need a bunch of time consuming workarounds, that I realistically could not explain to my colleagues (who are newbies that I need to convince from my system before they accept it).
What do you mean by Collections? View tabs?
EDIT: Oops, I’ve completely forget what Collection was 
My bad. I only use Sets from the begining for all the reasons already mentionned by others.
See this post (with screenshots):
In short:
The principle of this concept is, that Collections never show normal Pages.
They show in their Views only Sets.
Meanwhile I’ve developed the concept further, my Graph looks very different now from that screenshot some days ago.
Now, in some cases, my main Collection shows also some other Collections, as well as well as “special Pages” that exist only for containing inline-Sets (in Toggles).
But again: No Collection does show Objects!
Collections serve in this concept only for two tasks:
In tendency, this concept is a “revolution”! – I can reach each of my thousands Objects in the whole Space by navigating in a tree like structure, but a better one then a “normal”, simple tree.
In most cases I need no scrolling at all, nor in the side menu, nor elsewhere.
Typically only in the last step I sometimes need to scroll a tiny bit in the Set’s Grid.
Normally (that means: in most cases) I can find every Object with only three mouse clicks. A fourth will open it.
It’s incredible quick! And I can have a 1000 or even more Views!
BUT …
In practice, there are also flaws – hard to explain.
I work around these practice problems with special Tags and with filter settings for each of the many Views. Also by stacking Inline-Sets into Toggles. The Pages with these Toggles exist only for containing alternations of Inline-Sets that are all based on the same Set.
I know, that sounds confusing, and it is hard to explain.
Everything would be fine, If we would already have this new “List” (a combination from Set & Collection) AND if this new List would have lots more Views that we can group in a hierarchy.
I foresee a lot work for all of us when “List” finally comes.
Most of us (the users with thousands Objects) will see good reasons for restructuring the whole Space, because we will have a completely new and better principle that we can use for structuring the Space and navigating in it.
This will go hand in hand with “Tag as Object” (I hope this comes before “List”, or at the same time, but not after “List”!).
I foresee that we all will spent a lot time to tag Objects in a new way and to configure lots and lots of View settings.
But it will be worth it!
As I seen, your nesting structure seems to be : Set → Collection → Sets
But your system could also solely rely on Sets right? Why use Collection for the second level?
Nope.
The root thing is a Collection.
In most cases (and good for thousands Objects), the structure is as simple as this:
Main Collection (View 1)
--> Set 1 (View 1)
--> Object 1
--> Object 2
--> Object ...
--> Set 1 (View 2)
--> Object 15
--> Object 16
--> Object ...
--> Set 1 (View 3)
--> Object 36
--> Object 37
--> Object ...
--> Set 2 (View 1)
--> Object 150
--> Object 151
--> Object ...
--> Set 2 (View 2)
--> Object 300
--> Object 25
--> Object ...
--> Set 2 (View 3)
--> Object 36
--> Object 1
--> Object ...
And so on.
In this example, the main Collection shows here only one View, but of course there are more. Maybe 12 or so.
In each View are about 10-20 Sets to see. Let's say, in average 15. That means: 12*15=180 Sets.
And each of these Sets has maybe 10 Views.
That means: 180 Sets * 10 views = 1800 Views!Wrong, my second level contains only Sets.
The root is a Collection, the second level are a lot Sets
But in principle, it’s a good question, I was thinking a lot about this before and while making this structure.
Weighing up the pros and cons, I came to the conclusion, that a Collection would do the best job as the root “thing”.
– One of the reasons for this decision already no longer exist, after rebuilding everything. But I still think that it makes most sense.
It would be a lot writing to explain it; in principle is everything possible, but each way has it’s own advantages and disadvantages.
It also depends from your old way to organize things. I highly relay on Tags. And I use Sets for gathering Objects from everywhere, based mostly only on their Tags.
I could use a Set also for the first level, instead of a Collection, yes.
But there’s a lot to speak about it.
One point is, that my main Collection now is the most central point in the Graph.
It leads to the many Sets in it.
These Sets then, are connected to Collections, that contain Objects.
Deviating from my post in the other thread, my new Graph looks so:
It has a much better structure now and my rebuilding process is still in progress.
But to have a Collection as first level has theoretically also the advantage, that I simply need to put the second level Sets in it, without the need to tag them in a specific way so that a first level Set could deal with them.
– In practice it differs again – indeed there was need to tag the second level Sets …
But spare me to tell the whole story.
There are workaround for different limitations here and there that make it hard to explain.
At the moment I suffer from the fact that Objects, if new created from inside a Set, become floaters in the Graph. I’ve already requested a feature for that, some days ago.
At the moment, I need to connect each new Object by hand with a target Collection. This is a disadvantage, compared with my old way to organize things.
The new “List” will end this little suffering and some others, I think.
If you’re talking about a hierarchical view, I’m not sure yet. I can see how it could be done, but our focus is currently on the primitives project. Right after that, we’ll start working on new lists, which are also closely related to tags as objects.
Thanks for the information!
Although sad, it was important for me to know that it will not come as early as needed.
Now I need to to built my structure accordingly.
This will cause a lot work to restructure everything when the hierarchical Views come at some point later in time.
That and if/when hierarchical tags come. That will blow our structure out of the water. One would hope some tools for conversion would be available but with 2 devs on the problem I do not think that is a realistic expectation.
I say all this because I know many of us do not use the Tag property, because it then creates insanely long lists to wade through…many of us break it up by creating many properties with their own subset of tags. We do all this because we needed workaround for missing features. One of them being inline sets/collections sourced from global sets/collections. I have many properties of type tag just to support proper filtering of inline sets.
All of these will have to be migrated to a new hierarchical tag system.
I am aware this will come at some point and it is what it is. I don’t know of a strategy to make a flat structure future proof for hierarchical structure. If anyone has suggestions, would be great to hear it.
This may not be such a big deal for users with small set of objects. But enough people use AT seriously and have thousands of objects. For those, this will be a true issue
Cheers
Well said, @UnwokeNetizen !
I believe it will make no problem for the users to switch to hierarchical Tags if they become implemented. This should be only a one hour thing.
But to restructure all the Collections and Sets to Lists with hierarchical Views will make a lot work for everyone. All these Views need to be configured. But this is only part of the work. we all will need a lot brain work.
I experience it at the moment; since a few days I rebuilt my structure and the navigation principle. On first glance it seemed to be a quick thing, but the problems lured on the detail level.
I must bring it to an end now, well knowing that in some months or so a new restructuring is waiting for me.
Tag as Object was big announced long ago, but delayed again and again.
Waiting for it, I shove problems before me until the heap in front of me became too big. Now I’m forced to do something (using existing methods).
But I also see the problems for the devs. They don’t start fresh from zero, they need to do everything without crashing the users existing structures.
As nice as Anytype is (I love it!) – it’s clearly a still not finished software that even lacks some basic features, while it is at the same time advanced in other disciplines.
I am wondering how you see tag as an object beneficial?
I presume tag as object does not mean hierarchical tags?
Perhaps I am missing something…and perhaps tag as an object will pave the way to this…but I look forward to not just hierarchical tags, but inline tags and declaring them as simply as parentTag/childTag on the fly…obsidian does this in most excellent, polished way…
Nope, that’s not the same, that’s true.
But I’ve believed all the time, it comes all together. 
– Everything one could only dream about Tags.
Thank you guys for this project! I’ve changed a lot of apps before I found yours. You well mentioned plugins in other apps, and difficluties with anytype in the beginning of usage. But anytype has these benefits with different objects and capabilities to connect everything with everything. After reading book about PARA method, I configured one of templates for my own needs and now this is the only app I use from the last spring. I see all improvements and appreciate your work! thank you!
