YAML front matter reading (while importing) and parsing (when exporting)

Is your feature request related to a problem? Please describe.

This feature request is related to upcoming releases, regarding import and export of .md files.

Describe the solution you’d like


My notes have a front matter like this:

date: 2021-11-16T09:35:47+01:00
updated: 2021-11-18T12:55:48+01:00
tags: geek info example
description: |
  Notes about moving out of <a href='https://github.com/xplosionmind' target='_blank' title='my GitHub profile'>GitHub</a> and setting up a self-hosted <a href='https://gitea.com' target='_blank' title='Gitea'>Gitea</a> instance.
aliases: Switch to Gitea, Quit GitHub, Ditch GitHub
image: https://upload.wikimedia.org/wikipedia/commons/b/bb/Gitea_Logo.svg

It would be awesome if at import time the user could choose what front matter entry to associate to a value, e.g. prompting: «You have entry image with value https://upload.wikimedia.org/wikipedia/commons/b/bb/Gitea_Logo.svg. What do you want to do with it?», and the user could select the option to get image URLs and setting them as the image for the object in Anytype.
The same should happen with all of the other entries of the front matter. Of course, in my case I would need to import a ton of Markdown files at once, so it would be ideal to select in batch which YAML entries to associate to object properties.


When exporting Markdown files, not only the content should be printed, but metadata, too. Again, this should be done by parsing a YAML front matter containing all of the info of the object.

Describe alternatives you’ve considered

Once the .md import feature is enabled, a user would be forced to manually add metadata.

Additional context


Perhaps within the relation itself there could be an option to set this relation as YAML? Or per page you can have a setting to show relations as YAML on the top of the page.

Then when exporting to .md these pages/relations are exported as shown in your example.

Though, this might be very complicated?

Love the idea though, makes perfect sense since Anytype is all about owning your own thoughts and ideas and this will make Anytype way less restricting if you ever needed to export it!


This would be a nice solution.

My perspective is that the more content, information and metadata stays in plain text, the better it is.

I would really appreciate if all of the relevant information could easily be retrieved in the Anytype directory by running a simple good old find.

The front matter is actually meta data about the content, and Anytype’s way of handling meta data to a page is through relations. So the proper solution in my opinion is for the user to create a type specific to their notes. So for your example, either the user should have created a type with the relations date - datetime, update - datetime, tags - tag, description - text, aliases - text, image - url and the importer should ask the user for the type during import to import the page. So importing similar notes would then create new pages if that type and populate the relations with values from the front matter and the body of the page from the content of the note. Another option is for the importer to create a type based on the front matter, but that is much more complex than the user creating it. This would then enable the user to create a set for that type and use the front matter to sort or filter through them

This is something that should be given as an option to the user to export the relation or not for any type of exports not limited to markdown. So having such option would then export the page’s relation in accordance with the exported type

Might be hard to maintain everything in plain text and offer the same flexibility as now. But one could certainly create a find alternative specific to anytype which has the same interface as that of find, once the local APIs are out :grinning_face_with_smiling_eyes: