Relative links to other notes

[kflpk]

Please use GitHub reactions 👍 to show that you are affected by the same issue. Please don't comment if you have no relevant information to add!

Is your feature request related to a problem? Please describe. My problem is that currently there's no way to link notes to one another that is consistent between Nextcloud Notes for Android and QOwnNotes. Currently the android app uses an ID of a note to link to it. There are two problems with:

1. There's no way to check an ID of a note in the android client. You have to go to your Nextcloud instance's website to get the ID from a URL, and paste it to a markdown link. It's slow, it's frustrating, all around not a great experience
2. QON (QOwnNotes) doesn't support that. It does, however, have a better way to handle internal links, which I describe below.

Describe the solution you'd like In QON when you want to link to a note in the same folder, you simply have to paste it's filename along with the file extension. If you want to link to note located in a different folder, you do the same, but using relative path to the file.

Lets say, you have a directory structure like this

Notes
│   
├── folder1
│   ├── note-1.1.md
│   └── note-1.2.md
└── folder2
     └── note-2.1.md

and this this is the content of folder1/note-1.1.md

[Link to note 2 in folder 1](note-1.2.md)
[Link to note 1 in folder 2](../folder2/note-2.1.md) 

and if you click on any of those links, the program opens their respective notes.

Why is this better? Because you only need to know you directory structure (which you probably made yourself and organised it in a way that's intuitive for you) and the filename (which is the name of a note with .md or .txt extension whichever you have set in you settings), and while editing you can easily see what the target note is.

Describe alternatives you've considered

• Sure, I could use Nextcloud Notes web client on desktop, but the thing is..... it kinda sucks. You can't really change its behaviour, the only choices you have is where the notes are stored and the file extension new files notes are created in. There's no preference to display notes in preview mode by default, and it doesn't even render some things properly (see issues #680 and #325 on nextcloud/notes repo. According to issue 325 it's been a problem since at least 2019.).
• There also aren't many desktop clients I could find and those NC note clients I could find on GitHub seem to no longer be maintained.
• For the android side, I am not aware of any other decent Nextcloud notes client, and aside from lack of an easy way to link notes, this one is pretty much perfect for me.

Additional context You may wander why I'm talking so much about how QON handles internal links, but I believe that it's simply one of the best and most popular note clients compatible with Nextcloud, it's really customizable and is actively maintained. It seems that this app, and QON are the most popular Nextloud note clients for mobile and PC. It's not really easy to make complex notes with multiple files and references in the android app and I really believe that the compatibility between those two apps could make for a viable self-hosted, open-source alternative for something like Obsidian (which is closed-source and paid to sync). Sorry for such a long issue, I wanted to make sure I won't skip anything important.

[stefan-niedermann]

Hello there :wave: Thank you for the detailed explanation. I appreciate the efforts, you put into the analysis.

You pointed out the two major problems that you have. The first one is obviously "easy" solvable (#900). With a graphical way to pick notes, you will not need the technical ID of a note.

Some background information regarding QOwnNotes: QOwnNotes does not use the ID because it was a bad approach, but because it is not aware of it. It simply doesn't know the IDs. Why? Because QOwnNotes does not use the Notes-App at all, it does not use the REST-API but is only compatible because the storage backend of the Notes app is completely based on folders and files (yey :+1: :wink: ).

Now let me point out the drawbacks that the suggested solution has:

1. The Notes Android app is currently completely agnostic to the backend, because it is using the API. This decouples the Android client (as well as the iOS client) from the actual storage backend. Your approach will eliminate this architecture because each client will need to know stuff about the internal storage architecture of the server side app. Each change on the server app can easily break all clients at once if they are not decoupled via a API. This is also the reason why the Notes Android app isn't aware of .md or .txt extensions: because it doesn't even know (and have to know), that the server is dealing with files instead of database entries.
2. Change-Management. The filename is derived from the notes title. Changing the title will result in a changed file name. Seeing my argument above: Clients wouldn't even need to take care about this kind of details, and they shouldn't. But as it happens, i know it in this case. So, back to my second argument: Moving a note into a different folder or title. What happens now? How will the Android app be aware that the URL needs to be adjusted? What if the server tomorrow decides to not use subfolders for subcategories but separate them via _? Will the app do it? The server? Each app and the server? Using the ID of the Notes app is the only way to ensure that one is always pointing to the very note that is linked.

So while it seems to be the

better way to handle internal links

this approach is another, but for sure not easily a better. It has advantages and disadvantages.

[kflpk]

Thanks for the reply. It gave me some good understanding of the design choices in your app, so thank you for that. So, I am aware that QOwnNotes' design is a necessity rather than a conscious design choice, because it uses a directory structure. In regards to issue #900, a graphical way to link notes would be a nice feature, but as I can see, it hasn't been yet implemented.
I understand your approach with using only API and not relying on the server-side implementation, but I still think it would be beneficial to have the ability to add link to other notes by their name. Since the app knows ID of all notes and their associated names, it means it's possible to implement linking by name. I know it's not server-side-proof, as the server could change the title of but since the app is used with Nextcloud which is typically self-hosted, I would argue, that it would happen very rarely if ever, and wouldn't be too much of a risk, and the app could still use ID linking by default, but give the user a choice whether or not to link the note manually.
I'm not quite sure how the links would specifically work, but it would probably be a good idea, to have the ability to link two notes within a category, since a user would probably have notes on similar topics contained in a specific category. Alternatively it could use wikilinks as suggested in other issues, but I understand it's something you don't want to do at the moment

[NA0341]

What about reference links that use id's, but have the destinations title set as link text (name)?

Short: -» API - compliant -» platform independently accessible -» future-proof

Reasoning: -» This ensures that it'll technically work in all Nextcloud API - based applications and be visible as a technically non functional link in other applications (which title tells the reader where to look for).