,
Nocterra started as a practical tool for the website of the IRADIS Foundation, now ASK-Solutions. It came from the period in which the internet still carried a very direct promise: ordinary people, small organisations and small businesses could publish, share knowledge and build tools without first needing permission from a large software vendor, publisher, broadcaster or government institution.
That promise did not come out of nowhere. The personal computer had already moved computing power from institutions to desks, workshops, bedrooms and small offices. People exchanged software and knowledge through diskettes, dial-up lines, packet radio, BBS systems, FidoNet, Usenet, Videotex services and direct file transfers with tools such as Kermit and XMODEM. The internet made that exchange broader, faster and less local. It made a more radical form of independence possible.
At the same time, that independence was under pressure. The web was increasingly shaped by browser wars, proprietary extensions, desktop authoring tools and server-side dependencies. Work on open web standards1 was not an abstract preference.
Small websites were often written by hand in a text editor such as Notepad, Emacs or Vim. Larger websites were commonly built with desktop web-authoring software such as Microsoft FrontPage or Macromedia Dreamweaver. The later CMS landscape around Drupal, WordPress and Joomla was not yet there in the way it became known later. TYPO3 was one of the few early projects moving in that direction.
The workflow of the visual tools felt familiar from office and graphics software. A page was opened on a computer, visually arranged, saved and published to a server. In practice this often treated a web page like a document in a word processor or an image in Jasc Paint Shop Pro: something made for a chosen size, appearance and environment.
That was exactly the problem. A web page is not a printed sheet and not a drawn image. It has to survive different browsers, screen sizes, fonts, colours, user settings, devices and assistive technologies. HTML should describe structure and meaning. CSS should describe presentation. The work around web standards was about keeping that separation possible.
The problem also showed up in the generated HTML. Visual editors often stored the result of editing operations as repeated presentational markup instead of reducing the page back to clean structure. Changing a font, making a word bold, inserting text later and correcting the selection could leave behind nested or repeated <FONT>, <B>, <I> and <U> elements inside a single paragraph.
That was bad output in a technical sense. It increased file size, made pages harder to inspect and repair, and gave the browser more markup to transfer, parse, keep in memory and resolve. On dial-up connections, servers running from private addresses or remote locations, and computers with limited memory, those extra bytes and nested elements were immediately visible as slower pages and less predictable rendering.
The first version of what later became Nocterra was named BackPage. The name was a direct answer to FrontPage, but the reason was practical and technical.
FrontPage commonly depended on FrontPage Server Extensions for part of its functionality. That limited the choice of hosting provider and server software, and pulled a website into a licensing and deployment model controlled by one vendor.
The visual editors of that period also fed into the browser wars. They encouraged pages that worked best in a particular browser or authoring environment, instead of starting from the freedom of the visitor to choose a browser, device and user settings.
BackPage also reversed the publishing workflow. FrontPage worked from an authoring workstation and published the generated result to the server. BackPage was placed on the server itself. Source files were edited directly with tools such as Vim or Emacs, locally or through a remote connection, and the site was then built by running make.
The build step compiled the sources into complete pages, added markup, loaded stylesheet references, generated navigation, marked the current page with classes and IDs, and compiled a sitemap. In other words: BackPage did on the server what FrontPage tried to do from the desktop, but from structured source files instead of visually edited page output.
BackPage was later renamed Synergos. The name was chosen around the idea of working together: information publishing, idea sharing and making creations available through the same website system. This was close to the original promise of the internet and the World Wide Web. Individuals, small organisations and small businesses could publish and exchange directly, without first having to pass through a publisher, distributor, retail chain or software vendor.
At that time, selling something through a website was still very direct. A seller could place information and a few images online, and the buyer would send an ordering email. A more advanced version had a button on the page that generated an email to the seller. The seller would then reply with confirmation and payment information, often for a bank transfer.
Synergos tried to bring that process into the website system itself. Product information, normal pages and ordering could be handled together, with support for payment through PayPal. The aim was not only to publish pages, but to make a website useful as a place where information, ideas, creations and sales could meet.
That also changed the technical model. BackPage's page, navigation and layout sources were moved into a database, and editing moved from source files in Vim or Emacs to forms in the website itself. The build step moved from make on the command line to PHP scripts behind a login. Saving a page in the web interface could compile the public output, instead of maintaining the site through make dependencies on the server.
Synergos kept the same concern for generated pages and consistent structure, but explored a more interactive publishing model. The marketplace and sales direction was eventually dropped after Etsy became successful. Etsy proved that the marketplace itself could become the place where artists and craftspersons found buyers who were already looking for handmade and original work. For most people using Synergos, maintaining their own sales environment became too much work on top of making, documenting and selling their work.
The payment side also moved in a direction that did not fit the original goal. Keeping the shop functionality working meant spending more and more time on proprietary payment systems such as PayPal, MrCash and iDEAL. Especially iDEAL was fragmented at the time, with different banks requiring different implementations. That tied the work to specific platforms and banks, and moved development effort away from libre website publishing. The work on structured content, generated output and maintainable websites continued.
In 2019, after the Great server crash™2, Synergos was not repaired as it was. The project was renamed Nocterra and reprogrammed from the ground up.
The name fitted more than one change at once. Howard, the foundation's owl mascot, had by then become part of the identity around the project, in a role somewhat similar to the GNU head for GNU. The name Nocterra also fitted what changed technically. Synergos still had its administration pages in the dark web3; Nocterra went darker still. Authoring and administration moved fully off the web again: no browser-accessible administration backend, no database-backed editor and no hidden admin section, but source files, configuration, command-line tools and protocols such as SSH, SCP, SFTP and rsync.