New "default location" behavior for attachments/images: Automatically convert the note's .md into a container-folder itself that holds all embeds and cleverly hide it throughout the UI by treating it as a regular note

[boettges]

Hey everyone,

I couldn’t find anything similar to this idea. Please point me to a discussion If I might have missed it.

Status Quo

As of now, Obsidian supports 4 default settings for how to handle new attachments that for example get dragged and dropped into a note.
One can specify whether file attachments like images or pdfs should be stored …

1. (all) in the root folder of the vault,
2. (all) in one specific folder,
3. in the same folder of the note.md to which the attachment gets added newly, or
4. in a new specific attachment subfolder relative to the folder that contains said note.md file.

There are pros and cons for all four of those settings.
Commonly, people that choose 3 and 4 want to keep notes and attachments relatively close together on a file system basis. One reason could be logical separation of different topics, another ensuring easy data-portability in case the entirety of the note base has to be broken up in the future.

Use case or problem

If you have a couple of hundred notes with attachments either globally in the vault or in the respective attachment subfolders those can get messy rapidly.

All in all, I find Obsidian’s attachment handling (especially for in-line image embeds) not as intuitive as most other note-taking applications handle it. Most (Evernote, Bear, Apples Notes, OneNote, etc.) store the attachments “in the file” itself, which therefore becomes a container or package file. The example that everyone probably knows are the files embedded inside a .docx. Such behavior is not (yet) offered by Markdown natively.

However, I do fully understand that using Markdown as a plain-text markup language imposes certain limitations. And I can also see that some users embed attachments in multiple documents and will therefore find having a central attachment folder more useful than this proposal. Those options (1-4) should not be taken away, of course.
Yet, for me, this is a rare a use-case, and if so I would prefer to use transclusions to the parent note that contains the attachment instead.

Proposed solution

Since embedding all attachments in-line in the file itself (for example base64-encoded) is also not practical and breaks compatibility I would propose a fifth option to handle attachments:

If a file (image, pdf, etc.) is dragged into a note.md file in Obsidian the attachment should not be saved in a dedicated attachments folder as per the current options. Instead the note.md should be moved into a corresponding subfolder itself, which acts like a container: note.md/note.md. All embedded attachments of this note will then be stored in this very parent folder as well.

So instead of …

(The example uses option 2 with a specified global attachments folder.)

vault/
├── attachments/
│   ├── document for note1.pdf
│   ⋮
│   ⋮ (many more attachments)
│   ⋮ 
│   └── image for note2.png
├── note1.md
├── note2.md
├── note3.md
⋮ 
⋮ (many more notes)
⋮ 
└── note9000.md

… I propose:

vault/
├── note1.md/                           
│   ├── document for note1.pdf
│   └── note1.md
├── note2.md/
│   ├── image for note2.png
│   └── note2.md
├── note3.md
⋮ 
⋮ (many more notes with and without attachments)
⋮ 
└── note9000.md

Please note:

• note1.md/ is a folder that just carries the same name of the only contained note file, note1.md. The folder name includes the Markdown file extension .md. This is for the sake of consistency and to allow for easy differentiation to user-created folders (no .md suffix) and as a requirement for the related features below.

Related feature requests

• If a note gets renamed, both, the note and the folder name should be kept in sync in the file system.
  Example: note1.md/note1.md → note100.md/note100.md

• Folders, which’s names end in .md should not be sorted atop in Obsidian’s file explorer, but instead be treated like any other regular note. Clicking on it should open the contained note directly.

• However, a file explorer context menu option could be added to temporarily expand the note like a folder in the file explorer if the user wants to reveal the attachments that way. Yet, the contained note.md remains hidden at all times to avoid confusion. Due to the note being tied to its note.md/-folder and vice-versa this is also not necessary.

• Those .md-folders should also not appear as folders in the picker when creating backlinks, as well as in the outgoing links or backlink palettes, nor in the quick open dialog. Currently the .md file extensions of note files get omitted. Just like that the automatically created parent folder’s .md name suffix is also never shown in the UI. Generally the .md/-folder and it’s contained .md-note are treated like a single entity.

Example: Instead of …

… it should be displayed as follows.

Please note: The image attachment is displayed as a direct child of the note in the quick open dialog. The .md suffix of the folder name is hidden and so is the contained note file note2.md/note2.md.

This direct parent-child relation of parent note (folder) and attachment is significantly more useful than having all attachments end up in generic, (global) attachment folders.

This becomes especially evident in this example:

In contrast, with the attachments stored in the noteX.md/-folder of the corresponding parent note, additional information about the relation is conveyed. Especially for large vaults with extremely high note and attachment counts this relation becomes a useful way to structure the knowledge base.

• However, the user should additionally have the option to move an attachment “out of” the initial parent note and into a chosen location like a global attachment or any other manually created folder if desired. Just like it is possible right now. For example if the user already knows that an attachment will be referenced from multiple notes this could be handy. A simple context menu option could be provided to move the when right-clicking on the image or other attachment.

• This suggestions core idea, the aspect of treating the note’s automatically created note.md/-folder and its contained note file (note.md) should be carried out through the whole UI. That includes the wiki-style links for example:

Therefore instead of …

[[note2.md/note2]] or ![[note2.md/screenshot B.png]]

… the links are just displayed as follows inside of Obsidian, while the actual Markdown document (file system basis) contains the embeds as shown above for compatibility reasons:

[[note2]] or ![[note2/screenshot B.png]]

Comments

I am fully aware that this might seem like a hacky workaround to the problem that Markdown doesn’t offer file-embedding natively at first. Yet, so are the current options with more or less central attachment folders.

This proposed solution is fully compatible with any Markdown viewer to maintain 100% data-portability. Yet, it increases overall user experience and especially user convenience by treating dragged and dropped attachments more like traditional note-taking apps do. The main feature suggestion is that Obsidian would automate the creation of the note’s parent-folder and cover up the redundancy of the naming scheme by treating both, the folder and the contained note, as one entity throughout the entire UI.

I’d love to hear your thoughts on this idea that has percolated since I first Obsidian and experienced the friction regarding attachments.

Thanks a lot in advance.

[Nifty]

I too would favour an attachments-per-note arrangement option (this is also currently used by Noteplan, and would improve compatibility.)

The structure can simply be implemented by creating a subfolder named ‘noteFilename attachments’ (or similar) in the same folder as the note. The folders with the ‘attachment’ word suffix could be filtered out of Obsidian’s the file explorer if it is not desired that they be seen.

[Acon]

I just started using Obsidian as a Zettelkasten tool recently and always wonder how to keep the note portability when it comes to sharing or moving a note with all its attachments as a single unit, especially when you put all your notes in a single folder and all attachments in its subfolder called “attachments”, which is how I set up my Zettelkasten system.

Your idea is a marvellous invention and should be taken into the Obsidian development in my opinion. Hope the Obsidian team can take it seriously and realise this functionality. To me this is a must because portability and future-proofing are just the keys that make a note-taking app stand out in this competitive market.

Again well done @boettges!

Regards,

Acon

[Ocarinalover]

@Nifty

teplan, and would improve co

great idea but attachemnt overlapping between notes is hard to resolve

[habitats-tech]

What was proposed by boettges is what I have been manually doing for some time. It is a pain, but at least it works for me.

I would like to propose a slight variation which without obsidian coding cannot be achieved at the moment.

I would like to have an option for the default location for new attachments: “in subfolder named after current file”

So for example:

• folder1 - note1.md
  - note1 (this is where all attachments for note1.md will be saved, automatically handled by onbsidian if this option is selected)

optionally your could also allow someone to customise the folder name (e.g. {file-name}.attachments)

If this is something other people are interested would it make sense to move this post outside this thread standing on its own for people to vote?

[purplebrackets]

For me such a solution should be a core feature.

Having the possibility to decide if attachement are part of a note or a independent item.

For me, it should be considered as a part of a note.

I discussed that here: Related to Use the current note name in the attachment subfolder name - #38 by purplebrackets

[flyisland]

I’m not sure if you’re aware of it, but the note-folder-autorename plugin can be used to turn an Obsidian note into a folder, and is very useful for following the attachments-per-note strategy.