Google Docs auth: a deadend, logged honestly
File-Transporter (then 'google-docs-api-plugin') was initialized to bridge Obsidian and Google Docs — and within hours hit a wall on Google's auth flow that stopped the project cold. The two-commit history reads init → deadend on the same day. Filing it retrospectively because building in public means logging the dead-ends too.
Michael StatonMusic Editoraugmented with Claude Code on Claude Opus 4.7 (1M context)Why Care?
Most changelogs you read are about wins. The rest of building actually looks like this: you initialize a project with a clear goal, hit a hard block on the platform's auth model, and walk away to come back later. Filing this retrospectively because the splash page for content-farm needs an honest history — including the projects that didn't yet work.
If you've ever fought Google's OAuth flow inside an Electron app that doesn't have a public redirect URL, you know exactly what shape this dead-end was.
What's New?
(All historical, captured retrospectively. Both commits same-day.)
init(project): initialize project Google Docs api integration to Obsidian— manifest, package.json, scaffold, intent set: round-trip files between Obsidian and Google Docs.deadend(auth): google docs authorization not working— the work hit Google's OAuth requirements head-on and stopped.
The arc
The premise was simple: Obsidian users want to keep some files synced with Google Docs. Pull a Doc into the vault as a markdown note, push edits back. There's no shortage of Obsidian users who would use this.
The premise hit reality at the auth layer. Google's OAuth 2.0 flow requires a redirect URI. An Obsidian plugin running locally inside Electron does not have one. The workaround patterns — local loopback, device flow, copy-paste-the-token — each have caveats Google has been progressively tightening.
We logged the dead-end honestly and moved on to projects that could ship. File-Transporter has been waiting for a viable auth strategy ever since.
What this enabled
It enabled a name change. In May 2026, as part of cleaning up the content-farm pseudomonorepo, the plugin got the new on-disk name file-transporter to reserve linguistic space for "round-trip files between Obsidian and [any source]" — Google Docs being the first attempt, not the only one. The GitHub repo is still google-docs-api-plugin.git until we rename it.
If a future iteration wants to revive this, the path forward likely doesn't go through Google Docs API + OAuth at all. Options worth considering:
Drive API + simpler scopes — reading a folder's contents as Markdown might fit the device-flow pattern Google still supports for "limited input" devices.
Pandoc bridge — export from Google Docs to .md client-side, watch a folder, ingest. No OAuth from the plugin.
Different source — Notion, Coda, Bear, Apple Notes. The "transporter" name is intentionally provider-agnostic.
Retrospective notes
Written 2026-05-04, eight months after the dead-end.
Logged honestly because the changelog conventions skill explicitly says: "Embarrassments and bugs can be discussed honestly — that's part of building in public."
The deadend commit message is one of the most honest commit messages in the farm. Worth preserving.