20 · Where this is going

To close, what does not exist yet — with the caveat that these are directions, not promises with dates.

Direction one and most important: an author's dashboard. Today an entry is a file and publishing is an operation on a repository. Eventually the author writes a draft that lands in the database, and publishing is a task on the server side. One architectural decision here is already settled: the application will never receive a key to the repository. A key in a browser is a leaked key. The server publishes, on the author's behalf, with a key the author never sees.

What is interesting is that such an arrangement is cleaner than the present one, not merely more convenient. Drafts live in the database before they become files. An author can write today, release in a month and revise along the way — without touching a file once.

Direction two: reader accounts. The schema, sessions and sign-in through an external provider are already standing; the interface is missing. What matters here is what we deliberately do not build — profiles, following, activity notifications. An account is meant to give a durable identity under a comment and nothing beyond that. Every further social feature is a promise to moderate it for years.

Direction three is the first deployments that are not ours. Until then, everything we write about scaling and about what people need is a hypothesis — sometimes a well-founded one, but a hypothesis.

Finally, the boundary we do not cross, because it defines this project better than a feature list. Kolofon will not bring anybody readers. There is no directory, no recommendations, no shared front page with other people's writing. Reach is yours to build. Platforms promise more here and sometimes even deliver — in exchange for control over your audience. That is exactly the trade whose refusal this architecture began with.