An article about Building the Self-Agency Mobile Ecosystem: Push Messaging
Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently. But Who Cares Who Delivers Our Notifications? Our answer is: we care, and we do not like being locked in to depending on one mega-corp's system.
Therefore, in our libre mobile computing devices, we require a push-messaging infrastructure built from open standard technology that gives us freedom to choose our service providers and authority over them.
Should we consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa?
Not necessarily, and I will attempt to explain why.
Another upgrade in my self-hosted IT infrastructure.
Nextcloud is a self-hostable platform centred around file storage, providing a plug-in framework expandable to a broad range of services. It is one of the older hosting platforms, and unfortunately showing its age in several respects. I consider few of its default and plug-in apps to be of high quality. However, due to its popularity, stability and support it seems to make a good base for file storage services and connecting other services.
I have been running Nextcloud for years but so far only using it for one core stable service (contacts and calendar) and some experiments. This is partly because my deployment is an old, stale configuration, stuck on an old version. I need to update to a maintainable deployment.
There are a few ways to deploy Nextcloud. For this I will use MASH. It is not one of the “official” methods; it's a self-hosting framework from the author of the popular Matrix self-hosting framework.
The MASH Nextcloud doc says, after running the initial installation, we need to intervene, with a second ansible run to print some credentials, then an interactive cut-and-paste session, then a third ansible run to finish installation:
After installation, follow Nextcloud's setup wizard... choose any username/password for your account... choose PostgreSQL with the credentials you see after running just run-tags print-nextcloud-db-credentials
Once you've fully installed Nextcloud, adjust its default configuration (URL paths, trusted reverse-proxies, etc.) by running: just run-tags adjust-nextcloud-config
But we want to do this non-interactively: Infrastructure as Code. Nextcloud supports Installing from command line. On our server we can run the in-container equivalent of the occ command shown there:
I've been doing some upgrades on my home IT infrastructure. Twice recently I've been “got” by unfortunate backward-incompatible changes that were made in software I rely on. This one's in Traefik, which is otherwise pretty stable and reliable.
My certificates started expiring. That's when I noticed. The automatic renewal attempts were failing.
Briefly, the behaviour change affects Traefik “routers” (route configurations) that are intended as a full pass-through. When I originally set these up, the traffic they passed through included ACME challenges used for issuing TLS/SSL certificates. Some of these routes are routing a whole block of domain name-space to further Traefik instances which handle specific subdomains; some are routing to VMs running other services such as YUNoHost; and all these expect to manage their own certificates through the ACME protocol.
In our family we look after our own photos — we don't want Google or any other company deciding what we can and can't do with them.
In the past we used various desktop/laptop based open source viewer software, with storage on local disks. More recently we have been running the awesome open source PhotoPrism, with its smartphone-compatible web interface and photo library management features. Although PhotoPrism is impressive judged on its own merits, and has indeed allowed us to manage our photos ourselves, it's just not quite as usable as we'd wish.
