Introduction
The development of Kova has been rapid. The project is now four months old and is in a very usable state, usage has worked its way into my day to day toolbox for lecturing and I know that there have been other users and contributors for whom it has become a useful tool.
Through all of the feature requests, issues logged, and pull requests I can see that there are people that have a similar passion for the project as myself. And with these developments I do not want to risk the feature set being muddied, or contrary to the original philosophy that Kova was built against.
This post serves as two things, a bit of background into how I personally view Kova, where it sits in the software space, and the ethos behind decisions surrounding features and direction. Finally, I want to share and discuss future ideas for the project that I see us working towards.
Where does Kova sit?
Kova is not going toe to toe with the big names in presentation software, and that should be apparent. The majority of the world has never heard of Markdown, let alone engaged with it in a meaningful way (granted Apple Notes utilises Markdown underneath to some extent).
To my mind, Kova is for two categories of people. The first are those who use Markdown for documentation purposes, with a potential to need presentations without the headache of transplanting Markdown content into presentation software.
The second is academics, educators, and students that utilise Markdown as part of the notes and study processes, with PKMs (Personal Knowledge Managers) becoming very popular over the past few years I feel that this is a demographic of user that would be interested in a Markdown-driven option for their presentations.
The aim is not to take on the big presentation software in the space but to offer a local, privacy conserving application that does what the majority of Markdown users need. When deciding on features I would look at the use case, the user base demand, and dependency weight (we are not shipping Chromium to get a feature that we can't achieve through Tauri).
Direction and Moving Forward
At the time of writing, we have received fifteen feature requests from the community, twenty bugs, and sixty-five pull requests that have been merged. This velocity prompted the creation of the Kova.md Matrix Server for discussions relating to development and we of course welcome any visitors with suggestions, quick questions before making a PR, or to share their overall experience with Kova. It is appreciated, it does support in the direction for the project, and I welcome it at all stages.
Going forward, there are some key areas that I am currently reviewing as targets within the development process. These are things that have either been floating around in my mind, or have been raised by a community member.
Features
Part of the motivation behind writing this post is outlining some of the core functionality going forward. These are drawn from personal goals for the application, but also components that I feel would help reduce barriers for users that are considering Kova, but can't quite find feature parity with their existing presentation tool.
Kova Plugins
The first, a plugin system. This will reside in its own repository at KovaMD/Plugins and be fed into the Kova desktop app in the same way as the themes repository feeds the More Themes interface. This would be a system that enables users to create patches using either Javascript or Typescript to expand Kova's functionality to specific use cases.
The scope of plugins is something I am actively reviewing, as we are based on Tauri instead of Electron (a decision taken to reduce footprint), it does create some limitations in what user created patches can achieve within Kova as it would have to be built at compile time, making local plugin loading complicated. I do feel that Tauri was the right choice, I have nothing against Electron — but when an application is built around a simple language designed to be quick and simple, having a large-scale backend like Electron does not make sense for this project. This is early days, and I have only started scratching the surface of what could be achieved with plugins at this time.
Some examples of what could be achieved based on the current codebase:
- Markdown syntax extensions
- Additional inspector elements
- Additional export functionality (watermarks, footers, headers etc)
- Third-party themes outside of the Kova theme library system
I will emphasise that plugins are part of the long game for Kova. Creating an implementation that is effective, secure, and intuitive for contributors is important and does not happen overnight. I am intentionally not attaching dates to these goals as I do not want to raise hopes on what is a project I work on in my free time.
Kova CLI
Following a suggestion from @a1880 on batch processing from the command line, this got my brain ticking over what functionality we could have from running Kova as a terminal application for specific use cases.
So far I am thinking that having the following could be useful for those of us who live in terminals and TWMs.
kova --present MyPresentation.md— Launch the presentation mode of Kova, loading in a Markdown presentation directly.kova --import marp/pptx/url MyMarpPresentation.md MyKovaPresentation.md— Convert a file that is currently in another format into a Markdown file utilising Kova syntax, or directly import a remote file.kova --export pptx/pdf MyPresentation.md MyExport.pptx/pdf— Export a pre-existing Markdown file directly to a PPTX or PDF file using Kova's syntax.
Additional flags could include, and open to suggestions of course:
--theme=gruvbox-dark— Temporarily override the theme of a presentation before presenting/exporting. Either naming a preconfigured theme, or providing a path to a YAML file, e.g.--theme=~/path/to/theme.yaml--check— Review syntax for errors before running a subsequent command.
An example Kova command could be: kova --check --theme=firefly --present CancelledTooSoon.md
Third-party Editor Plugins (Obsidian, Joplin, and VS Code)
With the introduction of a CLI based tool, this opens up some interesting avenues that can be explored in the Markdown universe as far as using Kova as a presentation engine for pre-existing applications, utilising our syntax. This could take the form of a plugin for the likes of Obsidian and Joplin (of which Kova shares the CodeMirror library for rendering) making it a relatively simple translation. Joplin does however operate a sandboxed plugin system which would make integration a little more complex, but not impossible. Obsidian has a more open approach to plugins, meaning we could quite easily have a command palette item labelled Present with Kova that simply triggers a kova --present $currentfile in the background to launch the presentation engine from Obsidian/Joplin.
VS Code is also on my radar, it is one of the most popular editors in existence so it can't really be ignored. It does however use a different editor engine called Monaco that operates a little differently, plugins are also sandboxed like Joplin, however the API for plugins to interact with the editor is incredibly broad so we should be able to achieve the required features with relative ease.
Slide Content Animation and Transitions
Finally, animations. They are a staple of presentation software and something that has been largely omitted from Kova. There is a short fade transition between slides, but nothing as far as introducing slide elements. In my use case teaching, this is a real bug bear of mine as it is useful to be able to gradually introduce concepts to students without needing multiple slides. The main reason for the delay in this so far has been trying to work out an effective way of adding this without compromising the Markdown while also working on all potential elements (including code blocks, LaTeX, math etc). This is actively being discussed in issue 92, and I think we're getting close to an effective solution, it must also translate across to the PPTX export system correctly.
Packaging
Coverage for various Linux distributions. We currently cover .deb and .rpm distro directly through Apt, DNF, and Zypper. I have built an Arch Linux PKGBUILD file that is awaiting submission to the Arch User Repository when user account registrations have been reinstated.
A NixOS Flake for installation, alongside the option of running the full development stack for Kova.
AppImages now build successfully once an initial display bug was resolved; automatic updates have been fixed in the AppImage as of 0.6.12.
A Flatpak version of Kova is available as of 0.6.13; users are able to install the .flatpakref from https://flatpak.kova.md and have it integrated directly into their normal flatpak update command.
As a part-time Gentoo user, at some point in the future I would love to personally tackle the ebuild for submission to GURU.
A special thanks to @vadika for work on the NixOS Flake, AppImage EGL issue, and creation of the Flatpak solution.
Security
Following an issue raised by @a1880, we began exploring issues surrounding the integrity, security, and trust of the code base for new users. It is something that I had been considering since the earlier versions of Kova, mainly centred around building trust with Windows users due to the Smartscreen functionality. I have since applied for a code signing certificate with SignPath and Kova has been accepted onto their provision for open source projects, current version of Kova will remain unsigned but in the near future Windows binaries will be signed.
As of 0.6.14, codebase attestation is now built into the release process so that produced binaries can be linked back to a specific commit point in Kova's development. Guidance is also provided on how to verify this independently. Finally, I have added the repo to Snyk which is actively monitoring the code base for both vulnerabilities and malicious code attempts.
It was raised that all of this is fine — but at the end of the day, the codebase is large. I hope through continued open communication and insight into the workings of the application and infrastructure that the project develops trust from the user base. For any specific questions about the project, please get in touch through Matrix — or email directly.
A note on LLMs
With LLMs becoming so common in the software development space, especially on small projects with limitations on workforce, I feel that it is important to have a "statement" of sorts of LLM usage in the Kova project specifically. There are places where it is great and works very well, and there are places where it still works but I don't necessarily consider it the most effective for the scenario.
In terms of development, I have no issue with the use of LLMs for code submissions but on the condition that the contributor takes relevant steps to ensure that the code created is efficient, does not overreach, and fits within the philosophy of Kova. As a user of Claude Code myself, it is an incredible tool that significantly reduces the workload of expanding features, reviewing code, and doing sanity checks before shipping. As someone who works full time and has Kova as my personal hobby, it allows for a much more consistent flow of fixes and updates in a timely manner.
I have some rules for myself as far as where I use AI around the project. In code, PR feedback, and code reviews I don't see there as being an issue with the utilisation of an LLM, the code coming in is initially reviewed by Snyk for correctness and security. I pass over the core function of the patch or feature, Claude Code provides a deeper dive into the repercussions across the wider code base (if any) that need to be considered before a merge. Feedback is given on a PR, points are drafted following the LLM review, then a human touch added before returning to the contributor.
There are of course things that I do not use AI for, and I ask that contributors extend the same courtesy. For security reasons, I will not let any LLM or AI touch the VPS. As I hold various keys required for the VPS, GitHub, and other infrastructure, I personally use virtual machines for any development work involving LLMs. This is a personal precaution that I take, but I would not expect contributors to follow the same process.
Interaction with you, the community, is something that I feel is wrong to hand off to an LLM. If a user has put the time into an email, Matrix message, or raising an issue on the repo — I feel that it's only fair that I put the respective time into creating a direct response by hand. This applies across Matrix, email, issues that are raised, and a post like this one (you're taking the time to read, so why would I just throw generated work at you).
Thanks
Kova had been under the radar for the first couple of months of its existence, I initially posted about Kova on Reddit around two and a half weeks ago at version 0.4.9. We're now sitting on version 0.6.14 with so many touch up features across the codebase. I am appreciative to all that have been involved bug hunting, making recommendations, contributing code, translations, tests (thanks @ayush7614), and more.
Ross
ross@kova.md