The options for Option relations should be local to each object type

There are some other feature requests that appear to be similar/related (How do I "pre-write" options for relations?, Relation settings right at the type page), but unless I’m mistaken, this is actually a different request.

Most statuses for objects only apply to that particular object. For example, “not started”, “in progress”, and “done” make sense as statuses for a task or assignment, and “watched” and “not watched” make sense as statuses for a movie, but they don’t make sense as statuses for the other object type.

I think certain options for some Option relations like status or tags should be only available locally to each object. Some should still be available globally (such as tags for categorizing what is for “work”, what’s “personal”, etc.), so this should probably be able to be configured by the user for each option for each relation type.

1 Like

Hi @Composer3, thanks for Posting! I think there are similar posts for Tags, but for Status I would say that you could create just another Relation of type Status and give it either the same name (because that is possible, but might be confusing) or a different name to indicate what Object Type you are using it for.

1 Like

@sambouwer Thanks for your reply!

I would agree, but here’s the issue. The default “status” relation is already applied to all object types that have any sort of status by default - so that would be tasks, books, movies, etc. Mind you, this is the default, comes with Antype out-of-the-box status relation. Meaning if I set values for that status (the one that’s automatically applied by default to many unrelated objects) for one object, those options get added to the list for all the other objects for which it’s included by default, even though the same values don’t make sense.

For a concrete example:

  1. I create a book
  2. I set the book’s status relation (the one that is automatically applied upon creation) to “Not Read”
  3. I create a movie
  4. I set the movie’s status relation (the same one that is on the book object) to “Not Watched”

Now for all of the status relations on all objects (including all books, all movies, and all other objects that the status relation is included on by default), I have both the options “Not Read” and “Not Watched”, even though there are no objects for which having both of these objects together makes any sense whatsoever.

So I guess my question is, if the solution to this issue is to create a separate “status” relation for each individual object, and the main “status” relation is not meant to be used for different types of objects, then why is the main “status” relation added by default to every object that has a status? For that matter, if you’re not supposed to use it in this way, how are you supposed to use it? Does it even serve a purpose at all?

I hope that makes it more clear.

Am I missing something about the purpose of the main Status relation?


1 Like

@Composer3 thanks for the additional explanation, and I very much agree with the main point you make about a single default Status relation to be present in many Object Types out of the box.

I don’t think you are missing the point. The design of this part of the Anytype setup might not be as thought through as you’d hoped or expected.

I think this might be a good point go be captured by @Charlotte as this in my opinion ties in with the decluttering project AND how Anytype can be used out of the box.

@Composer3 thanks again for reporting this as this brings the team closer to a better product!


Hey! Thanks for the input here, definitely agree with your sentiments and that being able to define relations as ‘global’ versus ‘local’ is key to using them more effectively. It is one of many improvements that the relations-refactoring project from last year has enabled.

To give you a bit of visibility on how we see this progressing: after this release we will introduce a redesign of the main library pages to make it lighter and more intuitive (looking at 2-3 release cycles from here). The following step would be to redesign the individual ‘relation page’ interface to permit global/local settings & tuning of relation values (think currencies, units of time, distances, etc).

This last step is quite a project in itself and we won’t be able to manage it before the public launch, but hope to bring it in the roadmap after we’ve pushed out the main projects planned for the first half of this year. For now, please continue to tag any feedback related to relation management so we can think how to integrate this in future designs. Thanks!