Features

Entries sit as files in the author's repository. There is no editorial panel, because there is nothing to administer — there is a directory of texts. An entry is a file. It has a title, a date, paragraphs and a few descriptive fields, and it sits in its series' directory along with the rest. Deployment takes those files as they are — there is no database between them and the page into which they would first have to be imported. Several things follow at once. The change history is the repository's history, so it is visible who corrected what and when. A backup is a copy of a directory. Moving to another tool needs no export and no request for help — the files are already in a format readable without this engine. What is missing: a panel for writing in the browser. That is a deliberate cost. An author who wants an editor with a preview has one in their own tool; the engine does not try to be a word processor, because every such tool built along the way is worse than the ones that do only that. The gain is that no state exists which can be lost on someone else's side. The site can be raised again from the repository alone, and the repository sits wherever the author keeps it.

Every entry belongs to a series and holds its own place in that series' index. The stream gathers all series into one list, newest first. A series is a thread: a diary, a run of photographs, notes from building something. It has a name, a description, an opening sentence and its own address, under which all its entries sit in order. An entry without a series does not exist — belonging is compulsory, because without it a site turns into one unbroken run. The stream does the opposite: it folds entries from every series into one list, newest first. A reader arriving from outside gets a picture of the whole site there; a reader who knows what they came for goes straight to the series. Both lists are paginated and draw their entries from the same place in the code, so they cannot drift apart. The order of series in the navigation is set by a field in the series file, not by alphabetical accident.

An entry dated in the future sits in the repository and appears only at its hour. No external scheduler, no second deployment. The date field is the moment of publication, not a note of when something was written. An entry whose date has not yet passed is in the repository but not on the site: it appears in no series, no stream, no feed and no sitemap, and visiting its address ends the same way as visiting an address that does not exist. The practical consequence is that the publishing queue is ordinary files. Three months of entries can be prepared at once, uploaded in a single deployment, and left — each will come out at its hour, with no calendar task and no service that has to be healthy that day. The hour is taken seriously, not just the date. An entry set for six in the morning appears at six, not at midnight, so a schedule can be fitted to the time readers actually look in. The only trap runs opposite to expectation: an entry meant to appear immediately needs a date in the past. A date set to "now" while writing is often a minute ahead, and then the entry stays silent until that minute.

The feed serves the full text of an entry and its image in three notations at once — so that readers and distribution automations have something to build a preview from. The feed serves the whole entry, not a first sentence with a "read more" link. A reader who chose a feed reader has the right to read it all there; pulling them onto the site for every paragraph is a sales move, not a convenience. The image is written three ways at once, with an absolute address. Not for elegance, but because readers and automations look at different fields: one takes the first, another the second, a third takes none at all if the address is relative. The thumbnail is the light preview variant that every entry has — including a text entry with no photograph. The feed accepts a count parameter, so one address serves two purposes: a short list for a reader and a long one for a tool meant to see the whole archive. The address without a parameter stays at its default and does not change between releases — automations sit under it, and they do not take surprises well.

The sitemap assembles itself from published entries, and every page carries its own title, description and canonical address. The sitemap is built from the same data as the stream, so it has no way of drifting from reality. An entry scheduled for next week does not reach it, an entry hidden with its series does not either, and a published entry reaches it without anyone remembering to add it. Every page carries its own title and description. An entry may give a description separately — different from the excerpt shown on a list — because the sentence that draws a reader on the page and the sentence that makes sense in search results are rarely the same sentence. Where no separate description exists, the engine takes the excerpt. The canonical address is always emitted. With a family of language instances that is not a detail: without it, two versions of the same text start competing in results instead of complementing each other.

Every entry has a preview image — a photographic one gets a light variant of its own frame, a text one gets a card built from its strongest sentence. A link sent in a messaging app unfolds into a card with an image. If there is no image, the card is grey and the link looks suspect — and a purely textual entry has no photograph by its very nature. An entry with a photograph gets a light variant of it, around twelve hundred pixels and under two hundred kilobytes. The full frame is often too heavy: some messaging apps simply skip it and fall back to the grey card, even though the image was supplied correctly. A text entry gets a card built from a single sentence — the one the author marked as the strongest in the text. It is not decoration but a substitute for a photograph: the card has to give a reader a reason to click, and a quotation does that better than a logo repeated under every entry. Entries that mark no such sentence get the site's default image.

The site can be installed like an app, and the latest entries are fetched in advance — reading works on the underground and on a plane. The site declares itself an installable app: an icon on the home screen, its own colour, opening without an address bar. This is not a separate app to be released in a store — it is the same site, installed. It updates along with the site and needs nobody's approval to publish. On top of that comes the offline bundle: a list of recent entries fetched in advance, together with their images. A reader stepping onto the underground already has them. Entries hidden with their series do not enter the bundle, because the bundle draws its content from the same list as the stream. There is also a mechanism that notices the deployment has moved past an open tab. An app left in the background for a week could show a week-old version and not know it; now it checks the release marker and refreshes itself.

A reader can turn on notifications of new entries with a single click, without giving an email address. Delivery follows publication. Signing up for notifications is one click and a browser prompt. There is no form, no email address and no confirmation in an inbox — a reader leaves behind nothing they could later be addressed with somewhere else. Delivery is tied to publication, not to deployment. An entry scheduled for Saturday morning sends its notification on Saturday morning, though it was uploaded on Wednesday. A periodic task checks whether anything has come out since its last run, and only then sends anything at all. Consents are kept in the site's own database, along with the rest of its data. There is no external service here keeping a list of recipients and able to share it with someone — which matters more than it seems for sites written under a pen name.

Readers rate entries in stars. Before the first votes arrive, an entry shows the author's provisional rating, labelled as provisional. A rating is in stars and needs no account. The vote is written to the site's database, and the reader sees the average and the count immediately. The question under the stars is written by the instance — "Rate this frame" and "Did this entry make sense?" are two different questions and two different series. A new entry has a problem that collecting votes cannot solve: for the first few days there are none at all, and an empty rating block looks worse than no block. So the author may give a provisional mark, plainly labelled as provisional, which gives way to readers the moment they vote. This is a declaration, not a manipulation: the author says what they think of their own text and leaves it in plain sight. An entry to which they gave three stars themselves tells a reader something true about the series.

Entries have a view counter kept on the site's own side, with no third-party tracking scripts and nothing passed outwards. A view is written to the site's database and shown by the entry. There is no third-party script here, so a reader is not measured in passing by someone they did not invite, and the site's owner hands nobody a picture of their traffic in exchange for a chart. The number by the entry is information for both sides. The author sees what gets read; the reader sees whether the text they landed on already has an audience or does not. Both are more honest than a counter hidden in a panel. This is deliberately little: no heat maps, no paths, no profiles. A literary site does not need a tool for optimising a sales funnel, and everything beyond a view count is paid for with a reader's privacy.

Entries can be commented on, and the instance picks the rule: anyone, signed-in readers only, or nobody. Comments sit in the site's database. A comment is part of the site, not a service glued on from outside. That means the conversation under a text does not vanish along with someone else's company, and does not add third-party tracking to a reader's visit. The instance picks the rule: anyone comments, only signed-in readers comment, or nobody does. The choice is a configuration field, not a rebuild — a site that starts with comments off and opens them six months later changes one word. By default, where an instance says nothing, comments behave as they did before accounts existed: no registration, with a name typed in by hand. Older deployments therefore do not change behaviour when the engine version rises.

A reader may create an account and return under their own name. The session is kept in the database only as a digest, never as a token. An account gives a reader a durable name: comments signed the same way every time, without retyping a signature. For a site with conversation under its texts, that is the difference between a discussion and a guest book. Sign-in runs through external providers or an email address, depending on what the instance enables. Reserved names — the author's pen name, for instance — can be listed in the configuration so that nobody creates an account impersonating the person running the site. The rule that admits no exception: the database holds only a cryptographic digest of the session token, never the token itself. A leaked copy of the database allows nobody to impersonate any signed-in reader. This is one of those decisions that costs nothing while building and cannot be repaired afterwards. Accounts are optional. A site that does not need them leaves them off and pays for them neither in complexity nor in an obligation to hold anyone's data.

The site keeps its own event log: what was opened, where a reader came from, from which country and which browser. The network address is anonymised after three months. The log records events: an entry opened, a rating given, a notification sign-up, an arrival from outside. Each carries a time, a country, a browser, a referrer and a language. That is enough to see which text is alive and which merely sits there, and which channel people arrive through. The network address is anonymised after three months — the last quarter of the address becomes zero, and for a newer notation its second half is cut away. The rest of the event stays, because a statistic from a year ago still means something, while an address from a year ago has no purpose left beyond identifying one particular person. All of it sits in the site's database. There is no tool here that would build a reader profile for advertising along the way — not out of ideology, but because a literary site has nothing to draw from such a profile, while a reader has something to lose.

A family of language instances: each language has its own deployment and its own database, and a shared entry key leads from a text to its counterpart. A language is a separate deployment on its own subdomain, with its own database and its own content directory. The engine translates nothing and does not pretend to know what corresponds to what — it is handed a list of versions and recognises itself among them by address. Entries are linked by a key: a fixed identifier, the same on both sides, independent of the address in the content's language. The language switch leads from an entry to its counterpart, and where no counterpart exists, to the other version's home page rather than into a void. There is no map of addresses here that would need updating by hand after every change of title. The interface's own strings — buttons, labels, footer — are a separate set that the instance supplies in its language. Without that, an English site would carry a Polish install button, which showed itself immediately with the first non-Polish version.

The entries of one series, or of the whole stream, are set into a print-ready PDF book with a cover, a table of contents and bookmarks. Published entries become a volume: a title page, a table of contents, running heads, bookmarks, codes leading from paper back to the site. A5 format, with variants prepared for particular printers, because each counts its margins its own way. Typesetting does not happen on the fly at the press of a button. Setting a hundred-page volume with photographs is a task of a dozen-odd seconds and more memory than a single request has at its disposal. The file is therefore made in advance, sits in storage beside the site, and the button merely serves it. The button appears once a series has gathered a set number of entries, and it may be left off entirely. This is a feature for series that have grown into a paper form, not a default element of every site.

A series can be hidden without removal: entirely, or only from the navigation, with its entries still present in the stream. Its own address works in both variants. A series holding one entry from six months ago stands in the navigation on equal terms with one that publishes every other day, and promises a reader something it fails to deliver. Removal would settle it and break addresses along the way — addresses that already live in other people's bookmarks and in search results. Hence hiding in two strengths. The stronger sweeps a series out of everywhere: the navigation, the list of series, the stream, the feed, the sitemap and the offline bundle. The weaker takes away only the signboard — the series is in no menu and on no list, but its entries keep flowing in the stream and the feed, level with the rest. In both variants the series' own address works and shows everything it holds. Coming out of hiding is one word struck out: no migration, no change of addresses.

One configuration file describes the whole site: name, address, language, navigation, colours, policies. The engine knows none of those values in advance. The engine and the site are two different things. The site supplies its name, address, language, navigation, colours, contact address and chosen policies; the engine knows none of those values and has none of them written anywhere on its side. That separation is sharper than it looks at first glance. A value written into the engine's code reaches the browser even when nobody displays it — because whether it displays is decided only at run time, and the build tool cannot cut away a branch it has no way of predicting. A site run under a pen name cannot afford such a souvenir in its output. The practical consequence: a new instance is a new configuration file and a new content directory, not a fork of the engine with the names cut out. A fix in the engine reaches every deployment by the same road.

The site carries a release marker by which a long-open tab recognises that it is running an old version, and refreshes itself. An app left in the background for a week can show a week-old version and have no idea of it. An ordinary page reloads on entry; an installed one is often resumed where it was abandoned. The release marker settles that without guesswork. It is not a build hash, because there is no build here in that sense — the content is files in a repository, and deployment leaves no identifier behind. So it is assembled from the things that genuinely change when what a reader sees changes. The page checks the marker and, seeing that the deployment has moved on, refreshes itself. The reader need not know such a thing exists — and that is the point.

Every string of the engine's own — buttons, labels, messages — can be overridden by the instance, in its language and its tone. Some strings do not come from the content: the install button, the feed label, the message about no entries, the footer line. As long as one instance existed and it was Polish, they could sit written into the code and bother nobody. With the first foreign-language site it showed at once: an English site with a Polish button and a Polish footer. The strings therefore moved into a separate set, which an instance supplies whole or corrects point by point, leaving the rest at defaults. This concerns tone as much as language. A photographic site asks "Rate this frame", a technical one "Did this entry make sense?" — the same place, two different sentences, no change in the engine.

A site may have several authors, each with a pen name, a signature under photographs and their own way of setting the opening initial. An entry names its author, and an author is a separate record with a pen name and a signature under photographs. A site run by two people therefore need not be two sites, nor one site with signatures typed in by hand. Attached to an author is also the way the entry's first letter is set: dropped into the text or raised above the first line. It sounds like a trifle until two hands stand side by side in one stream — then the difference in typesetting does work no name label will do. The same setting carries over into the book, so a volume gathered from two series looks as the entries looked on the site. Authors a site does not have cost nothing — a one-person instance names one and thinks about it no further.

The same entry goes out into the world in several shapes. You do not crop a frame to somebody else’s format — you add a variant. Every entry has a preview image — a photographic one gets a light version of its own frame, a text one a card built from its strongest sentence. That is enough as long as the content goes out only as a link in a messenger. Image services have their own requirements about shape, and some frames they simply reject. Cropping on the fly is out. A photograph in a photographic series is composed deliberately, and cropping it to somebody else’s proportions takes away exactly what it was made for. Instead a second file is produced: the whole photograph fitted into a portrait canvas, filled out with the same background as the quote cards. Nothing is lost, the format is the same for every entry, and a quote card blends into the canvas with no visible seam. The portrait variant of a text entry is the same card at a larger scale: the quote gets more air, and beneath it stand the instance mark and the address. The type size steps down one point at a time until the block fits the frame, and below a hard threshold of legibility the generator would rather raise an error than release a card with text outside the frame. The feed publishes the address of a variant without checking whether the file exists — execution at the edge cannot see a disk. A missing file is a not-found and a post that does not go out. So the generating tool has a check mode: it walks the image directory and lists everythin

Three closed questions under the text. The result only after you answer, one pool of votes across language versions, and nothing stored that could identify anyone. Under the text of an entry there may be a poll: a few closed questions, each answered with one click. The instance supplies them with the entry, the engine collects the votes and shows the result. Questions have **fixed identifiers**, shared across every language version, while the wording of the question is in the instance’s language. The same principle as with ratings and comments: a question has as many wordings as there are versions, and a vote has one place. The sum is not divided between translations. **The result is revealed only after you answer**, and that is not decoration but the whole mechanism. The reader is meant to answer for themselves first and then see how many people answered the same way. The other order would turn the poll into a survey to read — and take away the only reason to click. We store the question identifier, the answer and the version’s language. **Nothing that would let one person’s answers be assembled** — no reader identifier, no address. That someone has already answered is remembered by their browser. With questions touching hard experience, that is not a detail but the condition for anyone answering honestly. The poll stands **before the rating and the comments** — from the cheapest gesture to the most expensive. A click costs nothing, a star requires a judgement, a comment requires words of your own. What this feature does NOT do: it award