28 January 2023

Been a while since I wrote anything on here and the reasoning actually has little to do with the subject matter: I've just been busy/slack/distracted, whatever you care to throw a dart at, it will hit a target.

Anyway, I made this post back in September 2021. All was trucking along fine until just a few months ago from the time of this writing, when one day I realised I no longer had the Raspberry Pi responding to pings and well, no internet access either.

Upon investigation, no this was no power loss or lack of sun... the little Netgear AC800s modem had blown up. No, not figuratively, LITERALLY.

Images speak for themselves...

So yes, lesson learned, lithium-ion batteries do indeed go boom sometimes. I was actually aware this could happen and technically shouldn't have left the battery in the device while it was hooked up to power constantly... but the thing is, the device was never stable unless it was plugged into both USB power and had it's battery inserted. External power was never quite enough, with enough activity the thing was liable to randomly reboot.

Anyway, so that's that. Remarkably, only the modem and a few surrounding cables were destroyed. The solar charge controller and the Raspberry Pi were, remarkably, unharmed, if not carrying a bit of spare black soot on their surfaces. Where to from here? Well, my internet situation is quite different now. I have Starlink and no longer the old satellite broadband now, as a primary internet connection, so the Optus 4G connection was becoming a bit superfluous anyway (except for when the power goes out at home, obviously). But with Optus' data breach scandal and what not, I wasn't going to be running back to them either.

So, for now, I have no solar powered internet connection but if something cheap and cheerful comes along I would be tempted to set it up again (this time a mini modem/router that doesn't require a constantly inserted battery to function properly).

How is this site running right now, you might ask? Easy, I took the Raspberry Pi back inside my home and hooked it up to the internet there. The RPi does need a new SD card though, as it's been failing for a while now, so I will likely shift this site to my Vultr VPS, but that's the beauty of a lightweight static website - can move it around willy nilly, no problem at all!

06 October 2021

I want to make a call out that I think is needed. Those of us who use "De-Googled" Android phones will be well aware that if you cut out Google Play Services, you generally won't get any push notifications. This makes sense, as most apps out there simply register with FCM (Firebase Cloud Messaging, formally known as Google Cloud Messaging) to provide the push notifications.

For apps distributed on the Google Play Store, this is understandable. FCM is easy to integrate with, well known and since the app is being distributed on the Play Store, obviously the user is already running Google Services and therefore isn't going to care where the notifications come from.

However, if (like myself) you run a De-Googled Android OS, like CalyxOS, GrapheneOS or LineageOS without the GAPPS package, Google Play Services will be (mercifully) absent and along with that, of course, FCM and push notifications. Services like MicroG are available to help mitigate this, but this still means sending data to Google servers.

In some cases, the lack of notifications is actually a good thing, as suddenly you're not getting spammed with what are somewhats useless and distracting notifications. Other times, this is rather inconvenient, especially if you want those instant messenger notifications to come in right after they are sent. Some privacy-aware app developers have worked around this; notably the F-Droid version of the Tutanota email app implements it's own system for notifications. Likewise K-9 Mail and Signal.

This is admirable, and appreciated, however if every app started doing this we end up with the same problem that push notifications via FCM was supposed to fix - that is, having a single push notification server to register services with, allowing apps to sleep in the background to maximise battery life. If you have a bunch of apps having to wake up regularly and polling for new notifications, battery life suffers.

Ideally, the user would have a choice of more than one push provider. Because of the nature of push technology, this isn't as simple as installing some other app on your device to replace FCM. Some of us, especially those getting more and more into self-hosting, would love to be able to host our own push notification servers. Those self-hosted server options are available, but without the apps supporting them, they are useless.

UnifiedPush

UnifiedPush is a protocol and small collection of tools for Android and Linux that, as their site says, "let the user choose how push notifications are delivered. All in a free and open source way".

It uses what it calls "Distributors" to give notifications for apps that support it. For example, it currently has three distributors available - FCM (Google Firebase), Gotify and what it calls NoProvider2Push, a hardcore and experimental way of sending notifications without a push provider, but requires a static IP address on your device.

Of those three, two are the most obvious options - FCM and Gotify.

We already know about FCM, it's ubiquitous and the standard that we've already mentioned. Gotify on the other hand is a well known self-hosted push notification server. For those of us who would want to self-host or know someone who would host it for us, this is the logical replacement for FCM.

What this means is if developers code their applications to be integrated with UnifiedPush, they not only can use FCM as they would have already thanks to the UnifiedPush FCM Distributor, but then users would also have the choice of something like Gotify. Gotify is in fact the default provider on UnifiedPush according to the webpage.

I imagine with increased adoption the distributor options would also increase in number.

But for now, even having the option of Gotify would be a huge boon to those of us wanting to retain reliable and efficient notifications and not have to send data to Google servers. Instead of apps having to exclusively code in support for alternatives such as Gotify, coding in UnifiedPush should make it all easier on the devs too, as it provides an abstraction that allows the Distributors to take care of the rest.

The FCM Distributor is also embedded in UnifiedPush and the website states:

Some applications using UnifiedPush installed from the Play Store automatically use Google’s Firebase Cloud Messaging if no UnifiedPush Distributor is detected.

So, there's nothing to lose here for developers, and a lot to win for privacy-aware users.

Currently Supported Apps

Currently, only four applications implement UnifiedPush. As of writing, this is:

• FluffyChat
• Fedilab
• Tox Push Message App
• SchildiChat

And then a couple of apps currently in progress with UnifiedPush support:

• Element Android
• Nhekho on Linux

Time to Act

I say we try to spread the word and get this to change. Looking at the UnifiedPush GitHub page, development looks very active on the project itself, so the time is now to start implementing, testing and seeing about finally giving users an option that doesn't mean settling for sending data to Google.

04 October 2021

If you can forgive the somewhat buzzword-ary nature of the title, here we're going to see how to sync bookmarks for Lagrange.

Lagrange is a superb browser for the Gemini protocol; just a lovely piece of software that's comfortable and in line with the protocol it's built to be used with, is very good on resources. If only our web browsers could be this nice and light at the same time!

Thankfully it also has the option to save bookmarks to a simple bookmarks.gmi file (press CTRL+S while on the bookmarks page). Try it, it's easy and we'll need it for our next steps further on.

Lagrange ALSO has the ability to use any Gemini page containing links as a bookmark source. This is very handy, and this will allow us to create a (albeit crude) way to sync bookmarks between our devices.

Note that the below instructions apply to a Linux machine specifically, but could be easily extrapolated to any other operating system that Lagrange runs on, you'll just have to adapt the config directory for Lagrange accordingly.

The Cloud

Honestly, I hate using this word. The 'cloud'. I'm cringing as I write this.

Nevertheless, though, for lack of a better word, this method of syncing uses some form of cloud syncing. In my case, I use NextCloud. But you could use any similar automatic files syncing service, like Dropbox or any such similar thing.

Let's Do It

Assuming on your original computer you have saved the exported bookmarks.gmi file to ~/Downloads, the next thing to do is to copy the file to our cloud storage syncing folder, eg:

cp ~/Downloads/bookmarks.gmi ~/NextCloud/lagrange-bookmarks.gmi

Next, making sure Lagrange is closed so nothing gets messed up, you'll want to delete Lagrange's internal bookmarks storage file. Yes, you heard that right. You'll see why in a moment. If the existing bookmarks remain, you'll end up with doubled up bookmark entries.

NOTE - Update 2021-10-06: The author of Lagrange, 'skyjake', has since told me that he doesn't recommend deleting the bookmarks.ini file as this will also delete any saved feeds and custom icons you may have set. Please keep that in mind. If, like me, you only are concerned with bookmarks then you can delete the file safely, but otherwise either leave it in place as-is or you could edit the file and carefully delete the bookmark entries within, but make sure to back up the file first!

We can do this as thus:

rm ~/.config/lagrange/bookmarks.ini

Please note that prior to Lagrange 1.7.0, the bookmarks file is actually called bookmarks.txt.

Then, fire up Lagrange and enter into your location bar the location of your now syncing bookmarks file from earlier, eg:

file://~/NextCloud/lagrange-bookmarks.gmi

This will bring up the file that you exported earlier. Now for the final bit of magic. Hit CTRL-D or click Bookmark Page.... When the bookmark dialog comes up, then click Use as Bookmark Source. This is important! This is what saves the bookmark as a Remote Source. Call it whatever you want, I called it simply My Bookmarks.

Once your bookmarks file is, well, bookmarked... then go to your actual bookmarks in Lagrange. You'll simply now see an entry called My Bookmarks as the sole bookmark and if you click it, you'll be taken to the full list of the bookmarks that were exported earlier!

Ordinarily, hitting Refresh on the bookmarks page should automatically display the full list of links in Lagrange's bookmark page without having to click on the My Bookmarks entry first, but I found this only works after restarting Lagrange after adding the bookmark source. YMMV and all that.

Done

And that's it!

To access your sync'd bookmarks file on another device, you simply repeat the above process of adding that file as a Bookmark Source on that device's install of Lagrange, eg. by bookmarking the file, and setting it as a Bookmark Source.

The obvious downside to this is it's not completely automatic, as anytime you want to add more bookmarks to the synchronised bookmark source file, you'll have to repeat the process of exporting the bookmarks again or simply adding them by hand to the already exported file. Saving a bookmark via the Lagrange interface like normal will still just save the bookmark locally to that instance of Lagrange. Still, it allows us to easily get our bookmarks list across our devices, all without any sync features being built into the browser or using some external service.

Note that if you have your own Gemini capsule, you could ALSO simply store the remote bookmarks file on your server as well, negating even using a file syncing service at all. You would just point Lagrange at the Gemini address of your server where the file is stored and bookmark... save as bookmark source... etc. Very easy.

If anyone has any better ideas or improvements to this, do let me know!

26 September, 2021

Yes, that's right, this site is now completely solar powered. Actually, it has been for about a week now but I wasn't going to write about until I was sure everything was working correctly.

Also, not only this site - but my Yarn.Social pod as well!

Technically...

For a bit of background, I've had the solar setup itself for nearly two years.

What is this 'setup'?

An Optus AC800s 4G/LTE modem (actually a Netgear device, just branded by the carrier), connected to two MiMO Yagi antennas, feeding into to a GL-AR300 Mini Router, powered by a 160W solar panel connected to a regular car battery, albeit a deep cycle one. The GL-AR300 is then connected to a 110 metre (approx) line of Ethernet cable that feeds into the household. The reason for this distance is the location of the solar setup and antennas is where the mobile signal is at its strongest, whereas back at the house the signal is extremely weak.

I live quite rural and this custom setup has served as my secondary internet connection for some time. The primary internet connection is, of course being rural Australia, is a satellite broadband service. The satellite internet actually works remarkably well, no doubt the technology has come a long way. But you can never get around 600~ms pings and limited data allowance, so some time ago I invested in the Optus mobile broadband deal which netted me the AC800S modem and 500GB per month data allowance. Still a far cry from the bandwidth and data afforded to landline and even fixed wireless broadband users, but it's better than nothing. The 4G service also has vastly improved ping, being around 30~ms to other Australian servers and still easily half the latency of the satellite when going elsewhere around the globe. It was then that I set up the solar system, primarily as it would be impractical to run an electrical cord all the way from the house to the spot where the solar installation is. And also because it would be a bit of a little project.

In any case, this service was mainly used for streaming things like Netflix and YouTube, which could obviously chew through the 20GB allowance of the satellite service in no time, but otherwise didn't have a lot of utility.

Until the day, recently, I figured it would be totally sensible to hook up my Raspberry Pi 3+ to the solar installation and use it as a server for this site. As you do.

Why?

The answer to that is simply, because I can. But honestly I was heavily inspired by Solar Low Tech Magazine. Check that site out, it is quite an eye opener and some great content on there, even if their battery level overlay thing is a bit weird looking.

Anyway, this site was originally hosted on NearlyFreeSpeech and while in all honestly it cost next to nothing to do so, I had an itch to scratch. Such a basic website could easily be hosted from home, being a static site with deliberately old-school stylings. Seriously, load this site up in a terminal browser like links, it works perfectly.

Note: Of course the aforementioned Yarn.Social pod I run on this system (which came a little after I initially set this up) is NOT a static site, but still seems to be quite low on the system resources.

So, a ~~Raspbian~~, sorry, Raspberry Pi OS install later on the Raspberry Pi with an Nginx server, I had something I could transfer this little site to.

Well, almost.

Turns out you can't forward ports on a mobile modem/router like the AC800S. Well, you can, but it won't do anything. This is an ISP restriction unfortunately. More about that in a moment. In any case see a couple of images below. These are dithered images, both to save bandwidth and also because in all honesty my setup is jerry rigged AF, and cable management has never been my strong suite. It's not attractive, so not being in full coloured HD glory is a good thing.

Bottom Left to Top Right: GL-AR300 mini router, 20A solar charge controller, Raspberry Pi 3+, Optus AC800s modem

As I said, this is a very jerry rigged setup. All the bits and bobs are mounted inside an old second hand gutted meter box that I picked up from the local tip shop for $5 and the meter box (and antennas) are mounted on star picket fence posts. The solar panel itself is mounted alongside this on it's own fence post (pictured below). Both the AC800S and the AR300 mini router are powered off the solar charge controller's two USB ports. The Raspberry Pi is then powered off a 5V, 2.1A micro USB power pack connected to the solar charge controller's wired output.

The battery is then at the base of the meter box post under some weather-proof wrapping. And by weather proof wrapping I mean an old unused heavy duty rain coat.

Exterior shot of the setup. Jerry rigged!

So, yeah, this is almost the sort of thing you would expect to see in a Mad Max setting, but that's kind of what I like about it. It's horrendously unprofessional, make-shift, but it works. And this basic setup has lasted through all sorts of terrible weather events and seasonal changes, including winds that have felled entire trees.

The solar panel and solar charge unit (as a combo) cost about $100 off eBay. The Raspberry Pi I already had from running a LibreELEC install and I can't remember what that originally cost me, but it wouldn't have been a kings ransom.

Otherwise, every thing else was simply what I had lying around. So besides the cost of the 4G/LTE internet connection itself (an $85 per month plan), the overall cost of this has been very very little.

No Port 80 and 443 For You!

Indeed, as mentioned earlier, these common internet ports are blocked off at ISP level, so no amount of port forwarding in the router will expose our little web server to the internet. So, to get around this we have to use Pagekite, a localhost tunneling solution, similar to the likes of ngrok. Unfortunately, the pagekite.net service itself seems to be lacking attention and while the service itself still works fine, heavy rate limiting is in place. The site says you can request these to be lifted, but I had no luck contacting anyone (as of this writing) to actually get this in motion. Pagekite, the service, never had this rate limiting originally but unfortunately after it was used by some spammers a couple of years ago, they had to put those in place by default.

Thankfully, however, Pagekite is more than just a service. The pagekite.py program that the site provides as a client for connecting to the service can also be used on any server to act as a frontend, which then in turn acts as the tunnel to your localhosted pagekite.py (called the backend - I know, it seems confusing this naming convention, but there you go). Luckily I have an existing hosted VPS I use for a few other things, so I simply run the frontend Pagekite on that VPS, point the DNS at it, and then connect to that frontend from my Raspberry Pi to establish the tunnel. Hello world wide web.

It's not quite that simple insofar as a bit of reverse proxying with Nginx is needed also, but it's not too hard.

Uptime

So, you may be wondering about uptime. As a solar system, and being 'off the grid', there are times where no doubt there will be enough lack of sunlight that power will be insufficient and the server will go offline.

This certainly can happen, but unless there's multiple days in a row of foul, very downcast weather, it runs almost indefinitely. These devices hooked up to the system are very power efficient, and the 160W solar panel is admittedly perhaps even a bit overkill for this purpose. It will be a matter of how much the battery degrades and any other factors that work against it. For now, it is fairly reliable, but there will be days here and there where the voltage may drop enough for the solar charge controller to cut power until sufficient power is restored.

And that's okay. The other potential caveat is how much extra power the Raspberry Pi will use while hosting the Yarn.Social pod, versus only serving static content. I don't know, I wouldn't even begin to know how to measure it. I can't imagine it would be much extra, and time will tell if we seem to lose more power than normal.

Advantages

It will all depend on what metrics you are measuring as to whether there is any advantages to this setup.

Certainly, it won't be speed or uptime percentages. There's not really even any monetary advantage, as it's a supplementary system and the rest of my home is still very much grid powered. The tangible advantages are very few.

But what it is, is a proof of concept, like the aforementioned Solar Low Tech Magazine site. We don't need high powered, always on servers, all the time. Yes, critical production servers are a different story, but here we're talking about a small personal website and a self-hosted decentralized social network pod. These things do not have to have 100% or even 99% uptime. It just needs to get the job done.

What's more, this is a system that runs off completely renewable energy. All the while providing a fairly speedy (yes, around 50Mbps down is speedy to a rural Australian!) wireless broadband service for a household, streaming video and hosting a couple of servers, all in one little efficient solar powered bundle.

It also has to be said hosting any sort of website on a wireless internet service is rather unconventional, especially one that averages between 5-8Mbps upload. This is why keeping transfers as small as possible and resource usage low makes sense just beyond keeping power usage down. The other downside is relying on an external server (the VPS) to even get this whole thing public facing. That's not ideal, but then again there isn't any other choice that I'm aware of when your ISP blocks port forwarding. At least the VPS was already getting used for other things, so it's not a major additional component.

But, it can be done and that's all that matters to me.

Final Words

If anyone has any comments or suggestions, please email me on the address listed at the bottom of this page, or message me on Yarn.Social/twtxt if you are following me on that network.

I am not an expert, I only know just enough to have set this up and I wouldn't be surprised if aspects of it are enough to make more seasoned solar energy enthusiasts/users recoil in horror. Perhaps the same for some web developers etc. But it is what it is, and I've enjoyed tinkering with it.

Lastly, I haven't detailed much on the technical side of things to keep this from getting too long, but if anyone wants more info in regards to things like Pagekite configs or any other aspect of this system, by all means ask.

Peace.

September, 2021

I haven't updated this site much lately, and figured this might be the best way to do it. Totally stealing inspiration from Tom at macwright.com with his regular Recently articles. Rather than make multiple posts for a given month, I might just update this page (and subsequent monthly Recently pages) during the month as I feel like adding to them.

Begin 2021-09-03

Site Downtime

Occasionally, you might notice (all 2 or 3 of you whoever read this site) that this site is sometimes, well, down.

Never fear though, it's simply because I don't always keep up with the hosting pay-as-you-go credits that my host nearlyfreespeech uses as it's payment model.

Although I will strive to keep up with it, I don't consider occasional downtime on small non-production websites to be too big of a deal. Indeed, the site over at the solar version of Low Tech Magazine explains why they have some downtime and why they have a pretty good excuse for it.

Now, granted, my excuse is less to do with demonstrating renewable energy and lacking sunlight and more to do with being slack and absentminded, but I still like the reasoning that maybe, just maybe, not all websites have to be online all the time. On that note though, I am very tempted to try and move this website to a similar homegrown solution as the Solar Low Tech Magazing site. It would be quite fun and very satisfying, I think.

Learning C

Otherwise, recently I've been trying to learn the C programming language. I've tinkered off and on with it in past months, but I'm trying to make a better go of it.

My main previous coding experience is with the likes of PHP, Javascript etc so mostly just web programming (yes, I know, it's not what everyone considers programming). Other than that, just relatively basic shell scripting.

So, I guess C is quite a jump but even having prior PHP and JS experience seems to help adjust to some concepts.

I actually really like C. Not only does learning it help to be able to understand some of my favourite suckless utilities at the source level, I actually find C to be a strangely elegant and simple language. This isn't to say that I've always found C to be a total breeze to learn or haven't had challenges, but once you pick up on some of the basic concepts and typical gotchas, it's a no-nonsense language well worth learning. I also like the fact that if you keep the code as portable as possible, which isn't that hard for relatively basic programs, you can compile and run the program on nearly any device you can poke a stick at.

Lack of The Linux Rain Content

This one I'm a bit less happy about. It falls both in the slack and also being too busy camps. That sounds like completely opposing scenarios, I know, but it is what it is.

I haven't posted any new articles on there since February of this year, and hope to change that soon. I haven't kept up much with the happenings in the Linux world, so to speak, yet I still use the platform every single day. That's okay though, everyone has different priorities at different times. I never intended for the site to be a fast paced mecha of Linux content, but I would still like to add more and keep it a little more active than it currently is.

End 2021-09-03

Begin 2021-09-19

My own Yarn.social instance

Finally, have my own Yarn.social Pod!

Been tempted to try this for a while and now it's finally done, helping to contribute to the "decentralised" aspect of the platform. It's hosted on my Raspberry Pi 3+ at home, so that's nice too. Actually, so is this very site now, but all of that definitely warrants a whole separate new article...

End 2021-09-19

I don't hate it, I just hate overuse of it

If there's one thing we can all appreciate about the rise of JAMSTACK, is that it brought about renewed vigor even amongst the mainstream for static built and deployed websites.

This is a good thing. The web has become increasingly bloated for various reasons, and along with that we've also seen increasingly complex websites/apps that put ever increasing load on the server, in terms of those that dwell sorely server-side. With static generated websites being back in vogue since, I dunno, 2016 or so, we've seen more and more pure HTML and CSS being deployed that only do (or connect to) server stuff when they have to, instead of the server itself being responsible for spitting out the HTML and CSS. A healthy bit of Separation of Concerns, if you will.

Unfortunately, somehow this has also led to websites being increasingly written in and depending on JavaScript (JS). Entire JavaScript frameworks have risen (almost too many to count nowadays) and become incredibly popular. I wish I were joking, but it's even fairly common to write HTML (or even CSS) inside JavaScript. Even one of the more sane JS driven frameworks, Svelte, tends to save all the HTML and CSS (well, if the CSS is written inline in the HTML anyway) inside the JavaScript bundles. When coupled with it's sister project, Sapper, which allows you to actually generate a static website, this is especially awkward as you have both static pages AND a copy of all the HTML and CSS in the .js bundle files as well. Hello bloat.

For mine, JavaScript has its place. To assist with rudimentary actions or effects on a webpage, or to do a little bit dynamic fetching of data (ala AJAX, as long as it has graceful degraduation). But having a website that could otherwise be written completely statically, instead pulling in hundreds of kilobytes just to "hydrate" the interface and create a kind of "SPA" (Single Page Application) feel...? I don't know, but it seems a little insane.

I know this because I myself once fell victim to the hype and wrote a website that was for all intents and purposes, a normal website. A home page, about section, a few other pages related to the business it was for. I did this with the aforementioned Sapper/Svelte combination. Now, the only really dynamic part of this website was a quotation form, i.e it took user input and generated a quotation of item costs, and then the user could choose to proceed (or not) in which case the system would send an email.

The quotation portion of the site could have been done in, at the very least, just a small Svelte component, accessed only when and IF the user wanted to get a quotation. Instead, no, old mate Andy here decided to build the entire website in Sapper instead. What Sapper does is, at compile time, builds the site and generates the .js bundle files, and also crawls the urls inside the site to generate a static version of the site as well. So you get a combination of good old .html files, that has links to the bundle files in the footer of the HTML which then loads and "hydrates" the interface, therefore handing off routing responsibility etc to the Sapper engine instead of letting the browser follow the URLs and loading say, about.html in it's entirety. This is meant to give that instant loading "app feel". It's nothing new, developers have been using AJAX to achieve similar effects for years, but projects like Sapper/Svelte exist to try make development faster and less fiddly.

Which is noble enough, and I'm not here to bag out Svelte or Sapper. Or even React, even though I find its syntax abhorrent. These projects exist for a reason and can have legitimate use. And of course there is the whole inbuilt "react-ivity" aspect that all three of the projects I just mentioned tout. The problem is impressionable or inexperienced developers, or just plain Soydevs, coming along and using these frameworks for what may be essentially brochure-style websites, instead of say a mobile application. That's pretty crazy, and that's how you get websites pulling in hundreds of kilobytes of JS on top of already existing static HTML/CSS to basically give a slightly faster response and a smooth transition maybe between pages. However, that's after the website potentially takes twice as long to load initially.

Then there's what I'll call technical-debt. That site I mentioned that I made with Sapper? It'll be one heck of a job pulling it apart and converting it to normal HTML/CSS. I essentially created a bit of vendor lock-in for a site that should never have needed to be that complicated or bloated. Lesson learned.

So, TL;DR: If we're going to encourage a more static web, let's write actual static websites rather than deferring it all to JavaScript. Use JS where necessary, but no more than that. if you have to ask yourself, "should I really need JavaScript just to do this?", then you probably don't.