Fully transclude backlinks

I personally think it’s pretty important to show more than that line, because that means you don’t have to think as much about where you’re writing your notes - put them anywhere, and if they’re linked thoroughly they’ll get automatically embedded in all the pages they should be. Having just one line means you have to do much more clicking through to other pages, rather than having all the info aggregated right there
(and honestly, although I know it’s probably beyond the scope of the program, I would love to see as many outliner features as it can get away with without losing the markdown backend)


With regards to UIDs, although now we’re getting off-topic for this thread:
I imagine if it’s done programmatically, you could even have IDs generated on the fly for linked lines, rather than IDing every line. That is, the dialog would show all the lines, and then when you selected one to link to it would automatically append an ID to the end of the line and link to that ID. That way your files aren’t filled with unused IDs, but you’re still linking directly to the line so don’t have to worry about line numbers changing or anything as the file is edited

1 Like

That’s pretty much out I imagined it. The plugin auto-generates a UID format at the end of each line. Maybe there’s even an option to hide them in the editor too, so that’s not cluttered either.

I posted about that here and death_au had some thoughts on it you may find interesting.

1 Like

@Fovea it won’t get unruly to show nested bullets, if the default behavior is that the bullets are folded (similar to Roam).

But visual details aside, the more important point is how to get more out of bi directional links.

If you are in a note and can see in which context is it referenced in other notes, just by looking at the backlinks section, that would be a great advantage and as Conan said in his Roam Whitepaper, it will allow serendepity to blossom. (Currently the UX mandates that you go into each of the notes, to see in which context that note / concept is referenced).

@Silver @Licat I did some prototyping in python, by parsing markdown files and creating trees out of them and map to identify which nodes have a particular link.
Seems possible to actually implement this kind of thing in production and then get contextual backlinks out of it.
Worth a try…


I’d actually prefer that the current backlinks implementation show only the note titles. I agree that partial context can be unhelpful, and I wish that the backlinks panel either showed no context (just the title/filename) or much more context.


I think this is a pretty important feature. It’s making it hard for me to move from Roam without it.

For example, here’s how I’m doing my book notes in Roam. I have sub-categories of books, then tag the ones I want to read, with [[Books to Read Soon]]:

Then, I can see all the books I want to read soon, along with their titles and categories, in the “Books to Read Soon” page:

In Obsidian, this just shows up as titles, which isn’t useful at all:

This makes the linking feature much less useful in Obsidian vs Roam. I think the context is pretty essential for the backlinking feature to be useful.


Definitely agree about how it limits thing, especially in your use case.

I would say that this would be fairly straightforward with seeing the entire line a backlink appears on; that’s mainly a UI/display thing.

But considering you put essentially a tag(link) of “books to read soon” under the book title as a indent, I don’t know how Obsidian could know to pull up the line above the backlink.

How you’re using the indent there seems a feature outliners; being able to see/point to relationships in a indented list.

Maybe Obsidian could display a kind of “x > y > z” above the backlink if it’s in a list, that could get a bit of the context.

I feel you though. In a daily notes/inbox I’m always “tagging” metadata to my notes in a line under them or with indents to keep the main note “clean” (especially with specific titles you do) and that flow doesn’t work quite yet in Obsidian.

My workaround is, make a note/file for the title of a book, then anytime I want to add to that book, (regardless of location) write my note (“Sam Harris recommends”, “read soon”, “look into”, etc) & put links/tags (ie the book) at the end of the line of the note.

Then when I’m on the books page all those notes will show up as backlinks.

Likewise being on “read soon” will list every file title & line that link/tag is on.

1 Like

It’s clear if you navigate the Obsidian Help notes that context-rich backlinks are possible, but require the [[backlink]] to be embedded in a suitably descriptive sentence, versus a standalone bullet/heading. Something I have to think about when organizing my own thoughts - probably a good exercise :wink:

However, I do agree with @derekpankaew that backlinks would be so much more powerful if they incorporated folding - so we could selectively interrogate context. I would even like to see a certain amount of unfolding by default - so I can survey the landscape of thought before clicking off in a particular direction.


There is so much potential for backlinks to present in a more useful way that can fully incorporate with our markdown environment, without foundational changes. Incorporating some logic behind what’s presented and introducing some interactive elements in the backlink frame could probably satisfy most of our needs.

We’re not an outliner but hierarchy is often present

and can be easily parsed programmatically

  • The user should have an option to show page title as well as section title for backlinks. That may provide enough context for some users
  • Ordered and unordered lists have easily garnered context to work with as well. If a backlink is part of a nest relationship, the immediately superior and immediate child list items can and (optionally) should be shown. If a backlink composes the entirety of a list line that has child lists items, all of those immediate children should be shown.
  • Even though we are working with simple markdown, logical context is often available.

Interactive Components

  • There could be a expander buttons at the top of the Backlinks Window that expose 1, 2, 3 lines above and/or below every backlink in the window.
  • Each backlink could be presented in it’s own cell with expandable bars, much like we can expand rows in a spreadsheet. This feature could borrow from transclusion/embeds which are already implemented in Obsidian.
  • For any backlinks shown as part of a nested list, those nests could be presented as foldable.
  • For any backlinks that are either part of or parent of check-list items, we should be able to check off items directly from the backlinks window.

There are so many things we can do without messing with the basic markdown format we’re committed to. Though I personally love what would be possible if a backend feature introduced line UIDs like @Fovea suggested. The plugins that could be built off of that would be game changing!


I just want to add my support for the idea of providing more context in the backlinks where the structure of markdown allows it (ie the ability to show above headings and expand nested bullets). @goodsignal is there anything in the backlog to start to address this?

completely agree with @Caketray. Providing context on the backlinks is probably the single most important feature when making serendipitous connections between ideas. Having to go click through each backlink completely disrupts the synthesis process. It seems there should alot of ways to expand the context/expandability around the backlinks even within the constraints of markdown.

1 Like

Exactly. This is why, even though I have high hopes for Obsidian’s future and am a supporter, I still personally use Roam. I hope that this can be fixed somehow…


Wanted to chime in support of this. A useful MVP for this would simply be to take the next few lines if plaintext or list of bullets in the backlink search results. Don’t think it’s a super heavy operation but not sure how the system is designed. It’s really difficult to move away from Roam without this.


While I agree that Roam can be a source of ideas, I’d worry about Obsidian pursuing them generally rather than following their own vision. I think this is important with a potential flood of $15 refugees on the horizon. Conaw has explicitly said that cheapskate/low intensity users are a resource drain and there could easily be an increasing demand for Roam features. Some things will always be easier to implement on Roam, and vice versa. Commercially, being seen as a cheap super lite version of Roam would not be a good place to be.

There will be other competitors too. I think it will always be best if they follow their own vision and their own advantages rather than worrying about what features will persuade Roam users transition.

This isn’t a comment on transclusion. I’ve not fully thought that one through yet.


I’ve seen similar sentiment in a few places, so this prompted some thoughts I’ve had.

I sympathize and I want Obsidian to succeed and have a strong individual identity. I actually think most of the community here is pretty great at respecting the vision and values of Obsidian too, it’s awesome.

Which is why I don’t feel we need to be so wary of, “becoming a Roam clone” when people suggest elements that Roam (or other tools) have. There are features & UI design that bring value to people, if it’s technically possible & doesn’t infringe on anyone or the stated Obsidian values, then they should be encouraged & considered on their merit without being weighted down with fear of association.

The idea of the backlink search results showing the full line of text is a fairly subtle UI decision - conceptually speaking. It just so happens that Roam does this in a way that brings a lot of value to people. I don’t see how a fairly straightforward UI tweak like that warrants us needing to worry about Obsidian loosing it’s identity.

I understand the concern, but I don’t think it will happen because Silver & Licat are strong developers & the community respects the vision they’ve laid out.

We should remember the key values of Obsidian is flexibility/extensibility/personalization - as long as it is doesn’t break markdown and create lock in. It’s also about supporting & utilizing connections between ideas.

This is a Beta, plus networked writing apps are still fairly novel for most users in general - so this is the time to excitedly consider all kinds of feedback on how to get the most out of an app like this.

As for the refugee, if Obsidian brings value, then they’ll come, but if they bring some methodologies & habits that can work in Obsidian, then shouldn’t those be welcomed? Shouldn’t their transition be as seamless as possible?

Both commercially speaking to retain them as users, but as well as part of Obsidian’s values of personalization and imposing as few limitations to your note taking as possible?

Just some thoughts I’ve had on things, I know this is kinda long, so hopefully it doesn’t come off as rude or harsh.


Disagreement is fine and I do understand where you are coming from.
As I said, I don’t think there’s an issue with Obsidian picking up ideas from other places when they’re a good fit for the design and vision.
I also see no issues with anything added through plugins.

For the rest, although you are persuasive, I believe you are wrong.

There are two issues. The first is that time is urgently needed to develop the core vision. And it’s a very different core to Roam in being based on documents rather than a database. It needs to lever the document advantages rather than trying to imitate functions that come easily in the Roam database.

The second is about branding and the future. Conan is very clear that he’s positioning Roam on the high ground. It already has status and high profile adherents. He believes that the focus on intensive users will give the best feedback for development and a higher bang for buck in support costs. He recognises that all users are not equal.

Many current users are likely to be driven away by the initial pricing. If they come here, they are naturally going to look for the features they valued in Roam. Dynalist have a tradition of using user votes to drive decisions about feature development. This is where the risk comes. If that route is followed, it cedes primacy of vision to Roam with Obsidian playing imitator. And, when Roam reduces its price or users become wealthier, they will trade up by returning to Roam. Leaving behind the users who were the best fit for the Obsidian vision with a program that is not as good for their use as it might have been.

There’s a perfectly good business to be made out of providing a cheaper clone. But it only works if its designed to be that from the ground up.


Disagreement often drives innovation and is essential to better understand certain issues. Hence, I hope there is some benefit coming out of my hesitation to follow your reasoning here.

First, the perhaps second biggest selling point of Obsidian is its backlinking feature. According to supporters of the application who take the time to engage in forum discussions and (likely) want Obsidian to succeed, the feature is currently limited in the value it provides and, to some, not very useful in its current form. To me, this is a “core vision” issue and should not be outsourced to the realm of (third-party) plugin features. And, I would imagine, I am not alone with this.

Second, users ‘trading up’ or down is not as common as you suggest. While Obsidian uses local markdown files and the core of our data is actually our data, it still suffers from an effective vendor lock-in barrier. Few people using an as complex note-taking application as Obsidian would want to go through the work of moving their whole ‘digital brain’ around - and even fewer have the time for it (not everyone is a full-time university student). Something is always going to break/not be checked for completeness and no one wants to lose information if they can avoid it.

That said, Obsidian is not - and should not be - a Roam clone, I agree with you here. This does not mean that its value should be constrained by ignoring good practices of other knowledge-related applications out there, whether it’s Roam (as discussed), or for instance Evernote (e.g. robustness) or Amazing Marvin (note taking app with impressive customisation via plugins).

My apologies for this slightly off-topic post.


I have no issues with discussions about how backlinking can be improved. I do have concerns about any fixation on how Roam does it, or getting tied into the Roam conceptualisation of blocks (or any other such concept). What can be done efficiently with documents is not the same as what can be done efficiently in a database. I would prefer discussion about precisely defined use cases and unconstrained thinking about how those needs could be met.

Some people will always be better off in a pure database solution, even if they find Roam too expensive at the moment.

I agree that there are differences in what can be done for backlinks related to Obsidian being document/markdown based versus outliners/databases. That said - backlinks are certainly a key feature of obsidian and theres is certainly alot more context that can provided to the backlinks within the constraints of markdown. Developing this feature out does not make Obsidian a Roam clone. Backlinks just happen to be core to both products.

In addition to the suggestion of just providing more info related to text lines in the proxity to the backlink, headings and bullets are structured elements of markdown that should be leveraged here. It would be great to have @Licat or @Silver weigh in on any plans for further backlink context?


I agree. I vastly prefer the no-lockin model of obsidian and the ability to work with my files directly using other tools such as vs code but not having more context around the backlinks really reduces the utility for me at this point.