Intro
Do you know what I mostly love about Obsidian? The plugins market.
Do you know what I mostly hate about Obsidian Publish (and every other type of SSG)? The lack of plugins.
Wouldn’t be great if we could combine these two things together? Wait, wait, it’s not what you are most probably thinking right now. What I’m proposing here is a more frictionless way to do what we can already do to make it simpler and (in a way) more widely available. What if we could bring a site INSIDE Obsidian?
Little Disclaimer: Everything I say here is the product of my imagination and little knowledge; I cant’ say if it is doable in reality given the limitation of: React, Typescript, Obsidian API…
Basic Idea
If out goal is to have plugins working on our sites, we simply need to force the developers to make them compatible with every browser, every SSG, Obsidian Publish… It sounds totally bonkers! They have already code them to work great on Obsidian so why should we make them do everything again for another platform? We should bring the readers to our Obsidian vault, not make them go to an half-baked site. If there is something I find really sad is visiting amazing Digital Gardens/Vault to find find notes with un-rendered Dataview tables, un-rendered Excalidraw links or the impossibility to use the powerful Omnisearch.
At the core, to make the vault accessible to everyone, it needs to be publicly hosted on an online database: it’s inevitable. The best option here would probably be GitHub with its powerful API and rich community. To connect it with Obsidian, you can use Obsidian Git and upload the vault you want to share to a repository with relative ease.
How could then someone bring your repository/vault inside their Obsidian? You could say by using Obsidian Git again or a manual process but no: the best way is by using this plugins. If you want to consult a public vault, you would simply need to download this plugin, enter a code and voilà. No complicated configuration or setting-up.
Actuation
Backbone
In my mind, to make the plugin work you could use the powerful GitHub API to call a HTTP request to download a specific repository. In that case, the code a reader reader would have to input inside the plugin would be the repository link. I don’t know if with this method it’s possible to perform a complete pull request and not simply download the entire repository every time a change to the repository is made.
What I know is that I don’t want, at all cost, to rely on Git: it’s a extra complication to the process (part of the motive why Obsidian Git is a less favorable tool).
Complete Reader Workflow
- Download and Install Obsidian
- Create a new vault
- Disable the “Safe Mode” and install this plugin
- Find the code of the wanted vault shared by the publisher
- Enter it inside the setting of the plugin and confirm it
It should be pretty straight forward for anyone, even more for whom who already have used Obsidian. No other steps or programs should be required to access a publisher vault.
Complete Publisher Workflow
- Upload the vault to your publicly available GitHub repository. I would recommend using Obsidian Git to do so.
- Make the code the readers are required to enter available
-
Facoltative:
- Write a “.md” file, formatted like a “.json” one, containing the settings that the publisher decide to apply on the downloaded vault. If not done, the default setting would be used. This file would be interpreted and executed by the plugin once a public vault is downloaded/updated. This file could enable the publisher to choose if, for example, a reader could:
- Change the theme of the vault
- Add new plugins
- Access “Edit Mode”
- Add new notes
- Use the “File Explorer” core plugin…
- Write a “.md” file, formatted like a “.json” one, containing the settings that the publisher decide to apply on the downloaded vault. If not done, the default setting would be used. This file would be interpreted and executed by the plugin once a public vault is downloaded/updated. This file could enable the publisher to choose if, for example, a reader could:
A publisher would not need to have this plugin installed because, in reality, what Offline Publish does is downloading, not uploading.
UI & Settings
Basic
In the most simple case, the “Plugin Settings” tab would require:
- Code (String input box): Where the reader would put the code of the vault to download.
-
Auto-Update (Boolean selector): This setting is a must. You want your reader to how control on their internet connection and not download files on any internet network.
- On: Every time this vault is open a pull request is performed. This setting would more closely mimic the functioning of a site.
- Off: To update the vault, the user would need to call a command from the command pallet/hot-key.
Here is a little mock-up:
Advanced
I would like to add this option to the “Plugin Setting” pane:
-
Overwrite (Boolean selector):
- On: When a pull request is done, if the files to overwrite have been modified by the reader (if (s)he is allowed to), the plugin won’t overwrite them but would instead download their updated version with a different name and updated the outgoing links.
- Off: The synchronization produce a clone of the repository.
For make the life of a publisher a little easier I would also like to have, on a different tab (invocable only using a command, so not to clutter the otherwise clean and simple “Setting” pane - so it doesn’t confuse a reader) a little “.json setting file” creator, like the “Button Maker” you can find in the Buttons plugin. There, with simple boolean selector, a publisher could see and select all the wanted feature mentioned in the [[#Complete Publisher Workflow]] . When confirmation is given, the pane would close and a rightly formatted setting file would be created.
One last advanced little feature would be having a little indicator on the “Status Bar” that, by changing color/icon or by hovering over, would tell the reader the status of the vault:
- Offline.
- Not synchronized.
- Synchronizing right now.
- The vault is updated and the date+hour of the last performed synchronization.
Here is a little mock-up:
Pros & Cons
-
Pros:
- Plugins: Every Obsidian plugins is accessible and usable.
- Personalization: The publisher could bundle custom themes and use plugins like Hider to add a little more customization to the user experience. (If allowed) the reader could also spice up the vault and, instead, add his/her little spin with, since we are dealing with notes like any others.
- Internet: An internet connection is require to use this plugin but, after all, you would also need to it to use the site counterpart. Only with the first method though you can continue reading it (after the initial download) even without a connection.
- Simplicity: Everyone who at least know of Obsidian could be able to setting it up. The “Complete Reader Workflow” is as simple as it gets.
- Reliance: As everything else uploaded to GitHub, your vault would benefit from features like: versioning, cooperation, server stability…
- Independence: This system would only rely on Obsidian and GitHub: as long as they are up and running, this system should work. No other third-party pieces of code or databases (like in Sekund) are required, not even Git (I’m looking at you Obsidian Git).
-
Cons:
- Download: You need to download the entire vault to freely read it. However, as far as I’ve seen, even the biggest vaults don’t require that much space (images and videos aside).
- Advanced Features: Full-fledge sites with many JS libraries, complex CSS and a PHP (or similar) backend are not possible in Obsidian per-se. However, from what I’ve seen most of the published vaults out there are created using SSG, so they already don’t have those functionalities. To mitigate this hole, embedding or using Custom Frames could improve the situation.
- Device Bonded: Since you are downloading a vault, if you want to access it, Obsidian must be installed on that device. If no multi-device synchronization is done, every personalization would be lost are lost between devices.
- Difficulty of Reach: Even though this is the easiest way I could think of, it cannot beat the easiness of tapping on a link and having everything at your disposal: no previous knowledge or setting-up required. By publishing your vault using this method, you would most probably NOT reach those people who have never heard of Obsidian and are not willing to dip their toes in.
- Security Concerns: As for every other piece of code you download - plugins included - there are some security concerns in doing so. Loading a site is most often safer than downloading an entire vault. However, one of the perks of using GitHub is that everyone can check the content of the ENTIRE vault before committing and saving it on a device. Open sourcing is cool.
Conclusion
I think, if all of this is technically possible, it is an elegant and simple option compare to the hassle of designing and setting up a site or buying the, at the moment, incomplete Obsidian Publish. By developing this tool, we could tackle some of the problem that afflict the “Obsidian Publish Market” (what a high-sounding name we have here).
If you haven’t yet notice, this post is in the “Plugins Idea”, I know something about programming and I like to thinker but I definitely don’t have to skill to pull this off. I would be really grateful to anyone who might be willing to have a shoot at this; in that case: hit me up, I would love to help you out in any way I can!
Thanks for listening to my Ted-Talk, that was quite a long rant. Have a great day.
Post Scriptum
- The name of the plugin is a work-in-progress, as everything else is.
- Cheers to every plugins I mentioned in this post: I love you all.