Today work began on wrangling the beginnings of a kubernetes deployment for this blog. A simple dockerfile to serve the site, based on the one provided by the hugo team, was deployed to the cluster. After some fiddling with authentication, secrets, and a local tls CA and certificates, the pods are running. They still need to be exposed through the load balancer – a job for tomorrow. Next, a wireguard link, and nginx configuration for proxying from the frontend VPS to the cluster will need to be created. ...

Today, content began to be organized for the blog. The domain, VPS, and ssh access are already setup for wicknet’s front end. Remaining: setup Ye Olde Wireguard Backhaul between home server and frontend. setup k3s deployment to host the blog on the cluster setup k3s deployment to host the email server for the domain on the cluster.

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. ...