# dokieli: a browser editor for publishing articles without a server

> dokieli is a client-side editor for decentralised article publishing, annotations and social interaction, built on Solid, Linked Data and ActivityPub, and it can run as a single page app or as a browser extension. It suits scholarly and data-journalism authors who want their documents to live on the open web.

**dokieli/dokieli** — :bulb: dokieli is a clientside editor for decentralised article publishing, annotations and social interactions

- Repository: https://github.com/dokieli/dokieli
- Website: https://dokie.li/
- Stars: 893 · Forks: 100
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/dokieli-dokieli

## The document is the server, and there is no root

The opening statement of the project is a positioning rather than a feature. dokieli is a clientside editor for decentralised article publishing, annotations, and social interactions, and it is built with four principles in mind: freedom of expression, decentralisation, interoperability, and accessibility. The sentence that follows is the one to hold on to: there is no root, authority, or centralisation here, with the instruction to control yourself. That means the application does not host your articles. A dokieli document lives at a URL you control, and the editor is a tool that reads and writes that URL. The consequence for a reader is that opening a dokieli article in a plain browser shows the published form, and the same document opened inside the editor becomes editable. The consequence for an author is that there is no export format problem in the usual sense, since the document is HTML with semantics embedded in it, and there is no backup problem either, since your copy is the copy. The two ways of using it are stated plainly: as a single-page application where you open any embedded dokieli article, and as a browser extension that you import into your browser.

## The standards underneath are the actual specification

The specification list is the most important part of the readme for anyone deciding whether this fits, because it tells you what your output will interoperate with. Information is represented and retrieved following the Linked Data design principles. WebID is used for personal and agent identities, and WebID-TLS and WebID-OIDC are used for authentication. Web Access Control with ACL sets permissions on web resources, and W3C Linked Data Platform and Solid Protocol servers are used to read and write those resources. W3C Linked Data Notifications provides inbox notifications for annotations and social sharing, the W3C ActivityPub client reads and writes from and to a profile's outbox, and the W3C Web Annotation Model and Web Annotation Vocabulary cover the annotation layer. Read as a set, that is a complete stack: identity, storage, permissions, notifications and social distribution, all from W3C and Solid specifications rather than a bespoke protocol. That is the interoperability claim, and it is also the source of the complexity, because an author is effectively choosing a set of standards for their publishing infrastructure rather than picking a CMS.

## The document does more than hold text

The feature list is long but it clusters into a few ideas, and the first cluster is semantic authorship. The editor does in-browser document authoring and formatting, and semantic enrichments as RDFa annotations. Content negotiation is possible for RDFa, Turtle, JSON-LD and RDF/XML, which means the same document can be served to a human as HTML and to a machine as graph data. Author information comes from the author's online profile through their WebID. There is per-language assignment at the level of the article, the annotation, and parts within, and URI fragments can be assigned to any unit of significance so other resources on the web can link to a specific part of a document. Versioning is implemented and the notion of immutable resources exists. The second cluster is embedded data, where data blocks such as Turtle, N-Triples, JSON-LD and TriG for Nanopublications can be embedded alongside media objects, tables and interactions, and the third is scholarly apparatus: automated references and citations that retrieve and reuse structured information, insertion of a table of contents, figures, tables and abbreviations, and a graph visualisation of the linked data. There is also GPX import with track viewing on a map, and a message log for social interactions.

## Self-replication means the document can fork itself

Two features are grouped under a heading of self-replication and they are unusual enough to be worth explaining. Creation of new documents from any existing dokieli document is part of self-replication, and so is saving a document and its dependencies to a new location, anywhere on the web given access. In practice that means a document can act as a template, and a reader who likes a piece can fork it, bring the dependencies with it and publish the result under their own identity. The dependencies matter more than they sound, because a document with embedded data blocks and imported citations is not a single file, and a fork that dropped the linked resources would be a broken fork. The linked data graph is not decoration but the structure the document depends on, and a graph visualisation of it is provided so you can see what a fork would carry. The readme also mentions creating new documents from any existing document and opening and editing URLs containing HTML, which is the escape hatch for the case where the content starts life somewhere other than dokieli.

## Building it and running it locally

The development loop is short and conventional. You clone your work repository, install the packages with yarn, make your changes in src and media, and build to create scripts/dokieli.js, or let it rebuild on change with yarn watch, or produce a minified scripts/dokieli.js with yarn minify. To serve the static files any HTTP server will do, and the readme suggests one directly:

```sh
git clone git@github.com:YOUR-USERNAME/dokieli
cd dokieli
```

```sh
yarn
```

```sh
yarn build
```

```sh
npx serve
```

The build is webpack with a progress and colour flag in every mode, and the package scripts show the rest of the toolchain. Unit tests run under vitest with a timezone forced to UTC and coverage enabled, end to end tests run under playwright, and the older test script points at a runner in the tests directory. Linting is eslint, and the postinstall hook runs patch-package, which tells you there are patched dependencies in the tree that a fresh install would otherwise lose. The dev script is the most revealing line in the file, because it starts webpack in watch mode with a nanopub test registry and a local ohyeah service URL, so the development environment expects a local service for the annotation and social features. The engines field requires Node 22 or newer, and the package is an ES module whose main entry is src/dokieli.js.

## Configuration is an identity, not a feature flag

The environment file is short and it is a good illustration of what a decentralised tool needs to be told. There is a login identifier and password, an identity provider URL, a WebID, and a key passphrase of at least twelve characters. There is a client identifier and a separate development client identifier, an origin, and an OIDC redirect URI that is there for the case where you want to redirect somewhere other than the origin. Then there are the service endpoints, with a websocket URL and a demo URL, plus flags for the nanopub test registry, a screencast setting, and a test resource URL. The WebID is the important one. Everything else is configuration, but the WebID is the identity under which your documents will be published, and the passphrase protects the key that proves it. That is a fundamentally different setup from configuring a database password, because the credential is not just opening a local service, it is the agent identity that will be written into every document you publish and into the signatures on the data you save.

## Licences split between code and media, and the paper interface is a stated feature

The licensing is straightforward and worth stating precisely because the two categories differ. The source code is licensed under the Apache License, Version 2.0, and unless otherwise noted, images and other media assets are licensed under the Creative Commons Attribution 4.0 International. The project also keeps a Code of Conduct, a Contributing Guide, a Security Policy and a Roadmap, and the roadmap is published alongside the documentation rather than buried in the repository. The feature that tells you the intended audience most clearly is the views for screen and print, with ACM and LNCS named as examples, and the documentation noting that you can output to a paper user interface as a PDF. The readme links to the authoring guidelines for the ACM SIG proceedings paper using the LNCS author guidelines, and points to a separate themes repository for more. For a scholarly publishing tool that is the point: the document you write in the browser is a document that can be typeset to a conference template without a conversion step, and the screencast list includes a specification conformance video covering requirements, test coverage, version diff and change log, which suggests the project is treated as an implementation of a spec rather than a product.

## Conclusion

dokieli is a good fit for an author or research group that wants to publish a document as a first class web resource with machine readable semantics, annotations and citations, and that does not want a content management system with a database behind it. It is the wrong tool for a team that needs editorial workflows, a server-side render, or a comment system with moderation, since the whole design assumes the document itself is the durable artefact. It is also the wrong tool if nobody in the project is prepared to think about Solid, WebID and content negotiation, because that is the domain knowledge the whole thing rests on. Before adopting it, read the specification list rather than the feature list, since the standards it implements determine what your output will interoperate with, and set up the.env file from the example with a WebID and an identity provider before you try to save anything. The source is Apache-2.0, the media assets are CC-BY 4.0, the last push was on 2026-10-22, and the project publishes no GitHub releases.

## FAQ

### What is dokieli?

It is a clientside editor for decentralised article publishing, annotations and social interactions, built on principles of freedom of expression, decentralisation, interoperability and accessibility. There is no root, authority or centralisation, so a document lives at a URL you control and the editor reads and writes that URL.

### How do I run dokieli locally?

Clone your work repository, run yarn to install the packages, then yarn build to create scripts/dokieli.js, or yarn watch to rebuild on change and yarn minify for a minified bundle. You serve the static files with any HTTP server, and the readme suggests npx serve. Unit tests run under vitest and end to end tests under playwright.

### Which web standards does dokieli implement?

Linked Data for information representation, WebID for personal and agent identities, WebID-TLS and WebID-OIDC for authentication, Web Access Control and ACL for permissions, Linked Data Platform and the Solid Protocol for reading and writing resources, Linked Data Notifications for inbox notifications, ActivityPub for reading and writing a profile's outbox, and the Web Annotation Model and Vocabulary for annotations.

### What does self-replication mean in dokieli?

It is the ability to create a new document from any existing dokieli document, and to save a document and its dependencies to a new location anywhere on the web given access. Dependencies are carried along, which matters for a document that embeds data blocks and imported citations rather than being a single self-contained file.

### What licences apply to dokieli?

The source code is under the Apache License, Version 2.0, and images and other media assets are under the Creative Commons Attribution 4.0 International licence unless otherwise noted. The last push was on 2026-10-22 and the repository publishes no GitHub releases.

## Sources

- [dokieli/dokieli on GitHub](https://github.com/dokieli/dokieli)
- [Issues](https://github.com/dokieli/dokieli/issues)
- [License: Apache-2.0](https://github.com/dokieli/dokieli/blob/main/LICENSE)
- [Project website](https://dokie.li/)
- [README](https://github.com/dokieli/dokieli/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dokieli-dokieli