Ability to track relative links between Inkdrop documents

Hi, wondering about the following feature or plugin:

Ability to track relative links between Inkdrop documents.

Given:

2 notes:

  • note “Parent”, and
  • note: “Child”
    which are linked (“Copy Note Link”) such that the Child link is pasted into the Parent note.

Then:

  1. There is no way of knowing in review mode that the link is internal, ie to another note in Inkdrop,
    or external, ie: to an outside link.

  2. There is no way for Child note to know that it’s being referenced by Parent note.

  3. Deleting Child leaves the link in the Parent to the now deleted Child,
    with no warning that Child has been deleted (and no warning before deleting Child).
    The Child link in the Parent note now points to nothing.

Therefore I propose the following features (or Plugin):

a) ability to know that a link is internal to Inkdrop

  • currently I do this manually by prepending “Ink:” to the child link,
    this could be done automatically.

b) ability to know which other documents have a link to this document.

  • ie: link-back
  • for example at the top of the Child note there could be a list of the Parent links which link to this document.

c) ability to be notified prior to deleted a linked note (Child) .
This could be a warning that this note is linked to by the following notes.

d) ability for a note to list the internal notes that it links to (forward links)

If this feature is not likely to be on the roadmap, and there is significant community interest, I’d be willing to make a plugin with this functionality (provided that’s doable in a plugin).

David

Hi Dav,

Thank you for the suggestions.
I guess you are talking about interconnecting notes, like Wiki and other apps that focus on connecting knowledge fragments. It’s important to keep in mind that there is a large gap in terms of the concept between them and Inkdrop.
Please check out my past discussion about it on this topic:

I mean, Inkdrop is, to be honest, not focused on strictly interconnecting notes.
It is basically a Markdown note-taking app. Markdown is a simple format to write roughly structured and mark-upped text. The concept of link in Markdown is from hyperlink that can be broken. So, strongly connected links/back-links are not supported.

That being said, you can implement it as a plugin.
The people in that topic would be happy if you made it!

a) ability to know that a link is internal to Inkdrop

Yes, it can be automated. The internal link URIs always start from inkdrop://note:.

b) ability to know which other documents have a link to this document.

You have to search with a URI with search API. And override rendering A tag.

c) ability to be notified prior to deleted a linked note (Child) .

Same as above.

d) ability for a note to list the internal notes that it links to (forward links)

Same as above.

I shared it on our Discord server so that it can get attention from other people.

Thanks, btw, I share iamben’s enthusiam for Inkdrop, I too love your product!
Re Roam and Obsidian, I haven’t looked at those in ages.
Re Plugin:

  • my thinking is that this could be implemented with one managed note which had a list of all “Child” notes and for each Child note a list of parents.
  • (Note I haven’t looked into what persistence hooks you provide for plugins, but at a minimum you have whatever you are using for the actual notes. Looks like PouchDB to me, but I could be wrong).
  • so, assuming using a managed note as the plugin persistence, then basically, at initial startup all notes would need to be parsed once, looking for Inkdrop notes to initialize the structure.
  • then whenever a note is edited, then the managed note is updated, ie:
    • a) remove all links to that note,
    • b) then for all Child links, create Child list if not exists, and add the Parent link.
  • this would presumably also have to happen on all synchronizations, and note timeline rollbacks.

Then, if ‘linkback’ plugin selected, for all open notes put a list of Parent links at the top of the note.

Probably that’s all that’s needed, but I’ll take a look at Roam and Obsidian at some point and also see what’s involved in creating a plugin.

Most likely the difficult part will be testing the rollback (history) and note sync scenarios, ie: in the case of sync conflicts, but I expect that’s solvable, at a minimum, by just recreating the index note.

David

I appreciate all your efforts. Those let me focus on improving the core experience.
Yes, it’s PouchDB:

You are right, you have to cache somehow the relationships of notes.
I guess you can store them as local documents; They will be stored only locally and never be synced.
You can watch note changes including sync & rollbacks via onNoteChange database API documented here.

Hope that helps!

Thanks, figured it was PouchDB!
I guess local documents could work, assuming re-indexing following a sync. If indexing is really fast (and it probably is), then we don’t even need to persist it, it can just stay in memory.

Next steps for me would be to:

  • take a look at your docs
  • then build a “hello world” plugin.
  • then run some profiling to see how long it takes to index notes, ie: if indexing is very fast, we don’t even need to persist at all.
    • I guess for a sample I’d have to create say 10,000 documents, with some percentage linked to some other percentage.
    • probably I should try that on mobile too, ie less resources.

Question:
Is there a way to develop this without affecting my own instance.
If I’m creating and throwing away 10,000 notes I don’t want that synced to my mobile and laptop instances!

I guess you can test the app inside a virtual machine with sync disabled.
Good luck!

Your app looks beautiful - and I signed up immediately after watching your youtube video

… however … a lack of this feature built in simply is a non-starter for me. I completely agree with all your philosophies, but you don’t eat your dogfood & IMHO break your own tenets. if you are treating markdown as a first-class citizen in your system, then why can’t this structure exist:

Directory Structure

<root>
* note-a.md
* note-b.md
* <folder>
  - note-sub-1.md

InkDrop UX

root (Notebook)

  • note-a
  • note-b
  • folder (Notebook)
    • note-sub-1

Contents of each file

note-a:

[link to note b](./note-b.md)
[link to sub 1](./folder/note-sub-1.md)

note-b:

[link to note a](./note-a.md)
[link to sub 1](./folder/note-sub-1.md)

note-sub-1

[link to note a](../note-a.md)
[link to note b](../note-b.md)

Then you could import 100% of an existing repository of interconnected markdown files in a directory structure, auto-create the tree, and have things magically work… AND… you could export back to that filesystem and have the directory structure replicated and actually work.

Why would I want to lock myself into a big bag of unconnected markdown files?

You don’t eat your dogfood and follow your own tenet of markdown-first.
Why should we?

So the irony here is: I’m fairly certain you have 100% of what you need to relatively easily do what I am asking. Seems like your internal DB simply needs a secondary index on the path structure I proposed. Why?

I did the following:

  1. I created an empty notebook called default, configured as default
  2. I created a secondary notebook called root
  3. I deleted example 100% of notes
  4. I created the notes I suggested with content and notebook tree structure under root
  5. I selected All Notes, highlighted all shown, and then export > As Markdown...

Your export system names things exactly as-expected:

  • Files are named as
    • note-a.md
    • note-b.md
    • note-sub-1.md
  • Directory structure is not preserved and is flattned

I then repeated the experiment, but did different export process:

  1. (same as above)
  2. (same as above)
  3. (same as above)
  4. (same as above)
  5. I selected the root folder, then command-clicked the highlighted note to deselect it
  6. I hovered over root > right-clicked > Export as Markdown...

When exporting this way, the structure looks like this:

./folder
./folder/20220319-note-sub-1-hphyOP9Gfx.md
./20220319-note-a-mGm79DWsk.md
./20220319-note-b-D9z3dEyPy0.md

This tells me a few critical things:

  1. You already have the export system able to walk the tree
  2. You already name exported notes as-expected (1st test case)
  3. You do not enforce note name uniqueness in-each-folder
  4. You could very easily add the note path to your internal JSON structures
  5. You could very easily add a customer-chosen uniqueness constraint, perhaps appending your internal ID if note names aren’t unique when chosen
  6. You could then add a secondary index on the path structure in each note JSON
  7. You already have a functional hyperlinking system like inkdrop://note/D9z3dEyPy0
  8. If you assume (1)-(8) is true, the click impl is:
  • intercept clicks on link ./folder/note-sub-1.md within note-a which is in root folder
  • look up via primary index note-a (contains path of /root/note-a)
  • Combine paths:
    • /root/note-a
    • ./folder/note-sub-1.md,
    • Into: /root/folder/note-sub-1
  • Use path to look up note-sub-1 via secondary index
  • Load note-sub-1 exactly like occurs with inkdrop://note/<id> into view
  1. If you assume (1)-(8) is true, the export impl is:
  • User enforces uniqueness per folder (enforced by UI after that)
  • Walk the tree to export (you already do this)
  • Use the path embedded in your internal JSON as the filename (you already almost do this)
  1. Add a 2nd contextual menu ‘Copy Externalizable Note Link’ which copies the path

If you implemented the above system:

  • imports an exports would be seamless with your potential customers’ existing systems.
  • Customers with 100s or 1000s of existing, relatively hyperlinked markdowns collections would function
  • Git repositories containing markdown could be imported/exported automatically & used as the preferred markdown editor instead of IDE

As-is, here is the UX:

  • I import all my 1000+ well-maintained markdown files
  • The 10K+ hyperlinks I have are all dead.
  • I have some choices…
    1. Don’t use Inkdrop
    2. Use inkdrop without hyperlinking
    3. Use inkdrop and modify 10K hyperlinks and never export
    4. Use inkdrop and modify 10K hyperlinks, export periodically and upon export fix another 10K hyperlinks

I think you’d get more customers if you implemented what is proposed above.

Thanks for letting me know your thoughts.
So, you have 1000+ well-maintained Markdown files. That’s great.
But what do you expect for Inkdrop? What problem do you want to solve?
I think that’d be different from mine.
Inkdrop is basically inspired by Evernote. I’m building a simple Markdown note-taking app.
It doesn’t replace the filesystem. It’s by design and concept.
I guess you look like wanting a Markdown editor with tree and list views for your local Markdown files so you can still have local files and sync with Git repositories.
While I understand your need, I’m afraid that that’s not what Inkdrop would focus on.
TBH, I don’t feel like spending time maintaining compatibility with filesystems at the moment.
I’d like to focus on improving other features.

What do I expect from Inkdrop?

  • A good editing experience
  • A good indexing layer on top of 1000+ mardkown files
  • Respecting the content of the markdown imported files. i.e. if I can hyperlink amongst them in-IDE (IntelliJ, VS Code), why can’t I after I import them?

What problem do I want to solve?

  • A generic IDE is a good text editor, but not super great at editing/rendering markdown. I want to improve that experience
  • I want to edit & search in Inkdrop, and export daily to IDE
  • I want my exported markdown files not to be filed with [foo](inkdrop://...) links which don’t work anywhere except on a system which is inkdrop-aware

It seems you are marketing to SDEs - I can’t imagine SDEs wanting to have a markdown sandbox where they aren’t allowed to play outside the sandbox.

Thanks for answering my questions.
Yeah, I understand what you want to do.
But again, it’s a note-taking app, not for writing well-structured documents.
It can’t be used as an external editor or organizer for your local file-based projects.
It’s for writing small pieces of memos and notes in Markdown.
Your need looks like something mixed between them.
But I can’t please everyone. I have to keep it simple and clean. Because I’m just a solo developer whose resource is quite limited.
Saying yes is easy but it will make the app broken and unuseful and you won’t be happy to have broken features.

This definitely won’t solve all of your problems, but these two plugins may alleviate some of your gripes:

https://my.inkdrop.app/plugins/plain_text_backups

https://my.inkdrop.app/plugins/wiki_links

Ultimately though, there’s probably a better application for your use case than Inkdrop.

@Ryan_McQuen thanks for the helpful suggestions

there’s probably a better application for your use case than Inkdrop.

Suggestions?

The benefits I see from Inkdrop that I haven’t seen elsewhere yet:

  • Great UX, look-and-feel while editing
  • Cross-platform sync with OSX, iOS, Linux, Windows

@craftzdog I understand you are a single developer & that you can’t please everyone. I also understand you have to limit the scope of the features you add to keep things stable. However - I suggest that you carefully consider my design suggestion & do a throw-away dev-spike on a lazy-day to see how feasible it is. Currently links like [foo](../bar.md) don’t function, so you wouldn’t be breaking anything.

Even if you ignored export-functionality and unique-naming-per-notebook and just added the relative-path-hyperlink support (link to first match), you’d have a big-win for UX as well as import compatibility.

Do you have any concrete examples of what might break if you implement just relative-path-hyperlinks? What about examples of what would break for full import/export functionality?

I’m pushing you because I think what you’ve got is a good product that could grow its user-base from the suggested features. As-is, I can’t justify using it because it deviates too far from my personal-needs & vendor-locks me into using specialized hyperlinks that don’t work outside inkdrop. Your existing API appears to give me enough hooks to add my own multi-phase-export/import, but why should I write that & give it to your community when you could simply add the features?

Your video overlay in your youtube video seems to imply you are a keyboard enthusiast. How do you feel when you type: [my hyperlink](../ and hit control-spacebar and nothing happens? When I’m in IntelliJ, I get a list of auto-completes. Wouldn’t your UX focused users like that?

Have you tried Obsidian?

@Ryan_McQuen Looks like that might work - the sync to iOS devices in Inkdrop was appealing - but not at the cost of losing relative linking & filesystem synchronicity. Looks like Obsidian does most of what I’d like even without a fee. I do my own version control, so I’m not interested in their syncing/backup.

I generally like to pay SDEs who make good products, but only if those products contain features I desire.

Good luck @craftzdog - Hopefully your customers want the features you want to build.

1 Like