File Metadata Block

[klreeher]

I think it would be very helpful to allow the use of a YAML-like metadata block. (Or Multi-Markdown style. Or Pandoc. Just something.)

YAML-like:

---
title: value
author: value
date: value
---

Ideally, this would use the "title:value" pair to name the note, and everything within the block would be formatted to show it's not part of the note content.

I use pandoc locally to frequently turn a note into a pdf or .doc file, so I use meta blocks a lot. Not having Notes automatically rename my file to title: value would be great.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jancborchardt]

This seems related to Use file name instead of first line as title #190 as when that is fixed, your issue about the note automatically being renamed would be fixed as well. :)

Additionally afterwards we could for example show the text of that block at 50% opacity to show it’s not part of the note content.

[elsiehupp]

I initially posted this as a separate Issue on the basis that I thought interoperability with the header format used by Joplin would involve a different metadata format, but I dug into my Joplin notes, and it appears they do, in fact, use YAML, so I'm going to bring my commentary over here, instead.

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

I currently use Evernote. I would like to be able to escape from Evernote. The notes I have in Evernote have metadata I would like to preserve, such as manually configured (i.e. backdated) note creation dates for content created outside of Evernote.

Describe the solution you'd like

Nextcloud Notes could support the header format used by Joplin, which is based on the EML format [actually it's YAML]. Even if Nextcloud Notes wouldn't immediately support all of the metadata fields, it could still preserve any existing ones on imported notes. The headers would be hidden by default, as in most GUI email clients, but they could be viewed and edited in plaintext via a supplementary interface. Metadata fields could be incrementally added to the GUI, but the existence of the EMLYAML-header backend would allow for the incorporation and preservation of metadata yet to be implemented in the user interface.

Describe alternatives you've considered

The main alternative is just using Joplin or sticking with Evernote.

Additional context

This issue is related to #164, but the difference is that I'm proposing the implementation and support of a specific metadata format already used by a major FOSS Markdown note-manager application [which appears to be YAML]. Implementing this issue might also fix #584, though the exact method of doing so would be open to debate. It could also fix #299, though actually including tags in the GUI would be separate from supporting tags under the hood. Again, the main thing here is supporting and preserving arbitrarily extensible imported metadata, regardless of whether or not individual fields are implemented in the user interface.

Ultimately it might be nice to have full database cross-compatibility (or at least JEX compatibility) with Joplin, but I recognize that implementing that is a much taller order. The main reason I keep circling back to Joplin is that it specifically supports importing Evernote ENEX exports, and in so doing preserves metadata initially created within Evernote. If Nextcloud Notes were to support Joplin's metadata format, this would create an indirect migration path from Evernote. Nextcloud Notes could also potentially borrow Joplin's ENEX-import module, but I recognize that that's also a much taller order. (The import module is written in TypeScript, though, so porting it would be more straightforward than if it were written in some other language.)

I guess if I were to summarize my main thought here, it would be to say that metadata could be implemented incrementally by defaulting to preserving and concealing it behind a disclosure button, so that metadata fields yet to be implemented could still be passed to and from other applications that do support them.

[elsiehupp]

This is an example of a Markdown file created by Joplin:

Squash/Rebase

https://gist.github.com/patik/b8a9dc5cd356f9f6f980

```
% git reset --soft master
% git commit -s -m "<commit_message>"
% git push <origin_or_upstream> +<existing_branch>
```

id: 6396807806f6466287d4492da67acb11
parent_id: 1e2b1170d1e34407914765ba1946636c
created_time: 2021-03-14T06:17:20.978Z
updated_time: 2021-03-14T16:19:12.023Z
is_conflict: 0
latitude: 0.00000000
longitude: 0.00000000
altitude: 0.0000
author: 
source_url: 
is_todo: 0
todo_due: 0
todo_completed: 0
source: joplin-desktop
source_application: net.cozic.joplin-desktop
application_data: 
order: 0
user_created_time: 2021-03-14T06:17:20.978Z
user_updated_time: 2021-03-14T16:19:12.023Z
encryption_cipher_text: 
encryption_applied: 0
markup_language: 1
is_shared: 0
type_: 1

The first line of the file is, in fact, the display title in Joplin. Joplin just pretends that it's a defined field. (The blank line between the first and third lines is stripped out.)

Also, the filename of this note was <id>.md.