Block reference

One way to execute this might be via search. The transclusion command, {{transclude:note_title§paragraphstart}} or whatever, would search in note_title for a paragraph beginning with paragraphstart and insert the relevant paragraph. This kind of syntax would keep the text readable and interoperable, and wouldn’t demand anything extra of users such as adding IDs.


Great example. The next simple step would be break/split [[Matthew 28]] into sub-files so the first reference (if clicked == you care enough) to [[Matthew28 #18]] results in separate #18 just for the block and it get included into [[Matthew 28]] with the ![[Mathew 28 #18]]. Use preview to see the whole thing or drill-in to edit. [[Matthew 28 #18]] obviously starts with a # or ## etc depending on the level.

1 Like

Thank you. I read your post at the beginning of my search journey and lacked the understanding of what your suggestions meant. It makes much more sense to me now and this would be, at least in some scenarios, an option until a final decision on this is made by the developers.

1 Like

I think that many of the issues mentioned in this thread are down to old habits and Obsidian not being fully developed yet. And it’s important to bear in mind the advantages and disadvantages of database versus document based models.

Some of the issues are about display - showing lots of documents on screen in card form, makes an overview easier; should be possible and I assume someone will write a plugin sometime. If you look at Scrivener, it’s quite easy to write a long document in small chunks and see chunks separately or the document as a whole. I don’t think that’s quite possible in Obsidian because I don’t think it has the concept of child notes, thoughit does have the file explorer sequence. Traditionally in outliners each new point is a ‘child’ or ‘sibling’ of the previous point and that relationship is retained unless deliberately changed.

I’m not convinced of the need for block references like Roam. Seems to me that there are many ways to tackle this perceived need, some of which are well suited to a document based system.

Thinking… , :star: :star: :star: :star: :star:

There are two problems with this approach. The first one is that it assumes a pure, 100%, contents-only atomic note. The second one is that it creates a couple of extra steps . Expanding on the two problems below.

Atomic notes are not atomic: As mentioned here. Take this very example. Let’s say I have an atomic note that says “Atomic notes are not really atomic, for they have some kind of meta data added to it in a Markdown-based systems like Obsidian”. I would like to add at least two elements to this note: where it came from and other related notes. If I add these bits of information, my so-called atomic note is no longer atomic. It bears not only the content itself, but other information. If I reference this note (by transclusion, for example), I’d also be including its meta data and the links to related notes, which I may not want to do if my interest is only on the core of the note itself.

Extra steps: We are interested in doing exactly the opposite of creating extra steps. Adding extra steps is taxing on ones cognitive system, which degrades understanding and learning. This seems a too expensive side effect. Taking the extra steps argument to the limit, Obsidian itself is not needed. For one can always implement atomic notes in an analog index card system and achieve great results. Luhmann’s intellectual production is a demonstration of that.

In summary, although it is possible to create (cognitive taxing) workarounds and in spite of the technical challenges of developing a block reference system on top of a plain Markdown file structure, it is possible and useful to develop some kind of block reference in Obsidian.


If you like the Roam approach so much, why not simply use Roam when it’s clearly not straightforward to add this feature to Obsidian.

I’d also disagree about the cognitive tax. It’s taxing if it requires a habit change because you are coming from another system, but otherwise it’s minor.

As a separate point there is a recurrent tension between users wanting a more reflective Luhmann type approach, and those pursuing a high number of outputs as in GTD etc. Your comments suggest that you’re more in the second camp?

1 Like

I don’t think it’s a Roam-specific feature, per se, although Roam popularizes it. Before Roam, I already was doing citations to specific paragraphs in my notes written in other note-taking tools. Particularly when I am writing a long train of thoughts that incorporate points made in paragraphs from other notes, the switching between notes exhausts me.

The reason I switched to Obsidian from Roam is because the cost of Roam doesn’t make sense for me. I like Obsidian the way it is, but I don’t think people advocating for block references are doing so due to their habits formed when using Roam, but rather from a position where they the benefits of such a feature.

If you would like to argue that, the habit change which is equivalent to forsaking the pursuit of block references, would actually benefit the users in the long-run, as opposed to increasing cognitive load as discussed above, I’d be interested in hearing that.


What would be wrong with a very simple system of markers to mark the block, that either include or exclude the ##header that identifies it? So you could have, for example:

{{ ### My awesome quote
My block text


### My awesome quote {{
My block text

In either case, you would include this elsewhere as

![[my_file#My awesome quote]]

Obsidian already supports this form of header-level referencing, I believe. The first form would include the header/block name in the transcluded text, and in the second case would skip it. I understand that the goal is to stay as close the standard markdown as much as possible, but [[ ]] is already non-standard. This seems to fit the philosophy of link as first class citizen even if it introduces a small deviation. And it looks not entirely unlike a bit of LaTeX or json code with the use of delimiters to mark out a region for special treatment, which is probably familiar to this community.

I’m not a fan of all the hidden line IDs or other mechanisms, which seem complicated. Better to mark and name the block, which will still work if you add, remove, or shuffle other things in the file, or change the contents of the block itself. Would also be obvious in non-Obsidian markdown editors that this block was marked and named for a reason, and wouldn’t be too visually offensive.


afaics Roam keeps all your notes as a single dataset. The block is a key concept in design and optimisation of its database. This makes it fast and flexible working with blocks.
Obsidian is a database working with notes held in separate document files. Links to Documents and Headings are straightforward because they are native features of those documents.
I don’t see how it can ever process blocks as effectively as Roam.

The downside for Roam is that it’s stuck with blocks, just as Obsidian is stuck with documents. There are many ways of thinking about working with sections of text. I think it would be most useful to consider the detail of various needs rather than talking about blocks.
For instance, doing textual analysis there may be a use for analysing portions of text, where the portions may overlap. Neither Roam nor Obsidian have an elegant solution to that right now- multiple links to the same word require a different solution to [[ in the original file. I think Ryan is right in his approach, though the program would need to heavily tweaked to make it fully effective. Micro plaintext files are managed very effectively in all OSs. A selection that created a new linked file could work with any and all portions of text - but there would need to be an effective way of displaying them in the original document.


@greasemonkey I try to not look at this as a difference in opinion because that can shut us off from finding something of value in what the other is saying - like 99% of internet talk I suppose :slight_smile:

This discussion allows some people to already find a partial solution that can work for them right now, which is great on its own.

Then others can share why exactly it won’t work for them and this is extremely valuable because let’s face it: there’s a lot of smart people here and those tend to have difficulties dumbing things down, as in their minds the problem is THAT obvious, it’s hard for them coming up with words to fully describe it.

There’s some great insights shared so far by both yourself and everyone else who posted.

For example based on your multiple uses of the words “friction” and “pulling” blocks, I now wonder how people would feel if the problem on how to STORE blocks got solved but we would then always need to type in order to RETRIEVE a block when including it in another page.

Would such a solution still carry the same amount of friction? In other words, when you refer to “pulling blocks”, is it the act of dragging and dropping blocks between documents which contributes to the feeling of efficiency?

Then back to the other side of the coin on how to actually store the blocks in the first place:

I’m sure eventually people will develop multiple flavors of plugin solutions as some want bullets, others want paragraphs, others just lines, etc… and those plugins will be a good fit covering those specific needs.

The risk is with other people not fully understanding some of the intricacies these plugins will bring along when they require storing foreign block indicators inside markdown files.

Everybody can of course accept that risk when using such plugins but nobody wants to see theirs or someone else’s life work get mangled due to the inner workings of a plugin conflicting with another app and/or human error update.

That’s why a fully portable and truly robust solution which can be safely distributed to a wider general audience will most likely need to stay closer to the Obsidian foundation using plain markdown documents.

I’m not a developer and don’t care much for markdown - so don’t know this suggestion is of any use at all, but maybe we need to look closer at using plain markdown without requiring extra foreign indicators in the file?

For instance by using a simple numbered list.
A plugin could validate numbered lists ensuring they are sequential and unique within the document(header). Then couldn’t that regular number be used as the block ID?

Something along those lines would feel more robust to me, easier to comprehend for the average user as well, be portable, and if something does get mangled wouldn’t require the SpaceX team to come in to fix your files.


To piggyback on @ja_rule’s suggestion, one way of referencing blocks that currently exists is to enclose text in an h6 (######) ‘block’:

###### If you dislike folding
If you dislike folding for whatever reason, it can be turned off in Settings.

###### A really great quote
> Obsidian rocks!
> \- Anonymous

The second ###### acts as a terminator to delineate the block.

Then use obsidian.css to hide h6 (whoever used an h6 with a straight face though, really?):

h6 {
    display: none;

Using the first few words of the sentence/block in the h6 heading works nicely when autocomplete kicks in during link creation (as opposed to using something like an ID).

I’ve never had the need to ‘title’ a block reference, so it seems fine for my use that the h6 is used as a reference, but never rendered.


Hi all,

I’ve used Roam for almost half a year now and I used block references very heavily. However, I played around with Obsidian a tiny bit and I liked how polished it is. I think that except for the lack of block references and a scratchpad, it fulfills almost all of my needs. Block references are really important to me, because people were quickly overlooking the power of block references, I made a quick video to showcase how I use them.

Here’s a review of Obsidian that I shared with my peers at Roam’s Slack

So I hope you can believe me when I say I’d really like to see a block references solution in Obsidian. I can leave the scratchpad feature aside.

While browsing this thread, I saw some clever solutions.

If I want to reference to a passage of text, I could just create a third page where the “block” lived and then reference it in both pages (the original one and the referer). Automating this via highlighting a passage of text and having a shortcut that will automatically create a page with a name that shows where it came from and copying the path to the clipboard would be fantastic (so that I can just go to the referer page and paste the reference).

However, the only issue left would be how embedding is displayed. In Roam, I can put a block reference inline with other annotations. In Obsidian, references take their own line and disrupt the outline of the page. If it was possible to choose to make an inline embed, it’d be great.


the only issue left would be how embedding is displayed. In Roam, I can put a block reference inline with other annotations. In Obsidian, references take their own line and disrupt the outline of the page. If it was possible to choose to make an inline embed, it’d be great.

Good point, and a good solution. Mind making a separate feature request for this so that the devs can see? If not, I can do it!


Having been thinking about document possibilities, my preferred solution would be:

  • Select text with option to make it a separate linked document - right click or keyboard shortcut
  • To accommodate the possibility of multiple overlapping links, to have a forward links pane
  • To avoid too many [[s to simply underline the text that is linked
  • And put a list of the forward links somewhere out of sight such as YAML front matter, so that the integrity of a pure document system is preserved.

I think this could even be done as a plugin since it only automates functionality that is already present.
It’s also infinitely flexible.
To perfect zettelkasten usage, the initial name for the new linked notes could be the date/time stamp.

I know that some have argued in favour of long documents, but Roam works in blocks - they’re just hidden in the presentation of a single document.


Well the ideas in this thread have convinced me - after working a while trying them out I’ve come to the conclusion I can accomplish my goals using the ability to transclude headers in Obsidian without additional block addressability. It has a little more friction than I’d like but not so much that it impedes my workflow. Given that the markdown centric approach is a key value point in my adoption of the tool it seems I need to accept the tradeoff…Thanks for all the great discussion - the community associated with Obsidian is a great reason to be excited about where the tool is headed.


Just a small correction: Obsidian is not specifically, or only, a zettelkasten app. It is a note-taking app that can be used as a zettelkasten if one desires it, but it is not a sine qua non.

I have been referring to some outspoken Zettelkasten (or, rather: atomised notes) supporters in this thread/forum and did not intend to imply that Obsidian had to be - or was only allowed to be - used in such a fashion.

OK, I misunderstood you. My apologies.


+1 on this feature request. There might be a way to make this happen now with a lot of custom CSS.