Capturing for Obsidian Using Drafts and GitHub

I’ve been a long time user of Markdown and have found it a convenient format in which to capture notes and documentation day to day. Utilising Markdown opens up a wealth of options for me in terms of capturing and processing content. I’ve been using Obsidian for a while as a repository for notes and I’ve been expanding my use into some new vaults recently, but as a cross-platform user I’ve been limited in my ability to easily capture thoughts when away from my desk. Until now. Now I have a solution that allows me to easily capture using Drafts.

Obsidian Syncing via iCloud

Capture via Drafts might not seem like a revolutionary idea, and it’s not. It is certainly possible to put an Obsidian vault into the Drafts directory on iCloud and export directly to it with a convenient action. Easy right?

Well it is great if you only want to use Drafts as Apple’s sand-boxing does impose a few hoops you need to jump through to try and save something directly. But what if you mainly want to use another app? What happens if you don’t have iCloud access everywhere you use your vault?

Well that last part if where I’m at. While you can use iCloud on a lot of platforms, there’s one where I need to access a vault where that is not an option for me.

Obsidian Syncing via GitHub

My chosen way to keep my content for a couple of vaults in sync across some disparate platforms is to take a less auto-synchronised and more scheduled-update approach. Obsidian now has official plug-in support and one of the plug-ins you can add to your set-up is the GitHub Sync plug-in by Denis Olehov, which makes it a trivial task; though you can certainly roll your own too.

This approach gives me a great version history too, which is something most other sync mechanisms would not provide. So while the sync needs a bit more of an eye to it, there is an additional benefit that comes from opting to use GitHub as the back end for the data.

But the other downside is that GitHub access on i*OS needs a little more effort than iCloud.

Obsidian and Working Copy

Anyone who works with GitHub on i*OS should have Working Copy installed. It is simply an outstanding git client for any platform, let alone a mobile one. Working Copy allows you to keep a copy of a remote GitHub repository on your i*OS device and is how I do in fact keep a reference copy around when I’m away from my desk.

Now, Working Copy does support automation through URL schemes and some fantastic Shortcuts integration, and since Drafts Actions also support working with Shortcuts and URL schemes, it seems an ideal match. While it is certainly functional, there’s a bit of lag with the whole round tripping through a secondary app when you have captured in Drafts. That’s time I’d rather not spend if I don’t have to.

Drafts and GitHub

Recently I updated the ThoughtAsylum Drafts Library (TADpoLe) with a new set of GitHub functionality. This allows me to push the content of a draft directly to GitHub within Drafts. After including TADpoLe, you can make use of a few lines of code to achieve this.

When you have the ThoughtAsylum Action Group installed and set-up, including TADpoLe in your own action so that you can use the library’s functions is as simple as including the action called TAD at the start of your own action.

I use the following JavaScript function in Drafts actions to enable that.

function addDraftToVault(p_strGitHubID, p_strRepoName, p_strDirectoryPath = "")
{
	let tg = new TadGitHub(p_strGitHubID);
	let objReturn;
	objReturn = tg.TA_fileUpdate(p_strRepoName, p_strDirectoryPath + draft.processTemplate("[[safe_title]]") + ".md", draft.content, "Upload from Drafts");
	if(objReturn.message == undefined) app.displayInfoMessage("Push complete");
	else app.TA_msgError(objReturn.message);
	return;
}

It takes my GitHub ID and the name of the repository that is hosting my Obsidian vault, and optionally the directory path within the repository in which the file is to be, or is already, located. When run from a Drafts’ action’s script step, it will put the current draft in the specified directory of the GitHub repository, basing the file name on the title (first line) of the draft.

If I had a repository named obsidian_vault for example, the full script step content would look like this for me.

function addDraftToVault(p_strGitHubID, p_strRepoName, p_strDirectoryPath = "")
{
	let tg = new TadGitHub(p_strGitHubID);
	let objReturn;
	objReturn = tg.TA_fileUpdate(p_strRepoName, p_strDirectoryPath + draft.processTemplate("[[safe_title]]") + ".md", draft.content, "Upload from Drafts");
	if(objReturn.message == undefined) app.displayInfoMessage("Push complete");
	else app.TA_msgError(objReturn.message);
	return;
}

addDraftToVault("sylumer", "obisidian_vault");

Within my vaults, I squirrel everything away into folders to avoid clutter and to allow me to keep some general structure to my notes even as they evolve over time. Anything that I am currently building out lives in the root of my vault. The root is effectively my inbox and ensures I can see at a glance what I have unprocessed, which I try and keep to a minimum.

Approaches with personal knowledge management solutions such as Obsidian tend to be quite individual, so if you need it to go to a particular folder each time, say inbox, you would just amend the call accordingly.

addDraftToVault("sylumer", "obisidian_vault", "inbox/");

Note the parameter is expected to have a trailing forward slash, otherwise the final directory will simply become a prefix to the file name.

Because I am using the update function from TADpoLe, as long as my Draft titles are unique, I can then use the same action to update the file if I need to apply an amendment, which is also highly convenient. I had considered using some timestamps in there to ensure uniqueness, but I found that being able to update an entry was more valuable to me than dealing with clashes of name - that’s just something for me to keep in mind when capturing content in this way. I did also consider utilising the draft UUID to ensure uniqueness, but that means more clean up at the triage point, so again that idea was set aside.

With this approach, I find the whole experience of capturing thoughts and notes to Obsidian smooth and very quick. It feels to me, for my particular set-up, the next best thing to having a native Obsidian client app that’s syncing with GitHub. There is very little, if any, friction.

Conclusion

For anyone who is using GitHub as their data store for Obsidian, I’d recommend trying out this approach. I find it so useful to be able to jot down some items, send it off to GitHub, and have them waiting for me to triage and process, right there in the vault root the next time I open up Obsidian on one of my desktop computers.

I can now also use a very similar approach to post to my various Jekyll web sites that I host on GitHub. As long as the draft is formatted in the correct way (front matter, tags, etc.), then I can push it right to the location I need in the GitHub repository and off it goes to be published, or more likely for me, dropped into a draft post folder ready for me to re-read, revise and schedule in publishing.

I hope that you do find the above useful, and that other Obsidian and Drafts users can get as much benefit from this as I do.