Can't reference other notes through relative links
Steps to reproduce
- Create a Markdown file named
index.mdwith e.g. the following content
# Index
- [Topic A](./A.md)
-
Create a file named
A.mdin the same directory -
Try and click on the link in
index.md
Expected behaviour
The note object linked to A.md should be opened
Actual behaviour
The URL is resolved with respect to the current note ID prefix, so the redirect goes to /apps/notes/note/A.md, which doesn't exist.
This is particularly relevant when using something like e.g. vimwiki (or anything that allows you to manage Wiki-like notes in Markdown format). Relative URLs in these context are usually resolved to file names, but Nextcloud Notes works with internal note IDs instead.
Would it be possible to add an intermediate resolver that checks if the requested URL points to a file indexed as a note, and in that case redirect the user to the right URL?
We can reference other notes. Just have to use the note id (see number at end of note link) not the note name:
https://github.com/user-attachments/assets/07bde47a-45de-4c20-b66f-5d4b1139118c
@enjeck I know that I can reference notes by ID, but it doesn't answer my use case (I'm just realizing that this should have been a feature request rather than a bug btw).
If I want to access the notes from another client pointing to the same directory (e.g. Obsidian, VimWiki...) then most likely that client knows nothing about Nextcloud note IDs - but it probably knows about filenames.
A good solution that may make things work with all clients may look like:
- If a note URL is a relative URL in the format
[0-9]+then it's most likely a note ID - If instead it's in the format
some/path/Note(.md)?, and that path exists, then render the associated note ID
- If instead it's in the format
some/path/Note(.md)?, and that path exists, then render the associated note ID
Could be possible, given that the API gives us an internalPath with that format:
Request:
curl -u admin:admin \
"http://nextcloud.local/apps/notes/api/v1/notes"
Response:
[
{
"id": 237,
"title": "Note 1",
"modified": 1745708246,
"category": "",
"favorite": false,
"readonly": false,
"internalPath": "/Notes/Note 1.md",
"shareTypes": [],
"isShared": false,
"error": false,
"errorType": "",
"content": "Note 1",
"etag": "b2e87d6a4305fa402b10424551980be1"
},
{
"id": 302,
"title": "Note 1 (2)",
"modified": 1745709634,
"category": "",
"favorite": false,
"readonly": false,
"internalPath": "/Notes/Note 1 (2).md",
"shareTypes": [],
"isShared": false,
"error": false,
"errorType": "",
"content": "",
"etag": "730ba02e995cb30ade2431010355e06f"
}
]
This is a much watched for feature. Notes is one of the most useful Nextcloud apps. The fact that the markdown doesn't allow links to other notes severely limits the usefulness. The natural format would be [some text](target note title) just like the markdown for normal links, but allowing the target note title to serve as the URL.
Keep it simple. Any implementation that requires normal users to scrounge around for note "id" is dead on arrival and will never be used. (we're talking about normal users here, it is a stretch to explain [title](url) much less sending them looking for references to database fields within the site API)
You can provide an option to enable/disable this feature -- but I don't really see that as necessary. There are no other instances where [some text](other text) syntax is used, and there is no potential to conflict with the current markdown. The worst case is the same as the current worst case, somebody enters a malformed URL and the link doesn't work. There is nothing different if this feature request is implemented.
Aside from typing out a link to another note in the usual markdown format: I feel that it would make sense to have a "link to note" option under the "link" button in the editor tool bar, or maybe a "link to note" option in the Smart Picker. The Smart Picker and the tool bar can already link and do all kinds of stuff, but it can't create a link to other notes.