Latest feedback about some significant drawbacks

Here’s the concerns I currently have about Anytype’s developpment, along with a few ideas to solve them.
Please let me know if there are any ambiguous or incomplete aspects about any of it.
The reasons why I specifically mention these points and why I have a real concern about them are explained at the end of the post.

1. Blocks should be Objects:

“Everything is an object” was one of the main Anytype’s motto, and sadly, the scope of it is not fully deployed. For today’s Blocks are still not objects, and it’s a deep drawback as there is no way of linking Relationships to any blocks, nor of indexing them in a Set.
Here’s what it might look like if this feature were integrated:



:loudspeaker: The official and current statement on this subject is:

What is it contest with atm? Please elaborate.

“If I had asked people what they wanted, they would have said faster horses.” said - Henry Ford
I don’t believe in community votes because there’s the unfair “First Mover Advantage” inherent in most voting systems, which only amplifies over time.
Besides the way forums like Discourse are designed, which relegates old topics to oblivion and encourages no one to explore them.
The FRs promoted overshadow the old ones, all the more so when @Angelo lists some of them to encourage the use of votes and therefore influences the votes itself.
For all these reasons voting will never reflect the wishes of the community. The first compass should be a clear, assertive and above all explicitly detailed vision for the community.

I’m not referring to transclusions, I really mean Blocks as Objects. Transclusion is already partially present, but is not yet In-text. Anyway transclusion doesn’t allow you to attach Relations to a Block and then find that block in a Query. Do you see the difference?

2. We should be able to design a hierarchical Inheritance between Objects:

Two possibilities:
A.
Either you add the possibility of Nested Types and Relations, which would allow the entire current system to be used hierarchically, thanks to the concept of Inheritance.
And since all Objects already function in the same way as tags, navigation and organization would be greatly facilitated.
B.
Or add the possibility of creating Nested Tags, enabling Tags Relations to create a whole hierarchy available from a simple Drop-down menu.
I’ll just give an example of Option B that I got from the web:
image

The community has also been working on solutions for over a year now, but nothing seems to have been officially adressed about this topic: A Master Tag System (advice and feature requests) (Tag hierarchy)

3. Notes should have Templates:

Template function isn’t active on Notes, so we cannot add any Header Relations to it, nor pre-formated its content and this limits their use.
And since you haven’t configured the Title blocks as a Featured relations, we can neither add nor remove the Title block from any Type’s templates, so we’re unable to recreate the Note Type from scratch.
Everyone as it’s own way to use notes, so please, let us customize and use it in our own way.
:loudspeaker: The official and current statement on this subject is:

@ignatovv I appreciate the improvement, but that’s really not my point. So I’ve included an example to help you understand the explanation. I look forward to your feedback.


4. Sets should merge with Collection and be able to query different Types and Relations:

Sets are incomplete as they should merged with Collections.
They can live alongside in the same Type. @raph explained very well throughout his many explainations, just how obvious this should be: Merge collections and sets
Here’s what it might look like:

image

This vision unfortunately clashes with the already acquired habits of users, who have rushed to Collections to solve the problem I’m now going to mention.
The second limiting aspect of Sets is quite simply their restriction to a single Query Type/Relation. The possibilities they could open up by overcoming this limitation seem quite obvious, to say the least.
Here’s what it might look like:


5. Anytype should allow us to modify our Recovery phrase:

:loudspeaker: The official and current statement on this subject is:

I’m glad to see that the problem will be solved, I just hope that the 2FA mentioned as a possible approach will avoid SMS or Email 2FA, and will only use TOTP or a similarly secure system.

6. Local data should be linked or relocated instead of being duplicated and integrated.


Our data are accessible offline, and that’s highly appreciated, but the fact that any files is duplicated and then integrated in Anytype’s file system containers means we can’t access the image, video and audio files integrated into Anytype outside of it. This is highly restrictive for many professions and uses.
@qualquertipo sums up the issue and how to solve it:

Besides that, thanks to @Person for pointing out that there will be a way for someone to create a Protobuf viewer to make these text and databases readable outside Anytype.
I just can’t understand this technological choice. It does not (from my point of view) reflect the data sovereignty statement.

Please note that I am not questioning the time it takes for certain features to come to completion, as there are many difficulties and unforeseen events involved. Many of the feature suggested by the community won’t require an overhaul redesign of Anytype’s foundation and therefore have no negative impact on being delayed.
That’s why I’ve only set out the aspects that I consider to be decisively urgent with regard to the risk of reaching a point of no return in the advancement of Anytype. As I’m affraid that the upcoming launch of the API and then v1.0 will have numerous implications, most likely setting the current foundations about theses specific topics in stone (usage habits, data structure, etc.).

Does my concerns about all this are founded? With all due respect, and despite all the efforts you’ve made to communicate with the community over the years of development, you seem to lack a certain clarity or at least reserve detailed objectives for yourself. So that an official statement with an explicit stance on these subjects would be most welcome.

Thank you for your time.

11 Likes

I agree with 1.

I’d also suggest you be a bit more considerate in how you address the team. Nobody owes you anything. Be kind.

14 Likes

Yet I chose my words carefully, as close as possible to my feelings and as far from disrespect. What part are you having problems with?

Far be it from me to think that the Devs owe me anything. Maybe it’s the way I put things into context about how their choices limit my workflow that makes you think that, but I was obliged in some cases, for the sake of clarification, to give examples.

I’d like to know what makes you think that the 4 other points are not important. Would you care to explain your point of view?

2 Likes

I hadn’t thought about it, but it’s true that there must be some kind of technological plateau, I mean, at some point, I imagine that certain changes are too important and can perhaps cause more problems, greatly slow down development or even as evoked disrupt the way members are used to the present features and their layout/functions. So if one of the Devs could tell us which of these functions can still be modified, and in passing give us their arguments as to why they haven’t been prioritized or chosen so far.

1 Like

For me, UX is a key factor, it underpins everything else. And you’ve pointed out some deep-seated problems that should at least be officially addressed.
I hadn’t thought about Notes, but it’s true that we can’t even take advantage of templates to add relations to notes headers, and thus quickly classify notes that we take on the fly.
Finally, from what I understand, this type was created to enable quick, no-frills note-taking, but personally, I use it because it means you don’t have to enter a title, but apart from that, it’s very limited and in fact, impossible to reproduce this function (removing the title) in a page template, and that’s unfortunate.

Besides that, I don’t know to what extent each of the points discussed will be immutably fixed or not, only the Devs can explain that, but overall I agree with each of the points.

Tags should have nested hierarchy:
Without this, they are difficult to identify and select. The community has been working on solutions for over a year now, but nothing has come: A Master Tag System (advice and feature requests) (Tag hierarchy)
Evernote popularized it back in 2008, so either you’re deliberately trying to free yourself from this obvious and structurally essential need, or you don’t mind being 15 years technologically out of date.

This feature is not so important as you imply. The feature request has only 3 votes. It is not essential feature and can be reproduced with sets if it is so important for you.

Sets are useless:
They were a very good idea, but incomplete. You can argue that it was just a matter of time before you could code and integrate the Collection concept, but I sincerely believe that you didn’t foresee this need and that the community’s insistence pushed you to conceive this integration. Except that Collections are a blatant example of an overly narrow or rusher vision.
Why is that? Simply because there should be no distinction between Sets and Collections. There should only be Collections, and these could just as easily integrate different Types/Relationships, as a single one.
Making these two entities cohabit doesn’t make any sense; you’ve complicated the structure for nothing. You’ve responded to a legitimate need in a chaotic way.

This is just false. There are many use cases for sets that are not possible with collections. Actually, I could argue that sets are superset of collections.

Our unreadable data file structure is locked in a big humanly unreadable container file. You should have come up with a format that’s readable without the need for your application, and that lets us navigate through a structure representing our data. Even if the hierarchical approach seems complicated by the nature of Anytype, it’s not impossible. Like Obsidian does with markdown, which doesn’t lock up data locally, but secures it in transit/sync.
Markdown is necessarily limited when it comes to integrating and representing Anytype data, but a solution is possible - you’ve simply chosen not to consider it.
For an application that claims digital sovereignty, it’s more than inappropriate to lock up our data. But since you offer Offline-first, I’ll go along with it, despite my disappointment.

If you want, you can write program that would process the protobuf files. The files are unreadable for humans for a reason - you can not store such objects in markdown.

While you have carefully chosen your words they do come across a bit harsh and demanding (like @qualquertipo said be kind :slight_smile: ), eventhough you have a few solid points of concern.

1. Blocks should be Objects
This is a thing that has been requested and Anytype responded. I don’t remember but I believe they are looking into it (no promises). Also, I disagree that this means blocks as well, but I understand why some people might think so. Or maybe hoped that would include blocks (which I would love and bring Anytype to the next level).

2. Tags should have nested hierarchy
I don’t think they should but having the options would be nice. Also there have been many suggestions about a master tag lis or better handling of tags including nested tags. Which also is something being worked on.

3. Notes should have Templates or be redesigned
I don’t really understand this, why? You can simply use an object type of your own choosing and assign templates to it. That type can be set as the default and you just not use the Notes type.
As I replied in this topic Let users change locked types - #12 by Jeroen I believe that Note is one of the default objects that has more things working in the background (like layouts) and that is why we cannot remove or edit them. This is more a design descission which you can agree with or not.

4. Sets are useless
Strongly disagree! Sets are great and useful to me as well as collections. Even in their current state! I use both a lot! Agreed that they lack some features and require some quality of life updates but both have their place in my workflow at least. Sets where the number 1 request more then a year ago before they got added.

Edit: I just red this post:

5. Inability to change our Recovery phrase
Strongly agree! But this is already in the works see this awnser in Learning more about Security Phrases - #3 by AnyChris

I feel a lot of your points are valid but almost all of them are still being worked on or improved in some way. So my advise would be to have some more patience and don’t use Anytype as your daily driver. Stick with Evernote, Obsidian or another app that does suits your needs better. You would be supprised how fast development goes when you are not focussed on it.

8 Likes

I believe #2 and #5 were acknowledged already. In the last Town Hall, one of the founders said something about acknowledging that relations still need improvement. And I read about #5 (recovery phrase) here in the Community. They are discussing possible solutions for changing the phrase when it is compromised. These things can take time, you’ve said it yourself.

#4 While I agree that sets and collections could use some improvement, I wouldn’t go as far as calling it useless. Just because you’re not satisfied with it doesn’t mean it’s useless to everyone else. But I can understand the frustration of wanting something fixed so badly. Have you written a Feature Request on your ideas on how it could work as one object type?

I am having difficulty understanding #3. Besides the title block that you seem to want to get rid of, I can’t see how pages or other custom types can’t be a solution for this…?

And iirc, they are also cooking some improvements on templates.

Lastly, I think you come off as a bit mean because you sound like it’s a shame for them to not foresee the demands of the community. I can’t speak for the team, but my understanding is that unless they marked a topic as “improbable”, then it’s still up for discussion and improvements. You can be more active here, submit and comment on FRs to strengthen the case of the ones that mean a lot to you. :slightly_smiling_face:

5 Likes

I am still hopeful. Considering last big update is about self-host and panes, it is reasonable structure of content isn’t refined as much.

  1. Relation as object’ is in progress. It should be even more efforts needed to make relation as object to work, compared to block reference/embed features that already exist in other open source software e.g. Obsidian or Roam research. I wouldn’t say the team has ignored this concept.

  2. I never understand tags so let me skip this. See my attempted understanding

  3. To me, note is the what one would use for quick change to have block as object. Nothing much is needed. But I wouldn’t mind if the function of pre-seting note object is enhanced. Technically speaking, I suppose it can be easily done with re-using codes from richer object type…

  4. The confusion is real but I lean towards using sets though, not collection…

  5. It make sense that passwords need to be changeable to feel safe and I do want to manage risky situations… But I would imagine recovery phrase is account identification as well as password and encryption key, so changing all of these at the same time? I would be worried if we hurried this function out, we have the risk of losing everything…:thinking:?

✦ I thought most of us come to Anytype for encryption… markdown and raw data, really? If I were you, I would probably just go for Obsidian, everything more mature. But Anytype is Anytype - a small team taking on big challenges :woman_climbing:. And since we are here on the Anytype forums, let’s make contributions.

In short, there must be negotiation between functions, since our desires are limitless and yet we live in scarcity and limited resources. Speed and functions; innovation and traditional understanding; safety and accessibility etc.

Claiming Anytype to be out of date can be a big accusation, when it is in development. The team is meeting us almost every month, responding to feature requests and bug reports. Looks to me they are listening. We, the community, also have divided views - so we vote and discuss. And the team try to figure out something with us.


Perhaps you have waited longer than you expect. Perhaps you have different mindset to the team. It is OK… tell us more about your process from hope to despair. So as a community (not just fellow users, Anytype team as well), we could support each other through the frustration and worries, it would be way more constructive :wink:

11 Likes

As a user who hasn’t grasped the concept of Everything is an object, would you mind explaining to me what implications that holds for Anytype? Particularly, how could or should that concept be incorporated into Anytype, considering it is a block-based app and not an outliner? (I’ve come across discussions about Tana and RemNote related to this.)

There’s a post discussing the concept of Everything is a… block, but the conversation mainly revolves around Anytype’s terminology.

Maybe OP is talking about transclusion? Transclusion

A block is just a part of an object. A paragraph, a heading, etc. It is not an object in itself and cannot be linked, nor referenced, nor related to/from.

2 Likes

Hi @Logic thanks a lot for your feedback :pray: Also thanks everyone participated for your kindness and care, you are great community to be a part of :face_holding_back_tears: A lot of things were already highlighted so I would love to add a bit new info.

  1. Blocks should be Objects:
    We are aware about this one but we are not sure it 100% matches with what we want Anytype to be eventually. As well this feature do not stand the contest with other things we are doing atm. Too much effort and we have more urgent problems to solve. But eventually we would love to introduce this in some form.
    We also have a feature request with mere 20 upvotes. So hopefully if community in interested to escalate this feature just upvote it. Also it will be nice to sparkle a fresh discussion in this thread for everyone interested to participate.
    Everything is a... Block?
    Also some things may be solved by transclusion like mentioned previously
  2. Sets are way to limited:
    Thanks for highlighting it once again. I will try to push some changes on this regard.
  3. Notes should have Templates:
    We are going to evolve notes experience with new quick capture mechanism and inbox widget for you to save info on the go and triage it later. I want to share design concepts here to show the fact we are aware of all the things mentioned. (designs are subject to change)
7 Likes

Your experience is crucial. I am a bit curious about your thought on this.

  1. What makes you think it will be irreversible?
  2. What features you want wouldn’t work if they are not implemented properly?
  3. What other features will need a solid ground of the above 6 things to work?

A solid foundation is certainly important, or we and Anytype will need to have a revolution to get back on track :sweat_smile::joy:. Let’s establish a framework to avoid this :wink:

1 Like

:star_struck:
@ignatovv This looks really promising. If it looked like that, I would already be satisfied. :smiley:

1 Like

Thanks for all your feedback, they are way more constructive than my initially published criticisms which were indeed too harsh and not contributive enough.

I’ve made numerous corrections and I hope the accompanying visual examples will clarify many aspects. :arrow_up:

My apologies.

Most people aren’t aware of the possibilities until they’re presented in a concrete way.
“If I had asked people what they wanted, they would have said faster horses.” said - Henry Ford
I don’t believe in community votes because there’s the unfair “First Mover Advantage” inherent in most voting systems, which only amplifies over time.
Besides the way forums like Discourse are designed, which relegates old topics to oblivion and encourages no one to explore them.
The FRs promoted overshadow the old ones, all the more so when @Angelo lists some of them to encourage the use of votes and therefore influences the votes itself.
For all these reasons voting will never reflect the wishes of the community. The first compass should be a clear, assertive and above all explicitly detailed vision for the community.

I’d like to point out that the reference to “essentiality” is attributable to the fear mentioned at the end of the post.
I’d be curious to see the concrete use of a Nested tags Set that you mention. Has anyone demonstrated this yet?

You’re right, I didn’t word that very well. I’ve corrected that part and think I’ve explained it much better, please tell me if there’s any ambiguity in my corrections.

Any official statement on this? Could you please link the source?

Apparently I misspoke as I don’t want to get rid of the Title Block, I want it to be fully integrated as an element that can be manipulated at will.
I’ve corrected that part and think I’ve explained it much better, please tell me if there’s any ambiguity in my corrections.

I also think that most default Types are essential to the basic structure, but they’re also used as a demonstration for new users. That makes sense as we’re not going to welcome them with a blank canva and teach them how to create Types and Relations from scratch right from the start :smiley:
Nonetheless, I persist, because in my opinion, the Type Note is either incomplete for the reasons mentioned above, or it should be integrated into the pages as a Template. Its differentiation lies only in features removed from Page Type, which further reveals the fact that it’s not necessary by default.
But I’d like to make it clear that I’m not against the idea of using a Type Notes, and I’d have a LOT of use for it myself, but as it stands it’s too limited.

Then there’s also the impossibility of renaming default Types, which poses a problem. The “Human” Type for example has real utility, but we should be able to rename it. I personnaly have to recreate a Type and name it “Contact”, then fill it with different templates, but I’ll constantly be confronted with this default Type that I can’t hide by sending it back to the Library, and that’s frustrating. If I need to add a Company template, it doesn’t belong in a Type named human. Imposing an organization is never wise, and I don’t think I’m the only one who doesn’t want to organize my contacts under the Human label.
But I hadn’t mentioned this problem because it doesn’t seem structurally urgent to me. I think it can be corrected without turning everything upside down, unlike the Notes.

I don’t understand what you’re referring to because Relations already are Objects. For my part, I was referring to the Blocks as Objects.
I’ve corrected that part in my post and think I’ve explained it much better with visual exemple.

The three uses you have mentioned should not be in opposition to each other, and should be able to be used in conjunction with each other as a structure should be able to adapt to many different needs.
And as you mentioned, in reality, every Object and Relations in Anytype already functions as a tag, their use is simpley limited by the restrictions that come with them and in which these Objects evolve.
The Tag relation therefore seem redundant (and in a way it is), but if Types/Relations could be hierarchized by Sub-Types and Sub-Relations, this would already allow us to structure these Relations with each other and use them as hierarchical Tags.

And since you asked for an example of how to use Tags, here’s one you can intereact with:

  • Who
    • People
      • Bill Gates
      • Steve Jobs
      • Etc…
    • Company
      • Microsoft
      • Apple
      • Etc…
    • Contact
      • My John Doe friend
      • My Jane Doe friend
      • Etc…
    • Myself

  • What
    • Film
      • Scripts
      • Softwares
    • Music
      • Music sheet
      • Softwares
    • Personnal work
      • Training

      • Published
        • Records
        • Podcasts
        • Audio-book
  • When
    • Year
      • 1999
      • 2000
      • Etc…
    • Month
      • January
      • Febuary
      • Etc…
    • Day number
      • 1
      • 2
      • Etc…
    • Week day
      • Monday
      • Thuesday
      • Etc…
  • Where
    • Country
      • Germany
      • Spain
      • Etc…
    • City
      • Berlin
      • Madrid
      • Etc…
    • Favorite place

With this tags structure you could:
  • Link Steve Jobs to Apple or any other tag, so if you’d displayed Apple tag, you’d see Steve Jobs Tag and vice versa.
  • If you only want to see everything referring to the year 2000, just select this tag in a search/set.
  • Time-related tags would be created automatically when creating each object, but could also be added manually or semi-automatically for historical events you’d like to refer to. By entering the date in a calendar, each tag would then be automatically created.
  • I’ve deliberately placed a tag with the identical name “Softwares” and in this situation, if you enter Software in a tag search, you’ll get a display of the closest relatives of each of these tags so you know which one you want to refer to and therefore add.
  • If you remember that a tag exists for your subject, but you can’t remember its name, you can simply browse the tag structure and find it in just a few clicks!
  • Create an infinite sub-level tags who are all connected to their relatives Tags.

Nothing makes selection as quick and easy as a Dropdown menu. Multiple levels of inter-relations and sub-Objects could replace Tags to me, but the way to create and display them must be simple and clear. One of the primary functions of tags is to enable quick reference, retrieval and indexing.

Imagine the possibility of affiliating Relations to Blocks in a reading log, tagging different sentences for example. This would then allow you to refer to them in a Set, and not be limited to having to constantly create a Type for each sentence you need to affiliate Relations to. As for how this could be incorporated, I’ve added a visual example in my corrections :arrow_up:

For example, a side icon could be used to show/hide Relations linked to Blocks, or some other subtle visual effect to quickly identify Blocks with linked Relations.
Ideally, I’d even go so far as to design Highlights as objects, so as not to have to create a new block every time, but blocks would be useful enough to most people.

Not really, I invite you to read the first post again, because I’ve explained it in detail.

Not really. There have been a lot of rumors, but few official statements.

If I recall correctly, the Anytype Agenda is:
1st phase: A Personnal knowledge management.
2nd phase: A web browser.
3rd and last phase: An OS.
What is it contest with atm? Please elaborate.

“If I had asked people what they wanted, they would have said faster horses.” said - Henry Ford
I don’t believe in community votes because there’s the unfair “First Mover Advantage” inherent in most voting systems, which only amplifies over time.
Besides the way forums like Discourse are designed, which relegates old topics to oblivion and encourages no one to explore them.
The FRs promoted overshadow the old ones, all the more so when @Angelo lists some of them to encourage the use of votes and therefore influences the votes itself.
For all these reasons voting will never reflect the wishes of the community. The first compass should be a clear, assertive and above all explicitly detailed vision for the community.

I’m not referring to transclusions, I really mean Blocks as Objects. Transclusion is already partially present, but is not yet In-text. Anyway transclusion doesn’t allow you to attach Relations to a Block and then find that block in a Query. Do you see the difference?

  1. Because I’ve seen the rise and fall of too many apps. Although I have no programming skills whatsoever, it seems to me that I’ve got a pretty good grasp of what’s at stake about this critical consolidation stage, but I’d be grateful to have the feedback of real developers to tell me whether my perception is wrong or not.
  • Software pre-releases that are exclusively used as early adoption rather than for testing, thereby risking to lose all of their data.
  • The adoption of habits concerning certain features that will be hard to get rid of in case of late deep changes.
  • And features that have so many connections and dependencies that, in the need of structural change, it would imply too much time and audacity to rework on, for some.
  1. All of them. Unfortunately, to my knowledge, there are no workadound.
  2. If by solid ground you mean an overhaul foundation redesign, then the 1st 2nd 5th and 6th will probably the most challenging.
4 Likes

Yes, I’ve read your edited post. It is much clearer now. :+1:t2: Is there an existing FR for that Title Block as Favorite Relation idea? It’s actually a good one and I can imagine using that myself. At present, I am using Collections for notes because I switch between the note and the page layout.

You’ve written some very good points. I encourage you to comment or link/quote this post to relevant FRs so the devs won’t lose track of your suggestions!

I understand your concern about things being too late to make changes, but keep in mind we’re still in beta. As testers, I believe a part of that means we agree to adjust should some form of change happen. If there’s a thing or two that I learned since they launched open beta, it’s:

  1. The team will provide assistance if the users are forced to adapt. (Alpha to Beta migration)
  2. They are willing to rewrite code and do things the hard way if it means it will solve a major problem in the app. (As they did with AnySync. Thank goodness that was fixed! :grin:)

So I have high hopes that more improvements will come, and that these developments will stay ‘community-based’. :blush:

1 Like

:wave:t3: Hi @Logic

:repeat: Revision

I read the original version of the post. It was not so much about the quality of the proposals, but only about the wording, which left me with an uneasy feeling. Thanks for the revision of your post, it is much more understandable now. :+1:t3: :pray:t3:

:person_raising_hand:t3: Representativeness

This is somewhat true. There are several effects, such as the series position effect, etc. and biases that will affect the result. Since there are 100+ FRs (huge backlog) they need to prioritise (apart from their own schedule: Multiplayer etc.) to focus on the ones that the community (who voted) wants right now.
But this does not automatically mean that FRs with fewer votes will not be implemented. They will simply be implemented later, when the focus of the community shifts to them.

:memo: The note type

Interesting thought. I think you just wanted to create a separate object type for quick capture. This should/needed thus not at all the whole functionality of a page, since this would be obstructive. :thinking:

:link: Please link/quote

@Kerstie good advice! I link most of my posts to the FRs so that everything in the community is better connected since there are so many posts.

:interrobang: The other topics

I can’t comment on the other topics like sets/collections, tags, block, etc. because I haven’t dealt with that much yet.

I agree that look really nice and I especially like how you have display all contents within that ‘block object’.

See FR treat relation as objects.

Perhaps we can understand if something is block and object in different ways, bringing all functions to relation, block and object

Relation Block Object
Ability to reference else where of its contents in original state ✕ e.g. content for lyrics relation of a song object cannot be reused in journal object, aka not connection point
Applicability of the structure else where ✓ relation type can be applied to multiple objects ✕ no structure; but should block contain format e.g. callout or inline template? ✓ as template
Whether it can contain attributes or relations ✕ e.g. Currency of Price ✕ enables block tagging in the relation way
Appearance / Location of relation ◐ Partial - Must have space between relation name and its content & sometimes feel like cumbersome additional pane Not supported ◐ Partial Favourite relations must show below title or at the top
Whether it can link/mention to other things (using @ or /link or cmd+k with highlight) ◐ Partial - only limit to relation that contains object, not text
Inline / in-text input ✕ must use pane or clicks and not streamline

I like your proposed layouts. It is not easily visible the query matters if it is hidden in filter. I have to enter in myself to see it :smiling_face_with_tear:

I certainly think query should enable multiple objects / relations.
But I still think collection and set are two different things… One is query; another is manual categorisation. I believe collection is the solution to people wanting folders, but not multiple things.

This point illustrate a part of the irreversibility - since users already well adopted a previous way to manage their contents. But I suppose if set supports query of multiple object types, then it is only an upgrade to set, nothing will change for collection / manual selection of objects.

I supports these features every much.

Would FR disambiguators enhance your management in a non-tag way?

I suppose you could create 4 different relations of who, what when, when and where, and use the relation type which allows objects? And if we have FR build title from relation, you can push German onto Berlin object, perhaps it will partially solve your sub-hierarchy situation.

Quick reference and retrieval: If global search is well functioning and displays relation as well, querying should not prevent you from getting to where you want to reach. Both the object type or the relation of type should do the job finding object of software. And may I suggest adding supports to querying multiple object as relation input to Search? ← this help find articles that contains 2+ concepts.
Index? How do you index with tag? Indexing to me means identification down to every single object, like zettlekasten or library catalog…


Well, wouldn’t this make sense? The older the topic and people still support it, the more priority it deserved, and so more accumulated votes reflect this.

But perhaps can we ask Anytype Team to occasionally revise backwards - from oldest creation time? Or if we can add oldest display onto Forum, it should encourage people looking at older posts? And if people find the need of old feature request and start to create new one, they would be greeted by similar topics on the right pane of writing. Ultimately, features are usage based, not voices based.

Different to electing political leader, the effect of one vote is unseen. Your one vote matters on the forum. Just one vote get the topic to the voted list.

See what @Filip did to get what he wanted on track :wink:.


Sorry I didn’t make myself clear. I meant what would someone build up and expand its functions of these 6 points from your way and from other way? In other words, one indicator of irreversibility is the team has constructed something from it and the new function depends on it, the other new features would not work because the foundation is different. e.g. A treehouse won’t work if your foundation is a river. What’s your treehouse?


P.S. See how I am finally learning and finding the use of tags in this post to address blocks with their relations to topics​:rofl:… but if it is in Anytype, I probably just want to link or mention it. :grinning:

1 Like

You can already query multiple types at least, by setting the query to the object type relation, and then using a filter to choose which types you want to be shown in the set.

1 Like