Take things offline and the dynamics totally change. The overheads disappear. No one needs to pay for anything. The subjugation stops, and it's Big Tech who are locked out of the party - not you.
In early June I documented a forthcoming content-packaging system, designed to run offline, cross-platform, with no software installation necessary. This has become a pretty serious project - for me at least - and I want no one to be in any doubt that the app is on its way. These things are fairly straightforward to codge up to an experimental standard, but crafting them into decent and widely usable apps is a lot of work for one person.
The single biggest challenge through the course of the app's development has been browsers' general reluctance to communicate with files when there's no server or authentication layer.
From the beginning, the goal with this app was to provide a real alternative to surveillance culture, rather than just whining about it on a blog. I honestly couldn't find one online platform that was a real solution. I'd dig up some tiny indie startup via Marginalia - proprietor assuring users it was all about independence and content. Then I'd find that self-same proprietor in dev land extolling the virtues of his Cloudflare CDN and talking about users like they were beads on an abacus.
Wherever you go, it's the same story. The admin needs funding, and is at the mercy of edge companies, and the users are either the customer or the product - or both.
But take things offline and the dynamics totally change. The overheads disappear. No one needs to pay for anything. The subjugation stops, and it's Big Tech who are locked out of the party - not you. There's no hosting. No certificate authority. No "Who-Goes-There?!" fortress-guard between you and your resource, deciding whether or not you're a fucking "bot" that has to be sent to the sin bin.
You own the software. You control it. You can email it to friends and they can own and control it, and they'll thank you for giving them that liberty. And slowly, as a society, we start to rediscover that having a private life is at least feasible.
I've been building in shortcodes that extend basic Markdown to produce additional visual punctuations within each post.
We don't just need genuinely private alternatives. We need them to be available to anyone who wants them. There are plenty for people who are familiar with servers and, for want of a better expression, Linuxy shit. But nothing for anyone else.
So the number one proviso was that my app would work 100% offline, in any operating system, without any server technology. Literal download, click and go. But due to browsers' security policies, that's been a lot easier said than done.
When you use a web-based editor or CMS, there's always an authentication layer (AKA a login), behind which a database can be freely accessed with appropriate ringfencing and permissions. So WordPress or similar can save or fetch your content without you even knowing about it.
TRIALS AND TRIBULATIONS
However, with a serverless system anchored in a browser, that kind of seamlessness is impossible. In one way, this is good, because it means nothing can ever be perma-saved without your say-so. In another way, it's not so good, because it introduces the inconvenience of manual file-saving via a dialogue in the browser. The danger of people losing work has been a major concern, and it's taken some thought and much testing to make saving intuitive and non-intrusive, without the risk of loss.
I considered building the app with Electron to get round this headache, but on the developer side, Electron has dependencies I don't really trust, and its bundling of both Chromium and NodeJS in all distributions would be horrendous overkill in something designed to be light and virally distributable. At present the whole package is just kilobytes in size. Very trivial to share. That would not be the case with Chrome and Node levered in. And that's before you even think about the forced use of Chromium. The point of this packager app is to get away from Big Tech - not increase its market share.
The idea is to take tactics that Silly Con Valley has exploited to drive its own brands, and free them from the grip of silos so they can be used to push independent alternatives.
So rather than making an Electron app, I've kept faith with a "bodyless" app, entirely using stock front-end Web frameworks for the main interface. It sounds a bit cavalier, but "bodyless" looks to have been the right decision.
As various workarounds to the file-saving issue start to mesh, the app is feeling more like an online tool. I just ran it in Windows and was pleasantly surprised at how indistinguishable the performance was from that in its build environment of Ubuntu-flavour Linux. The strategy was to use the browser as the operating system (which is essentially what modern browsers are), so running with Firefox in Windows is no different from running with Firefox in Linux. That part of the plan looks to have worked flawlessly.
But giving the app a competitive feature set has been frustrating at times. Creating offline distributions has never been a problem, and that was the core of the idea from the start, alongside the wherewithal to spin up fast pages for Neocities - also a straightforward task. But as time progressed I realised many people would also want the facility to turn their project into an entire static website, in a single action. This has been restricted by browsers' file-saving limitations throughout.
Without a server, a browser-based app can build a static site step-by-step, with each page saved as it's made within a project. A project, I should explain, is just a collection of work, bound to an index. It's all the ingredients of a website, without the physical structure.
But the inability to instantly convert a project into a full website was a glaring omission. For now, I'm addressing this by including a Python script, allowing instant website generation via a two-step process. The app saves an XML file containing the relevant site information, and the Python script rifles through the XML creating the appropriate folders and individual pages automatically. From there, the fully-built site can just be dropped onto your server wholesale. JavaScript-free, fast, light, all the dependencies in the right place. A quality job.
The problem? If you don't have Python, you need to install it to get this particular function, and the Python script has to be run from the command line. It's not the end of the world, but I didn't want any geek-level processes involved, and I'm not seeing a way round this one at present.
UNGEEKING
On the positive side, the app's output is getting more mainstream all the time. Because it's an app for writers, I've sought to start with a single-column layout for posts, and then "pictify" the formatting so that various Markdown conventions generate cool aesthetics. To drive this idea harder I've been building in shortcodes that extend basic Markdown to produce additional visual punctuations within each post. The idea is to take tactics that Silly Con Valley has exploited to drive its own brands, and free them from the grip of silos so they can be used to push independent alternatives.
For example, Cyberquotes (see image at top of post) look much akin to classic social media embeds, but they're much more flexible. They cite quotes found elsewhere on the Web, in a design-rich, pseudo-pictorial fashion. The difference is that you can use them to cite people on any Web property. Not just Surveillance Valley silos. You can cite people on Neocities, on Mastodon… On their own domains.
Inserting a Cyberquote is a simple mix of ordinary Markdown and extension shortcodes. Cyberquotes are entirely separate from ordinary blockquotes, so you can have both in the same post, maximising the visual impact. And in output, Cyberquotes don't need JavaScript to display, so even with lots of these faux "embeds", your pages remain superfast and immune from social media blocking routines. You always get an absolute single-source page in the output - unless you knowingly hotlink image content from elsewhere, that is.
At present the whole package is just kilobytes in size. Very trivial to share.
Another great thing about the app is that you can see the raw Markdown and the formatted output side-by-side. It serves as a sort of live how-to. If you load the demo About page in a new project, then scroll through, picking out the bits of demo formatting you like, you can simply check the Markdown pane next door to see which symbols or shortcodes will produce them in your own work.
Whilst I still can't predict when the app will be ready, it is a happening scenario, and RSS subscribers to this blog will be the first to set the offline revolution in motion. The app will probably get its own info and tips blog on release, and these pre-release posts can then migrate there for the record.
I'll keep you informed.