The philosophical drive for Welkyn is to create a window to the AP network. That is, persistence of data is not an anticipated feature. Welkyn will preserve local data, but will be, effectively, a sliding window into the fediverse. Historic data from remote instances will not be kept. The experimental motivation is to address the infinite database creep of existing fediverse implementations. This ought to allow the software to run on less powerful hardware, and require fewer resources, compute, storage, or otherwise. While this may sound drastic, with a long enough window (90 days or so), and combining this with persistent local data, some rules about keeping conversations in which the user participated, or bookmarked a post, I anticipate that there will be minimal impact on the user who merely wishes to communicate with other fediverse users while significantly reducing hard-disk and compute requirements with regards especially to databases.
The general structure of the Welkyn application is a monolithic service. gunicorn runs the flask app which will handle the UI (at least for now) and the api that will be necessary for ActivityPub interop. This will allow me to also write or implement a task queue in line with the rest of the application, and hopefully require no additional deployments other than the server.
My general plan is to leverage sqlite to implement the task queue (which I anticipate to be mostly used for outbound federation and fetching remote AP objects. Some maintenance tasks may crop up, and will also be run in some cron-style fashion). This will necessitate a side project of project scale, but I have some ideas on how to go about this.
After a few days of work on the flask app and the skeleton of the whole, I’ve established a framework for authentication, and the beginning of an administrative UI. The interesting work will begin with the task queue and ramp up with the activitypub implementation.