Bark and Distribution

A bark is a distribution campaign attached to one piece of content. It holds one item per platform you want that post to go to, and each item tracks its own schedule and its own outcome. This page covers what actually dispatches, what does not, and how to read the queue.

What auto-publishes today#

Every platform carries an automation status, and the queue refuses to dispatch anything that is not marked automated. That status is the source of truth, so this page lists what actually sends rather than what could in principle be connected.

Bluesky posts through the AT Protocol: a session is created, then a record, with link facets. Connect it on the site’s Platforms page.

ActivityPub is different in kind. It does not go through the bark queue at all. When a post’s status lands on published, the content controller enqueues a signed Create activity that fans out to the site’s followers, so people following your site from Mastodon or another fediverse server see the post in their timeline. Federation is a no-op when the site has no ActivityPub configuration.

Other adapters do exist in the codebase (Mastodon by instance token, dev.to, Discord webhooks, Telegram bots, Hashnode, Reddit link posts, and SMTP newsletter sends to your site members). They are wired to real APIs and the queue will dispatch them. Bluesky and ActivityPub are the two paths with the most production mileage, so use Test on any other connection before you rely on it.

Connecting a platform#

The site’s Platforms page is split in two:

• Deployment, where the site is published (Cloudflare Pages). See Publishing and Custom Domains.
• Distribution, everywhere content gets shared.

Connect platform opens a searchable list containing only platforms with a working integration. Each one asks for its own credential fields, which are stored encrypted. A connected platform can be tested (a live health check against its API) or disconnected.

Below your live connections, the manual platforms are listed read only with a “Manual” badge and a pointer to the copy kit, and the coming soon ones with a “Coming soon” badge. They are visible, never presented as connectable.

Creating a bark#

Open a post and scroll to its distribution panel. Tick the connections you want, optionally set a schedule, and bark it.

Scheduling works at two levels: one global schedule applied to everything you ticked, and a per platform override. A schedule is immediate, a delay, or an exact timestamp.

Delays exist because publishing to social before a search engine has seen the canonical page is the wrong order. Each platform carries a default SEO delay, and you can override the defaults per site:

Platform kind	Default delay after publish
ActivityPub, Bluesky, Mastodon, Twitter/X	30 minutes
Discord, Telegram, Reddit	1 hour
dev.to, Hashnode	2 hours
Newsletter	24 hours
Copy and paste platforms	none, you are posting by hand anyway

The Bark page#

The site’s Bark page is the whole queue for that site, with a platform filter and two tabs.

• Queue holds every item still pending, earliest scheduled first.
• History holds everything that reached sent, failed, or skipped, most recent first, with the error message for failures.

Deployment connections are filtered out of both views: Cloudflare Pages is a deploy target, not a distribution channel.

Item lifecycle#

A bark item is always in exactly one of four states, and each has an endpoint behind it:

• PUT /api/v1/barks/items/{item_id}/failed records a failure with an error message.
• PUT /api/v1/barks/items/{item_id}/skip marks it skipped, with optional notes.
• PUT /api/v1/barks/items/{item_id}/reset puts a failed item back to pending so it can be retried.
• DELETE /api/v1/barks/items/{item_id} removes the item entirely.

The bark itself supports create, get (with its items), rename, delete, add item, and a summary that counts pending, sent, failed, and skipped.

What runs the queue#

A background poller ticks on the server (60 seconds by default, configurable, and disabled in the test environment). Each tick it walks every site, moves due bark items into the distribution queue, and drains the queue through the real adapters. There is also a manual POST /api/v1/distribution/process if you want to push it along.

The copy and paste kit#

For the manual platforms, the distribution panel gives you a per platform copy button. It returns the post already transformed for that platform’s limits, with the canonical URL back to your site, ready to paste. It is not a fake integration and it does not pretend the post went anywhere: you paste it, then mark the item sent if you want the history to reflect it.