Yunus307 downloadsEmbed Proton Drive files in Obsidian notes.
Bridge between Obsidian and Proton Drive, built on the official @protontech/drive-sdk. This is an independent project and is not affiliated with, endorsed by, or sponsored by Proton AG or any of its products.
Early foundation: browser sign-in, optional session persistence, and Proton drive link embeds in reading view.
[!CAUTION] The Proton Drive SDK is still evolving and does not yet ship standalone auth. This plugin implements the same auth/API wiring pattern used by the official Drive CLI.
npm install
npm run dev
npm run build
npm run typecheck
Copy main.js, manifest.json, and styles.css into your vault's .obsidian/plugins/obsidian-proton-integration/ folder (or symlink the repo).
Supported embed types: images, videos, and documents (PDF inline preview, plain text, and markdown).
The plugin supports proton-drive:/// links -- a stable embed format based on Proton’s canonical node UID (volumeId~nodeId), not the share ID in a browser URL.
Why prefer these over drive.proton.me links?
shareId) from the web app..../shareId/file/nodeId) are legacy; resolving them uses deprecated SDK APIs (getNodeUid) that exist only for backward compatibility with the old web app.How to add one
volumeId~nodeId), and insert the embed; or
The plugin URL-encodes the UID in the path (for example, ~ becomes %7E).
Works for files in My files and the Photos library (your own volumes).
You can still embed My files items copied from the browser:

These rely on deprecated share-ID resolution in the SDK and may break as Proton moves to volume-based navigation. They do not work for Photos library items. Prefer proton-drive:/// links when you can.
Keep credentials in memory only: sign-in data is not written to Obsidian plugin storage; you sign in again after each Obsidian restart. Because Proton is known for its stance "Privacy by default", this is the default behavior.
If you would like your session to persist across Obsidian sessions, you can disable this option. However, please keep in mind that doing so will write your credentials to .obsidian/plugins/obsidian-proton-integration/data.json, unencrypted. Do not share this file, and do not add it to version control.
Client UID: the plugin also stores a random protonClientUid in data.json. This is required by the Proton Drive SDK to identify this Obsidian installation (for upload/sync state on Proton's side). It is not a credential, is not tied to your Proton identity, and is always persisted, even when "Keep credentials in memory only" is enabled. If you are not using session persistence, data.json contains only this UID. You can safely share it or add it to version control. Deleting it will cause a new one to be generated on next launch.
src/
main.ts Plugin entry, sign-in, embed registration
embed/ Proton drive link embeds (reading view)
settings.ts Settings tab
plugin-storage.ts Credential + client UID persistence
proton/
drive-service.ts ProtonDriveClient lifecycle
crypto.ts @protontech/crypto initialization
credentials.ts Session state
api/ Auth + HTTP layer (SDK prerequisites)
The SDK handles encrypted drive operations once ProtonDriveClient is constructed with:
httpClient — authenticated requests to drive-api.proton.meaccount — user keys/addresses for decryptionopenPGPCryptoModule — crypto via @protontech/cryptosrpModule — SRP auth helpersentitiesCache / cryptoCache — in-memory caches (SQLite later)This plugin identifies itself to Proton APIs as:
Per Proton's SDK usage guidelines, third-party apps must not use Proton branding and must disclose that credentials are entered into an unofficial application.
This project has used AI tools during development, and this section explains how.
During the early foundation stage, Cursor (Pro) was used to move quickly and explore implementations. Each change was reviewed manually to the best of my ability before landing. Going forward, the focus shifts toward slower, smaller changes; I expect the project's own stability to improve as a result.
That said, stability also depends on upstream: the Proton Drive SDK is still evolving and can change without much notice. This plugin cannot promise a stable or backwards-compatible experience anytime soon, regardless of how carefully changes are reviewed here.
For pull requests, I review every change myself first. After that, I also run GitHub Copilot code review on the PR. Those review comments are public on GitHub. I rely on this extra pass mainly because I am the sole maintainer of the project for now.
MIT