Some findings and thoughts about search function

Part 1.
These days I created many text links, and it occurred to me that whether these URLs can be searched out through the search bar. I tried some cases and the answer is no.


  1. The the text link is restricted to some formats, like “https://", "ftp://” or “abc://test”.
  2. The url of the text link can not be search out.
  3. If write down a url as plain text, it can be search out, but the results are not perfectly matched.
    3.1 “”, doesn’t work
    3.2 “”, works
    3.3 “://” works
    3.4 “s://” doesn’t work
    3.5 “ps://” doesn’t work
    3.6 “tps://” works
    3.7 “xxxyyy” doesn’t work (may be relevant to Global Search does find content only when word is (nearly) fully typed)

I couldn’t find out the main problem and what the pattern is. Is this should be considered as a bug?

Part 2.
One more thing is that the title of the search results is “Recent objects”, which is confusing.
There are four situations:

  1. Click the search bar, show a list of recent objects, and it looks good and understandable.

  2. There is no any result, and it looks good and understandable.

  3. Sometimes the search results are not the right answers (Idk why, I suppose this is a bug)

    “Cool S” doesn’t contain anything about “

  4. There are several matched results, but it is still “Recent objects” (compared with point 0), which is confusing. Are this results the matched ones or just real recent objects? I did notice the order is based on “recently opened” (why the title is named like this), but because of the bug in the point 2 and the original expression in point 0, I can’t tell what the results really are.

In my opinion, Anytype is a little different with the hierarchical structure app, and many user feedbacks show it is tough to locate their objects, which makes it important to have a stable and even powerful search function.


Part 1: URL in text link can not be search out.
pros: completely control all the contents, even the url behind the text link.
cons: the results seem to be redundant if there are too many URLs

Part 2:
“Recent objects” is confusing due to the search function is not stable enough. Please keep polishing the search function or maybe just change it into “matched results”.

Part 3:
Search function is really essential. Hope it will be improved after the infrastructure development. Stability, even wildcard character or regular expression?!

I tried my best to make these points as clear as possible, but it is still messy.
Please correct me if there are logic mistakes.

Btw, be careful when you test with some random urls like “”, because some of them are NSFW, which makes me embarrassed after clicking the link by accident. :sweat_smile:

Related links:


We updated our search engine and in the upcoming release you can check if it is helping anyhow


This is exciting!

Thanks for that! Very thorough. Hopefully the new version improves on what you pointed out.

Is the search engine (bleve) updated in the current version (0.31.0)?
Or it will be in the upcoming beta version.

HI @fat_fellow,
I am also VERY interested in which anytype version the search will be improved or debugged.
Because I am also having trouble with the current search.

The search in the current version is quite unreliable or unpredictable.

To be honest I changed my hole documents/objects-struture. Instead of individual files/documents/objects as before in Evernote/Trello/Notion, with all of them has really helpfull and predictable main-search-solutions, I create in anytype very large documents.

Otherwise with the current AppWide-search-solution, I can’t re-find some stuff/ideas/words/urls/objects in all the files when the search-query is only a partial of the word.

  • Then there are sometimes much to many objects listed in search-result with NO search-term in them
  • or most of the time there is a lack of objects with the exact search-term when this search-term is only a partial of the hole-word.

To find partial if words or wrong-written words (so I have to search for the partial, who is matching in every possible “wrong-written”) most of the time it is a pain and an extreme waste of time.

Because most of the time I had no chance to find in hte main-search-field. So I had to go trough each document of a huge list of documents to serach by the in-document search.

At the end not practiable and extremely frustrating. Therefore I create BIG-HUGE documents only to have the in-document-search possibility…

See to the problem / theme:

→ So I would like to go back to more OOP-structure with the new search-solution from anytype.

@fat_fellow could you the version number to “upcoming release” that will be implemented the new search-engine?
This would also help in future, because it would be very well comprehensible for later problems or readers.