cose: a browser extension that syncs one article to many platforms

Create once, sync everywhere

cose is a browser extension for the doocs Markdown editor, and its job is stated in one line in the README: it supports publishing an article to multiple content platforms with one click. The name expands that idea, Create Once Sync Everywhere, and the badge row carries it as the project's tagline.

The pairing matters. The extension is not a general purpose publisher, it is built to work with the doocs Markdown editor, which is a browser based editor. The usage flow starts by opening the editor either at the hosted address, md.doocs.org, or a local development environment, and the publish button in the editor is what triggers the extension.

That is a much narrower and more useful product than a general publishing tool, because the hard part of publishing the same article in several places is not the copy and paste, it is that every platform has its own editor, its own formatting quirks, and its own login. The extension does not try to be a Markdown converter for thirty different dialects. It opens the platform's own composer, pastes into it, and lets the platform's own page do the rendering.

The project is under the doocs organisation, the primary language is JavaScript, the last push was on 2026-10-17, and the releases are v1.3.6 from 2026-06-01, v1.3.5 from 2026-05-20, and v1.3.4 from 2026-04-29. The licence metadata records Apache-2.0, while the badge in the README says MIT, which is a small mismatch to resolve in the licence file.

It is distributed through the Chrome Web Store, and there are video walkthroughs on Bilibili and YouTube linked from the README for people who prefer to watch the flow rather than read it.

Five steps from draft to published

The usage section is a numbered list, and it is short enough to quote in full because the order carries the meaning.

You install the extension from the Chrome Web Store, then open the Markdown editor at md.doocs.org or in a local development environment. You edit the Markdown content. You click the publish button in the top bar. A dialog appears in which you select the platforms to sync to. You click the confirm button and the sync begins.

The order is what makes the tool work, and the fourth step is where the real decision happens. The extension is not pushing to a fixed list, it is asking which destinations this article should go to, which matters because a technical post might go to three developer communities and a product announcement might go to a different set entirely.

The fifth step is the interesting one, because the work is not instantaneous. The extension is interacting with third party sites in a logged in browser tab, which means each destination is a page it drives rather than an API it calls, which is also why the login state detection in the feature list is a prerequisite rather than a nicety.

That design decision, driving the real pages instead of calling private APIs, is what makes the tool work across platforms that have no publishing API and no incentive to provide one, and it is also what makes it slow and what makes it break when a platform changes its composer. Both are consequences of the same choice.

The platform list and its letter quick reference

The supported platform list is the substance of the project, and the README keeps it in a collapsible quick reference table organised by the first letter of the platform, which is a very Chinese convention and a very practical one when you are looking for a specific site in a list of more than thirty.

Under A there is the Aliyun community. Under B there are the Bilibili column, Baidu Cloud Qianfan, Baijiahao, and CNBlogs. Under C there is CSDN. Under D there are Douban, Elecfans, and Douyin articles. Under H there are the Huawei developer articles, the Huawei Cloud blog, and the Volcano Engine community. Under I there is InfoQ. Under J there are Jianshu, Juejin, and Toutiao. Under K there is OSChina. Under M there are Medium and the ModelScope community. Under S there are SSPAI, Sohu, and SegmentFault. Under T there is Tencent Cloud. Under W there are NetEase, Weibo articles, and WeChat Official Accounts. Under X there are Xiaohongshu long form posts and X, formerly Twitter, articles. Under Z there are the Alipay open platform and Zhihu. And under the digit 5 there is 51CTO.

The README groups the platforms into three families by their nature, with icons for each. The media platforms are the content sites, including WeChat Official Accounts, Toutiao, Zhihu, Douyin articles, Xiaohongshu, Baijiahao, NetEase, Sohu, Weibo, Bilibili, Douban, SSPAI, and the X articles. The blog platforms are the developer blogs, including CSDN, CNBlogs, Juejin, Medium, SegmentFault, InfoQ, Jianshu, and OSChina. And the cloud platforms and their developer communities are Tencent Cloud, the Aliyun community, the Huawei Cloud blog, the Huawei developer articles, Baidu Cloud Qianfan, the Alipay open platform, ModelScope, the Volcano Engine community, and Elecfans.

That grouping is a useful way to think about what the tool covers, because the three families need different things. A blog platform wants Markdown, a media platform wants a title, a cover image, and a body, and a cloud community wants a tag hierarchy and a topic selection. The extension handles all three by using each platform's own composer, and the grouping tells you which destinations are likely to be a smooth fit for a given article.

The four features that address the real friction

The feature list is four items, and each of them corresponds to a specific thing that goes wrong when you publish the same article by hand in several places.

The first is that you edit once and sync to multiple platforms, which is the obvious one.

The second is automatic detection of the login state on each platform. This is the feature that makes the whole thing tolerable, because it removes the need to log in to thirty sites before you can post. It also implies that the extension checks whether you are signed in, which is a network request per platform, and which is why the login state is detected once and then reused.

The third is that the tabs opened for the sync are automatically grouped, so they are easy to manage. This is a small detail that solves a real annoyance. Syncing to twenty platforms means twenty tabs, and untidy tabs are how a workflow like this becomes unusable. Grouping them keeps the browser navigable and, more usefully, keeps the half finished tabs together so you can go back and check the ones that did not publish cleanly.

The fourth is specific to the WeChat Official Account path, and it is the one that shows the most work has gone into the hardest platform. When syncing to WeChat, the rendered styling is preserved in full and the result is saved automatically as a draft.

Both of those halves are decisions. Saving as a draft rather than publishing directly means the author gets to look at the WeChat rendering before it goes out, which matters because WeChat's editor is the most opinionated of the set. And preserving the rendered style rather than pasting Markdown means the extension screenshots or renders the article and uploads the result, so the visual result is what the author saw in the editor.

The WeChat case is also the clearest illustration of the trade-off in this tool. Doing it that way is what makes the result look right, and it is also why the extension needs to interact with a third party page rather than post to an endpoint.

Local by design, and the privacy file

The privacy claim is stated prominently, right after the description, and it is a specific claim rather than a generic one. The plugin runs entirely locally, it does not collect and does not store any user information, and the README invites issues and pull requests to add more platforms or to improve the accuracy of the sync.

That claim is structurally plausible rather than merely asserted. The extension drives the pages in your own browser, where you are already signed in, so there is nothing for a server to collect, and the repository has a PRIVACY.md file at the root, which is where a statement like that belongs.

The design is also consistent with the other choices. There is no account, there is no configuration server, and the way to add a platform is to send a pull request rather than to sign up for something. The tool's cost to the person using it is the browser extension and the effort of logging in to each platform once.

The remaining question is the obvious one for a tool that drives thirty third party sites, and the README does not answer it in the excerpt available here. What happens to your content during a sync, and what the extension stores locally between runs, are both things the privacy file and the extension permissions will tell you, and a writer publishing to a dozen platforms is exactly the person who should read both before the first run.

For a user who publishes elsewhere with a different tool, the platform list is the other thing to check, and the README asks you to open an issue for a platform that is missing, which is a low bar to clear and an easy way to find out whether the community you write for is covered.

The monorepo, the browser targets, and the dev mode workflow

The repository is a pnpm workspace with the extension in an apps directory and shared code in packages, and the build scripts are all delegated to the extension app, which keeps the workspace root free of build details.

The scripts show the three browser targets the project supports, which is more than the Chrome Web Store badge at the top of the README suggests. There is a plain build, a Firefox build, and a Safari build, alongside development variants for Chrome and a watch mode. The build and the dev scripts all delegate to the extension app with a filter, which is how a pnpm workspace is normally driven.

The quality tooling is small and modern. Linting runs recursively across the workspace, formatting is Prettier over the whole tree with a check variant for continuous integration, and the tests run with the Node test runner, which means the test suite needs no test framework dependency at all. The pre-commit hook is set up with simple-git-hooks, and lint-staged runs Prettier over the staged files, with a glob that covers JavaScript, TypeScript, module files, JSON, Markdown, YAML, and HTML.

The developer mode instructions in the README are the ones every extension author knows. You clone or download the project, open the extensions page in Chrome, turn on developer mode in the top right corner, choose the option to load an unpacked extension, and select the cose directory.

The package manager is pinned to a specific pnpm version in the manifest, and the root package is private, so the repository is a workspace rather than a published package. The presence of the Safari and Firefox build scripts alongside the Chrome one is the most interesting detail here, because it means the extension is not tied to a single browser's extension model even if the distribution channel today is the Chrome Web Store.

Editorial conclusion

cose fits a writer who already drafts in the doocs Markdown editor and publishes the same piece in several places, and who wants the platform login state reused rather than re-entered. It does not fit a writer whose platforms need genuine native formatting per destination, because the extension renders once and posts the same content everywhere, and it does not fit a team that cannot install a browser extension. Verify first that the platform you publish to is on the supported list, that the platform list is current for your region, since the supported set changes with the releases, and that you read the privacy file, because the local only claim is a design decision you should be able to check rather than assume.

Frequently asked questions

Official sources

1. doocs/cose on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases