Please speak English on the forum. If you want, you can add a Chinese translation at the bottom of your posts.
10 Likes
I created a feature request that might be relevant for people who want/need block-level references. Itās not necessarily a replacement for blocks, but it might cover some use cases. It would be useful to be able to create links without having to remember which file or section has the content being referenced. If the links suggested at the moment of typing would include content, after selecting a suggestion, a link with the right location in the right file would be inserted, e.g. [[File##Header]].
In case you think that might be useful to you, please give it some love: Suggesting links based on content
Hi all,
This is a very good ādiscussionā going onā¦
Iād like to make some other suggestions reading all this:
- The idea of the atomic note is for me (personally) a building stone of a good PKM-system.
The remarks of @juvoni about Block Referencing and Block Transclusion (which are two very different things) were very insightful and got me thinkingā¦ - I tested some things and saw that when you drag a note from another vault into your current vault it creates a copy and references is with
in the current vault. I understand that this is linked to the āNew link formatā which is set to āShortest path when possibleā (correct me if I am wrong). - I also would like to add that I really like the idea of adhering to the MarkDown standards and the basic Obsidian Manifesto which is explained on the website.
I do understand people who want to have Roam-like features. My honest meaning (which I also read in some remarks) is that the makers of Obsidian should stick to their basic ideas and not give in to make a Roam ācloneā, which I donāt believe is going to happen seen what great suggestions come from the community.
That being all said (sorry for the long intro): - Would it be and idea to explore the idea of storing metadata in an Atomic Note (Zettle) and do Transclusion of the metadata Zettle into the Zettle/Note you want?
I need to do some testing here as I still donāt have a solution for Relative Path referencing which would keep your Vault easily transferable as we would adhere to the MarkDown standards. Again I donāt believe building proprietary stuff or Add-ons to achieve this will help the ecosystem in the long term. Obsidian is really great (and I mean that) but there is no one who can tell if some other even better system will emerge in the future (I doubt it but OK
). I also understand that some people āmixā different softwares to maintain their Second Brain. Not adhering to the MarkDown standard would be nefast for those people. - Another thing which I really like about Obsidian is the fact that you can freely edit your Zetlles in every outside system. I use this method a lot to add new block references when I am creating new research. This is something which Joplin does not allow at all so keep this great feature please!
Letās try and find a good solutions which adheres to the MarkDown standard and keeps the Obsidian Manifesto alive. In my honest opinion the makers should try and keep that also in mind when opening the Obsidian platform for third-party add-ons. Not saying you should build an Apple ecosystem with very strict rules and kick out everybody and everything you donāt like. I would nevertheless not allow add-ons which violate the standards and start creating MarkDown files that are not usable in other environments without first having to convert them to ānormalā again.
Looking forward to see a good solution emerging for this issue!
3 Likes
From what the devs have said I understand they wonāt go for block references. They have implemented links to headers (I personally use that a lot in combination with transclusions) and thatās it.
I am quite happy with their decision now that I have more experience with header links and transclusions.
1 Like
Hey @Klaas,
Thanks for mentioning this. I wasnāt aware of the new ādevelopmentsā.
Would you comment mean you are āforcedā with the H6-approach you also mentioned in the discussion or can you link whatever header you want?
From DIscord ā
Licat: āOfficially the core app will stay at heading level references. Once plugins opens up itāll be up to a plugin maker to implement block reference however they want with respect to syntax.ā
How block reference is done in an app called liandi:
āBasically the way block references are done is that Markdown is parsed into a tree of blocks, and the app assigns an ID to each block, which is saved in the JSON. The original markdown file is then discarded and the JSON is the new source of truth.ā
Silver: āI have heard potential plugin authors come up with solutions that do not require converting Markdown to JSON but instead add IDs inline, which may still play well with the other apps that understand markdown.ā
@Silver
Good remark on the āother Apps that understand MarkDownā. Goes with my latter remarks on keeping the ecosystem of add-ons clear.
Letting add-ons transform MarkDown in a way that other MarkDown systems wouldnāt be able to āunderstandā the files anymore is in my opinion the creation of proprietary format.
My opinion (personal meaning) is that such add-ons should not be āpromotedā in the Obsidian ecosystem or at least with serious caution warnings regarding portability and usability when working with different softwares.
3 Likes
Already sought out.
Works with every header.
Only remark:
You would need to know the name of the header ( 
).
Canāt we just display the available headers in the notes when #is typed in the [[ link?
@RikD: yes. So, you start with
-
[[, get presented with a list of note titles, - move your cursor to the one you want, but do NOT click on it,
- instead, type
#, which will result in a list of all the headers in that note, - when you have found your header, click on it.
Bonus: when you have followed these steps, you get an ugly looking ling like so
[[filename#headername]].
What you can do is after step 3 you can type | (= pipe character), then type a name for your link and it look like [[your chosen name]].
2 Likes
Hereās a video from the Foam developer with some interesting ideas about block referencing in markdown
5 Likes
This looks very promising, hope Obsidian is considering how they might do this in the future too.
Effectively adding a UID isnāt it? Licat has said heās not keen on that as a solution.
I think he anticipates someone addressing the issue when the API is out, possibly with a little database. As a plugin, users can choose to use it or not but the md remains intact. If someone produces a UID alternative, then they could choose that instead.
I think the option will come via a plugin.
2 Likes
That would be perfectly fine and welcome!
1 Like
I have seen Licat and/or Silver state explicitly that they will not implement block references, links to headers is as far as theyāll go.
1 Like
With the important caveat that itās likely weāll see multiple plugin options for block reference to suit everyoneās tastes!
Chant with me, everyone: API! 
API!
11 Likes
I have no idea if someone already proposed this since there are so many replies that is actually quite hard to follow.
Iāve seen many people obsessed over how Roam has an id for each block and then they use that id to be able to reference to a given block on a given note.
One way to work around that is to donāt use ids at all and hash the contents of the block instead. This is akin to how git or merkle trees store and addresses all pieces of content. If one changes the contents of a given block, then Obsidian can search and replace the references to the old hash with the new one.
Example: Letās say you want to reference a block on the note "Block Reference.md with the content of āObsidian does not need idsā. Imagine that the first characters of hashing that piece of content are ān01dsā (you donāt need the whole hash, the likelihood of collisions on a given note is very low). Then one could reference that block with something like this ((Block Reference#q2pm)). If I changed the content to āObsidian is awesomeā and that content produces the hash ā4ws0mā, then Obsidian could replace the old reference to become ((Block Reference#4ws0m)).
Regarding how to produce those hashes in the UI it should be fairly easy: Exactly like it does with headers, but instead of inserting the contents of the block it would insert the n first characters of the hash.
Solved! (or not, Iām just theory-crafting here)
3 Likes
Iāve been thinking about this on and off for years, more for the challenges it presents (when dealing with plain text files) than an actual need of the functionality. I always enjoy reading about different approaches.
How would you define the beginning and end of the block?
2 Likes
Hashing the contents of a block are what Iāve been advocating for, too, although I havenāt posted about it in this thread.
@macedotavares New lines? Or, my favourite option: require that users declare potential blocks as statements anywhere in a text, e.g., with ((double parens)).
Personally I think weāll see many solutions to blocks when plugins are possible, and thisāll be one of āem
3 Likes
Iāve always wondered why text paragraphs donāt have this kind of ID as a system-level option or default. It would be so useful in many contexts and apps. The overhead would be worth it IMO.