Metadata in 2.0

[InnayTool]

In the current version of HedgeDoc metadata is specified by adding tags in a section on top of the document. This is done by using front matter in YAML syntax.

An alternative would be to specify the options and metadata by adding database fields and GUI elements.
This has several disadvantages:

• More GUI which must be built
• The API has to set set options as separate calls
  Advantages:
• Backend doesn't have to parse these from the notes.
• Markdown is cleaner -> fewer confusion of users who did not know about metadata tags.

We should decide which option we choose for 2.0.
Related issues:

• Add tags to history table react-client#59
• Exclude tags (especially images) from document name react-client#440

[DerMolly]

I think we don't really want to move much from the frontmatter. As it's easy to collaborate on and people are used to it not just with HedgeDoc, but with other Markdown software as well.

I think one could argue, that the breaks option could be put in the DB instead of frontmatter, if we wanted to change the default from true to false.

All old notes could be imported in the new schema with the breaks option set to true. All new notes would be false by default and anyone who wants to use breaks: true can do so.

Only question with that is:
What do more of our users expect? False or true?
I could be argued that should be the default. On the other hand, there is also a strong argument to doing what the "standard"¹ tells us (aka breaks: false).

¹ I know there is no real standard, but that's what most people do with markdown.

[ErikMichelson]

Having the metadata inside the note content enables another good thing: Users can easily make backups of their notes including the metadata(!) only by downloading their notes.

[ErikMichelson]

We needed a legacy-field anyway in the database (for example for redirecting only old notes to /n/). This field could be used for checking whether the old breaks was used and thereby save us one additional breaks field in the database, or?

[mrdrogdrog]

I'm against removing frontmatter. It's the industry standard for meta data in markdown and I think it would confuse more users than help them. But. We could:

• (Warning! Just an idea!) Make front matter invisible in the editor if you don't want to see it. (don't know how easy that is)
• Add a GUI Editor for front matter (which is already planned)

[InnayTool]

I think it's no problem to add the metadata if clicking on download button and I think an additional field in the database is no problem.
In my opinion the relevant question to this, what do the most users think. Do they know of this industry standard? And are we want more tech users or others?

@mrdrogdrog why do you think it is not confusing if we make frontmatter invisible?
A GUI editor would make it more beginner friendly but don't remove parsing from development.

[mrdrogdrog]

A GUI Editor will come in 2.0 anyway. But the plan is, that this Editor changes the frontmatter to cover beginners and advanced users.

I don't see any advantage in removing frontmatter than just breaking with a industrial standard.

Also we'll have to implement server side markdown parsing anyway, because if you don't define a title in the meta data, then the first heading is the document title.

[DerMolly]

I think it's no problem to add the metadata if clicking on download button and I think an additional field in the database is no problem.

How should the metadata be added? As frontmatter? Then the backend needs to be more aware of the whole frontmatter than before…

[InnayTool]

Do you mean because we have to add an function which inaserts it or because of importing notes with frontmatter?

[DerMolly]

Do you mean because we have to add an function which inaserts it or because of importing notes with frontmatter?

Both, actually.

[InnayTool]

Yes, maybe it's less about the work but more about separation of content and metadata and having no cached data in database.

[davidmehren]

I think the discussion is mostly done here: We keep metadata in markdown/YAML and create a GUI to edit that.

The remaining question is how we handle legacy notes, but that should probably take place in a separate issue.

[DerMolly]

The building of the Metadata GUI is tracked in #2884