Collections 2.0 Architecture—changing how we use types

[kaye]

Here we will outline three architectural changes to how Anytype handles types, queries, collections, and tags. Previously, this was known as Lists 2.0 but we have renamed it to Collections 2.0 for now. Everything is currently just a proposal, nothing is set. The purpose of this post is to ask for community feedback and to prototype a great solution.

For a video explainer of this post, check out the Collections 2.0 recording—18 mins, starting at 32:15.

If you’d like to see an outline of the features part of Collections 2.0, please see this post.

If you’d like to see the discussions surrounding the name choices, please see here and here.

---

1—Converging Collections

The challenge today in Anytype

Every object has a type. To bring them into groups outside of their type, you must use a query (rules-based curation) or a collection (manual curation). Every object has a primary set of ‘type properties’. Additionally, secondary ‘local properties’ are bestowed upon it from queries and collection, but these are not easily viewable and treated differently from type properties.

A common way Anytype is used by the community is to put a ‘tag’ property on all their object types, and then a query is created to organise specific tags into a group. In some cases, only the ‘page’ object type is used, and queries are used on the type properties of ‘page’.

Questions:

• Why must an object have only one type?

• Is this representative of how we see the world?

Every item belongs in collections

In reality, nothing in life is viewed in isolation. It is through the context of an object that we can fully derive its meaning. Objects in life also have multiple contexts that they can show up in, which impacts how we see them.

Person Example: You belong to your nuclear family with a partner and kids—you are a parent here. You belong to your family of origin with mum, dad, and siblings—you are a child here. You belong to your friend group—you are a peer here. You belong to your work group—you are a colleague here.

The context changes how you’re viewed in those settings, even though you are literally the same person.

Book Example: A book in a library with other books, it’s part of a ‘book collection’. A book on a shelf with other art, it’s part of a ‘decor collection’. A book in an office with other work portfolio items, it’s part of a ‘case study collection’.

The context changes the book, yet the book itself remained the same.

Every item is the same in its core, but it naturally assumes different properties based on the context that it is in. Just like all the different sides of you as a person are equally all you, they just show up at different times depending on the context you’re in. Importantly, no one piece of context is inherently more important than another.

Collections must adapt to serve context

Context is great, but how does an object adapt with its context and show up together in a helpful way?

Tech News Article Example:

Automatic Context: you are sent a weekly roundup of news articles in the tech world. The inherent nature and properties of this article enables its context to be automatically generated by the system that surrounds it—a weekly tech news collection, properties of ‘news’, ‘tech topic’, and ‘within week release date’.

Conscious Context: you want to keep the same tech news article, but you also associate it with a cat clothing picture and a painting company. There is no inherent context from each of these items that can connect them, no automatic context can be generated. But in your mind they are related to a story you’re developing, thus you are connecting them together through conscious context—a story research collection.

Focus on the relationships

Types, Queries, Collections, and Tags are not intuitive to many people. ‘Should I make a new type, or do I use a tag with a query, or do I just throw it in a collection?’ By having one mental model, we can simplify our focus on one thing: ‘what is the relationship that connects them?’

The proposal implementation

TLDR:

Objects can be part of multiple types/collections, which means that they can have multiple property headers that switch depending on context. This has an effect of bringing types/collections closer towards how tags are used.

• Types + Collections (merged) = Collections
• Queries (renamed) = Smart Collections
• Tags (multiple methods) = Tag Property or Collections

Types still exist. No current functionality is lost with this new proposal, however this would mean changes to the user experience—which is the main challenging aspect to resolve. It’s a question of, ‘how do we make these additional benefits worth it’?

Current ‘Types’ and ‘Collections’ become merged as Collections

Today, what’s the difference between assigning a type to an object and assigning it to a collection? Both require your manual decision making. Both inherit the context of other objects in those groups.

Based on the current system, a functional difference is that collections can have objects from different types, because objects can only have one type. However, if all objects can have multiple types, they are inherently part of multiple types/collections. Thus, multiple types per object effectively merged types and collections to be the same thing.

Current ‘Queries’ becomes Smart Collections

Same functionality today, with the exception that the Smart Collections are also Collections in themselves, meaning their properties will be applied like a Type/Collection (it can display in the object’s properties header). Queries today only apply local properties, not easily visible. If there are no additional properties in the ‘Smart Collection’, potentially it may not show up as an additional property header tab option.

Current ‘Tags’ can still be used, however it feels duplicative with Collections.

Today, tags as a global property shared across types is used to manually connect objects horizontally across a space. It’s what enables an object to show up in a type and across multiple queries. However, if all objects can be in multiple ‘types/collections’, they are also connected horizontally. In this case, ‘collections’ effectively serves as a ‘tag’—making it somewhat redundant. That is, one can view the current ‘types’ as ‘tags’. Or it can be viewed as ‘tags’ with properties.

User flow is based on one mental model: what is the relationship?

To create new items

• Create item, defaults to unsorted, add to collections

• Go to collection, add item, automatically part of collection

To create new collection

• Add properties preset

• Add properties manually

To curate existing items

• Add search criteria

• Add item manually

UX Challenges

• Potential proliferation of collections, making it noisy and difficult to navigate.

• Items need to have a primary collection that serves as a default view of the object, such as in search.

• When deleting an item, if it’s part of multiple collections, it’ll only be removed from that collection and can still exist across the space.

• Making this new architecture backwards compatible with current spaces.

---

2—Tiered Properties

When there are many collections and properties in the space, the challenge of search and navigation grows. This often leads to collections sharing properties when they shouldn’t, very noisy auto-complete options when inputting properties, and simple property naming challenges—such as multiple ‘category’ properties.

• Global Properties: can be used on all collections in the space. Great for creating relationships between items horizontally across multiple collections.

• Collection Properties: can only be used in the collection itself. Great for minimising noise across the space and misuse of properties from collaborators.

• It’s a question of which should be default.

---

3—Cross-Space Collections

Spaces are intentionally isolated from each other on a technical level. However, at many times the mental models we have with spaces are connected—such as in teams. This is especially the case when you need to share properties, templates, and other setups across spaces.

Sharing collections, properties, views, and templates across spaces can help to lower inconsistency and improve workflows.

[Boodybon]

Anytype is the Apple of the note taking industry

Cant wait to see what you’ll come up with

[raph]

Everything outlined sounds great. This will make Anytype much more accessible to newcomers, and easier to managers to old timers.

One thing I particularly like about this model is we get the same thing as currently, but simplified and with more flexibility. For example, if you’re an old timer and you’re used to types, an easy way of re-creating types is to create a “Type” global property, and for every new object setting one multiple types (book, human, document, etc). But if you’re a newcomer coming from Notion (and you probably organize everything in Collections/Databases), you’ll simply create objects directly from within Collections and never bother with global properties.

@kaye

User flow is based on one mental model: what is the relationship?

To create new items

• Create item, defaults to unsorted, add to collections
• Go to collection, add item, automatically part of collection

The only thing I’ll add is another way of creating new items:

• Create item, set value for global property, automatically part of smart collections that curate objects with this global property’s value

[Arif]

Finally! This is the deep dive we’ve been waiting for

The shift from rigid Types to these flexible Collections is a massive move. It actually feels like the architecture is starting to match how our brains work that ‘Person’ example you gave (being a parent, child, and colleague at the same time) really made it click for me.

Also, turning Queries into Smart Collections makes total sense to keep things simple ,really appreciate the transparency on the roadmap @kaye, it’s great to see the long term vision laid out so clearly

[lassee]

I like Smart Collections and how Collections can be more intuitive, but not having types doesn’t makes sense to me… Or maybe I’ve misunderstood?
I’m the examples with books and people, Types is what makes it possible to even talk about the examples. Without the types Person and Book we don’t know what is what. You can’t have a book as your sibling, and putting people on the shelf of a library doesn’t make sense.
Creating a new instance of a type is easy, and it helps a lot with structuring research, reminding me of what fields are important. And it’s easy to make it look good!
But again, I might be missing something.

[ferdzso]

Town Hall - 2026 Feb.0021920×1080 128 KB

What I do not understand is why Types are being left out. In this case, I assume Film represents a specific film, meaning this object could just as well have the type Film and then be collected into Collections.

I feel that Type and Collection represent two different but equally important concepts for organizing.

If Types were kept intact, this example could also be achieved by having a single Type that is used for everything. Keeping Types would still provide more options for organizing.

I might be misunderstanding this, but then it feels like a regression given the naming improvements over the past year or so that have helped with onboarding experience.

Edit: Just as an example for my confusion here, Lord of the Rings is a Film type (which distinction we would lose) and it belongs to the Movies, Party Activities and To Watch Collections. A Lord of the Rings themed Monopoly could also broadly fit those Collections, with To Watch being an outlier. At a glance, to distinguish between the film and the board game, I would need to sift through all the collections it belongs to instead of having a top level Type that clearly indicates what it is as a base concept

Maybe the way I am looking at Collections is closer to Tags as an object (which is also part of the design). Thinking it through from my perspective, ditching Collections in favor of naming them (smart) Tags might be a cleaner for my understanding (which would then contradict my concern over clear naming :D)

[dzlg]

There’s so much information here that I have to read it again and again to fully grasp the idea! However, a couple of ideas caught my mind.

I’ve been long waiting for upgrades coming to Collections and queries, including formulas, rollup, etc. but more than anything, I wanted to see a concept like multi-dimensional relations which I explained in detail a while back:

Multi-dimensional Relations

Ever since the introduction of “relations as objects” and also “inline sets” into Anytype, I was toying with the idea of incorporating more and more aspects of my life into Anytype but in doing so as I mentioned in my other posts, I felt some limitations and lack of features can get in the way of that. Browsing through the community, I came across some interesting and brilliant ideas (multi-type and inheritance) of what could be the next step for the “object, relations, sets” philosophy of Anyty…

@kaye When I heard you talk about “Collection specific” properties, I thought that’s an interesting way to achieve what I had in mind back then, albeit it would require more work on my side. For instance, I gave two examples there in my original post. The point is that we DON’T WANT duplicates. So, I was talking about Habit tracking, Work out, and my Movie Database as an example.

I proposed a way to have a system of habit tracking using multi-dimensional properties. Imagine you want to log what you’ve done in a week, or month across various aspects of your life. Then, you need to have an object like January 1st. Then, you could add properties to it such as work out, reading, etc. of the type “Check Box” and put it there. However, it’s so limited. Imagine you want to see which workout you’ve done but you can’t. Or, the other way around. You want to see which days you’ve done your push-ups. What I proposed back then was to add another dimension to properties of the type Object, in specific, you can tag other properties to it. For instance, you can choose “push-up” for that day, but add the ‘number of reps’ and ‘number of sets’ too. Or, you’ve read for the day, but you want to see which book you’ve read, or how many pages. The point is “that book” or “push up” is yet another object in your space which is at your disposal and it would be great to '“anchor” additional “object-specific” relations to it such as a number. I have to say, it could’ve been done to some extent if we could create queries and collection from the date objects, but as of right now, it’s not possible.

Another example was Movies. Again, you’ve seen my movie database: The Power of Anytype . Imagine, you have a property called “award” which you can keep track of the awards that movie has gotten. But then, you could add another dimension to it such as “what was the award" like “best actor” or which year, etc. Again, you could achieve this if you had multi-dimensional properties.

Now, with this idea that you’ve mentioned yesterday, I think they could be achieved in another way. Like, you can create a collection of 2026 Oscars and have specific award for best actor, best picture assign to different people and movies. This way, you wouldn’t get cluttered and bothered to create separate relations such as “2026 best picture”, “2024 best actress”. You just hook two of them, “best actor” and “2025 Oscars” in that collection.

I have to say, I think it would be achieved but it would need more time and effort from the user side to pull it off compared to the “Multi-Dimensional” properties that I put forward. I wanted to add this here so that maybe you guys take into consideration for the upcoming Collections 2.0. @anton @kaye

Once again, masterful presentation Kaye and I’m so excited for the future of Anytype.

[Obsidian]

I hope AnyType is not getting rid of Types entirely

[Mizoik]

So as far as I understand you are proposing that instead of creating a type “character” and a type “location” with their own properties, and then creating a collection for “heroes”, “villains" that will store the hero vilian characters + the location of their bases. We instead make a type for character, that has some properties then we create a type for hero for vilian, then create a type for location. And then create an Object with type character+vilian or character+hero, or location+vilian, location+hero which is really what you are proposing are procedural types that can layer or stack on one another if you will. How are templates going to work for this multi type, templates must then also be multi typed and not tied to the types. And the types would then be nice to sort in some hierarchy like character type, main character type, side character type, location type, sub location type for like different things so you can organise it. Types will be lists of properties you can stack on an object = putting a thing into a collection. And about collection I have to say make it one and just call it collection with an option to add any other object manually as an exception so that It works as a query as a base but you can just bring in any existing object that will be in the collection ignoring the filters as an exception you want to manually collect, to be honest I don’t really use collections myself but I can see how some people might find them useful, I just prefer properties for this more automatic sorting.

[Mizoik]

Or if like I have a task type for all my tasks and it has a property task type for like writing text, filming a video, doing research.instead of having this tag - I’d have different subtypes of tasks that would add relevant properties for like writing text for example number of pages or related object for text, for filming a video that subtype would add video format options for properties, for research some other detail properties for research and so on.

[Code-Jack]

@lassee I try to explain it how I understand the thing:
Let’s assume you have two Collections:

1. Books
2. Family

On the first glance, there is nothing special. You put all your books into the “Books” Collection.
Each book Object is from the same type and has therefore the same header with all the needed Properties.

And All you family members are from Type “Human”.
If you put your family members into the Collection “Family”, they all have the same appearence, the same object header.

But now the thing:
Let’s assume, you have a book with the title “How To Make Your Family Happy”.
– On first glance, it’s a book and belongs therefore into the “Books” Collection.
– But on the second glance, it has much to do with “family”, therefore it would also make sense to put it also into the “Family” Collection.

That was always possible, of course.
But if this new book now is in the “Family” Collection, it will be the only item there, that has a different type and object header then alle the “Human” type Objects.

The idea is (as I understand it), that the book can have a different header if it appears in a Collection that was intended for a different object Type.
– Let it sink in for a moment …
(I must admit, that also my brain smokes.)

.

The new concept sees headers different from the past.
The whole header can be seen as one big and complex “property”, quasi like a Tag.
– A very complex Tag of course, that has multiple other Properties.
But not all of these Properties are necessary or wanted in a completely other context.

Maybe the example with the books was not the best.
I have another example that’s from my own experience:

I was running a one-man company.
Therefore I have customers and I have vendors. Both are humans. But they differ.
And I have a cousin. He’s my family member. But sometimes he’s also my customer. AND he also runs his own business and sometimes I buy items from him – in this case he’s my vendor.

How on earth to deal with that?
Yeah, we have Types and we have Templates. But what Type and what Template to chose for my cousin? He belongs into three different categories, depending from the context.
In the moment when I scroll through my vendors, I don’t need (and don’t want) so see who his father is.
And when I scroll through my family members, then I’m not interested to see some strictly business related Properties.
A flexible Object header could be a solution. What it shows depends from the context.

This can indeed be important if you think about printing an Object.
If you need to print all Objects inside of a “Vendors” Collection, you want to see them all with identical headers.
Yo don’t want to visit all them manually and maybe change the Template for some Objects to let them all look identically. You simply want to print all items in a Collection and everything should look as expected.
For a list of vendors it’s not wanted to see who’s his father and who’s his child; not in this context.

[sturdily]

I personally love the proposed architecture. It is very similar to Tana SuperTags or Logseq DB NewTags, but with proper and correct taxonomy! (If I understood it correctly). These systems work very well (in my opinion, the best of current PKM systems).

Congrats to the team!

@kaye

Potential proliferation of collections, making it noisy and difficult to navigate.

It is the same issue with those systems mentioned above, it requires some discipline from the user, and flexibility from the UX.

@kaye

Items need to have a primary collection that serves as a default view of the object, such as in search.

Anytype could use a system, like current Type properties, with “Featured” collections, which will be default view and visible under search.

@kaye

When deleting an item, if it’s part of multiple collections, it’ll only be removed from that collection and can still exist across the space.

Hum… this issue already exists, I guess a good clear named option (move item to bin vs remove from this collection)

@kaye

• Making this new architecture backwards compatible with current spaces.

We will be here to help out and test any issue before deploying to “Stable version users”

As a personaly request and clarification, can you say that properties on a collection, will only be collection scope, or if Collections can be mixed and have global and collection property scopes?

Thank you, great work on the presentation, and great work for all Anytype team on the great vision.

[Shampra]

I love the general idea, and it’s ambitious!
But I’m waiting to see how it will translate into functionality, interface, and usability, which is often the tricky part of high-level concepts.
It needs to remain simple and quick to use… Good luck!
If you succeed, it’s really promising and will solve a lot of current problems.

Before the meeting, I planned to bring up one point.
For me, the major difference between query and collection is the link. A query does not necessarily add a link to the objects displayed, unlike a collection.
And the way the library works follows from this:

• Do we want a strong link? Add a link and the resulting functionality for the library: recursive deletion possible, folder and tree view, “who is in” search.
• Do we just want to display objects without actually linking them? We don’t overload the link properties and the above functionality does not apply.

As I don’t read English fluently enough, I need to find the time to sit down and read the post and the replies in detail. Perhaps this has already been mentioned ;-).

[Darifar]

Dear @kaye ,

Thank you and congratulations on the conceptual heavy-lifting within the team as well as on the inclusive brainstorming approach with the community here, this is really appreciated.

Going straight to the point: I have substantial concerns about the new proposal.

My perspective is that of a scholar in Information Systems, a field in which we routinely deal with informational architecture challenges.

The main issue to me is that we are mixing up different ontologies together:

• What an object is in itself, or “substance” (say, a book)
• The defining features this object can take
  • In itself (book release year)
  • In relationship to other objects (book written by…, owned by…)
• How this object can be grouped/understood in a broader context/environment (say, My library, All objects discussing Topic “Artificial intelligence”, etc.)

These are ontologically different things:

• What an object is: This is Type in AnyType today
• Object defining features (relational or not): These are Properties and Tags
• Object grouping: These are Collections and Queries

The approach to simplify and streamline AnyType’s universe is absolutely right, but in my opinion it should be done like this:

• Types remain as a fundamental and intuitive way of making sense of the world, as underlined by @ferdzso . Case in point: The examples you give @kaye keep referring to them, as @lassee pointed it out.
• Tags and Properties become one and the same thing (Tags are already Properties today, it is mostly about reducing semantic complexity for users)
• Collections become one type of Query/Set (a “manually curated” query/set or what not). As of today, nothing prevents users from having objects in multiple Queries such as “My movies, “Party activities” and “Watchlist”

Bottom line: the challenge is that people think very differently. While rethinking system design is key so that people thinking relationlly or tree-like first feel at ease, it should not violate basic ontological borders between what philosophers call substances, accidents and relations.

Curious to read your thoughts on this!

[mandem]

I’m still trying to wrap my head around this and (as mentioned already) having to read it again and again. My initial worry is the motivation to simplify the mental model will reduce the flexibility of organizing our objects.

I really don’t understand the merging of Types & Collections. Types are foundational to the objects we track (collect?), so my brain just thinks “collection of collections” at the idea of merging them. I’ve always felt Collections (as the docs say “work more like a traditional database”) are an important bridge to understanding how our objects actually connect in life. Maybe it’s just how my specific brain works, but sometimes I just need to throw a bunch of random objects in a box and move them out of the way in order to sort them later. This sort of goes back to my initial worry and the original questions: ‘Should I make a new type, or do I use a tag with a query, or do I just throw it in a collection?'… I’d personally like the ability to do all 3 options.

Additionally, I use the Graph a lot to visually grasp the relations & organization of my objects. I often use it to navigate to different areas of my space as well. Perhaps I’ve been looking at things the wrong way (heh), but it’s just how I’ve made sense of things so far.

I still need to catch up and watch the town hall which may give me some clarity, but so far the changes to types is worrisome.

[Darifar]

On the current proposal as it is, two additional remarks if it ends up being implemented this way:

• Collection properties must be convertible to Global properties at all times. If not, the amount of manual work is such that I expect a lot of users dropping out
  • Example: I have “Movie release year” as a Collection property. Later I realise “damn, I want to subset all art works with the same release year, be it movie, painting or book”. The “Movie release year” collection property should be convertible to “Artwork release year” global property and merged with other existing objects. If not… that’s gonna hurt.
• Amazing work has been done on simplifying AnyType terminology, I find that introducing now “Smart collections” along “Collections” is very confusing and counterintuitive. But that’s my subjective two cents of course.

[prizmo]

I love these changes and think they will help me bring others around to understanding Anytype. I’m wondering, why not have “collections” default to automatic collections (smart collections) with a toggle to turn the automatic curation off and do manual curation only?

[Perlsowisdom]

My immediate reaction is nervousness. For instance, I’ve set my People up in such a way the Collections 2.0 update will likely require significant reorganizing of my types/properties, to the point it’d be less work to export to a different system like Tana. Particularly since this is the second massive structural change in a year (the first being the Primitives update). With the API still not allowing editing, trying to redo everything manually is enough of a turn-off that I’d likely give up on Anytype.

Two points of confusion remain for me.

1. How are we specifying the sort of interface the editor will have? Task, bookmark, page, note, and event all have very different interfaces. Is that something we select when creating an object, and how are we grouping those traits.

2. How will properties which contain the same information and are used the same way be handled? If I have the Budwiser Beer object. It could be in the collection grocery list, beer reviews, and Gifts for friends collection. I’d like to add the price property to all three collections. It’d be the same price (ideally the same property) in all three collections. How would that be handled in the object. Am I going to start seeing duplicates of my properties? If not, how will I distinguish what collections its part of.

It seems like collections is just a property of properties. Is there something else I’m missing? If that’s the case, it seems like just making all tags have the ability to group properties too would solve that problem. Overall, this proposal doesn’t feel like it’s simplified anything, it’s just moved the complexity to different areas.

[Perla]

While I generally like this, especially the idea of being able to use multiple headers (this is something I would use heavily, personally) I’m not sure eliminating types is the right move. People organize things broadly and having no highest-level organizer could cause be a regression for some folks, myself included.

I like the idea of objects belong to more than one type? I guess rather than totally doing away with the current system perhaps making it more flexible is more serviceable for everyone.

I also like tags as a higher level navigable item, but when you have thousands of entries, conceptual borders are really important. I have 400 characters in my character database. I have 8 categories of characters just to keep them organized. If I am asked to to view every single “tag” or conceptual border as equal, it will cause decision paralysis. I personally need “these 400 entries belong to the characters type, of which there are 8 sub types” Just looking at 8 groups of 50 character types is not going to help me keep clean data.

I guess my concerns amount to:

1. How is the information “automatically connected” ? What does this mean in practice?
2. Will this make it harder to organize sub information? Clear boundaries between objects make subcategorization easier.
3. Separation of collections and queries. Types work for me as a dumping ground for objects. Collections/queries are a way for me to organize that information and control how it’s displayed. By forcing all organizing rules to exist at the same level, it would lead to a ton of queries. I guess I could manually implement a type query but it would basically just be doing what’s already there but extra work for me.

I think it would be important to add gaurdrails that allow you to

A) toggle a flag that allows you to say “this is a flexible context-first object/category” and “this is an inflexible object/category”

B) toggle a flag (or maybe a new property type) for non primary tags. The idea of every tag creating a collection (maybe I misunderstood?) feels a little unwieldy. Some tags are purely semantic/organizational and not connected to other contexts.

As for a few ideas on how to handle defaults, perhaps for tag the default should be local properties (if the option to change them freely between global and local exists, otherwise global should be the default imo). Mostly because I feel like when you’re setting up new collections people will set up a ton of properties that end up trashed because they realized it’s not what they needed. Having to do massive global clean up for that every time would be a painful UX.

For primary collection perhaps formalizing it? Just have 2 inputs, one that is “primary collection” and then “all other collections, or something to that effect. Would essentially operate as types do now.

Thanks for the deep dive and for the opportunity to provide meaningful feedback!

Just to reiterate, the idea of having multiple headers is very appealing to me, and I can appreciate the