Background & Context

Obsidian has become the writing environment of choice for a growing number of developers, bloggers, and knowledge workers who value local-first, Markdown-based notes. But Obsidian is a writing tool, not a publishing platform — and the gap between "finished note" and "published post" typically involves at least two manual steps: pushing content to a CMS and separately posting to distribution platforms.

The IndieWeb community has long advocated for a solution: POSSE (Publish on your Own Site, Syndicate Elsewhere). The idea is simple, publish the canonical version on your own domain, then syndicate copies to the silos (Dev.to, Mastodon, Bluesky, LinkedIn, Reddit), with every copy linking back to the original. This keeps the domain authoritative for search engines while still reaching audiences where they are.

No existing Obsidian plugin implemented POSSE end-to-end. POSSE Publisher was built to close that gap.

Problem Statement

The Question: How do you implement the POSSE publishing pattern without leaving the Obsidian writing environment?

The Problem: Content creators using Obsidian must break out of their writing context every time they publish, copy-pasting to a CMS, then manually cross-posting to each distribution platform, with no record inside the note of where it's been syndicated. Content published directly to silos (Medium, Dev.to) becomes owned by those platforms, indexed on their domain, and disconnected from the canonical version on the writer's site.

The Challenge: Building a plugin that handles multiple destination types (custom REST API, Dev.to, Mastodon, Bluesky) behind a single interface required writing type-specific payload builders and credential flows for each platform, without letting the complexity leak into the user-facing settings UI. Supporting Obsidian's own markdown syntax (wiki-links, embeds, Dataview blocks) meant the plugin also needed to preprocess content before it ever hit an external API.

Methodology / Approach

The plugin was built in TypeScript using the Obsidian plugin API and bundled with esbuild for a zero-dependency runtime footprint. Each destination type, custom-api, devto, mastodon, bluesky, has its own credential configuration and payload adapter, but all destinations share a common buildPayload() method that handles frontmatter extraction, slug generation, and Obsidian syntax stripping.

A shared markdownToHtml() converter handles platforms that require HTML bodies; markdownToPlainText() strips all Markdown syntax for character-limited platforms like Threads and LinkedIn.

Syndication tracking was a design-first decision: after a successful publish, the plugin writes the syndicated URL back into the note's frontmatter under a syndication: field. This makes the note the permanent record of where its content lives across the web, eliminating the need for any external tracker.

The settings UI was built to scale, adding a new destination type requires only a new credential block in the settings tab and a new adapter in the publish flow. The destination picker modal handles the "multiple destinations" case, keeping single-destination users on a fast path.

Analysis and Findings

Four design constraints emerged early:

Canonical URL is the load-bearing concept. Without a stable canonical URL, syndicated copies have nothing to link back to. Every payload now includes a canonicalUrl field, either from explicit frontmatter or auto-generated from the configured base URL and the post slug. Getting this right required fixing a bug where the field was ignored even when explicitly set.

Frontmatter must be the single source of truth. Users shouldn't need a separate dashboard to know where a post has been published. Writing syndication URLs back into the note's own frontmatter was the right architectural call — it keeps the note self-describing and makes the data portable.

Obsidian's markdown is not standard markdown. Wiki-links ([[Page Name]]), embedded notes (![[note]]), Dataview blocks, and Obsidian-style comments (%%text%%) all need to be stripped or converted before content reaches any external API. This preprocessing step is configurable but on by default.

Auto-publish on save is a power feature that must be safe by default. Triggering a live publish on every save would cause rapid-fire API requests while a note is being edited. The implementation debounces by 3 seconds and restricts auto-publish to notes with status: published in frontmatter — drafts are never auto-published regardless of settings.

Solutions and Implementation

Version 1.0 - Private Publishing Tool

The plugin began as a single-purpose tool: push a note from Obsidian to a personal site's /api/publish endpoint. Core features included multi-site destination support with a picker modal, three publish commands (publish, publish as draft, publish live), full YAML frontmatter parsing, auto-slug generation from note title, upsert-by-slug behavior on the server, and Obsidian markdown preprocessing.

Conclusion and Lessons Learned

POSSE Publisher shows that a writing workflow can be made publishing-native without adding friction. The key architectural decision was treating frontmatter as the permanent record, not just input metadata, but the output log of every successful syndication. That choice made syndication tracking feel natural rather than bolted on, and it kept the plugin's data model simple: the note knows where it lives.

The evolution from a private single-site tool to a public multi-platform plugin also illustrated a useful heuristic: solve your own problem completely before generalizing. Version 1.0 was built entirely for personal use. The POSSE rebrand happened after the core behavior was stable and the value was clear, not as upfront product design.

The biggest remaining challenge is completing the syndication adapters for Medium, Reddit, Threads, LinkedIn, and Ecency. The settings UI is already wired; the remaining work is writing and testing each platform's API integration.