Eliminating the Battery

I've been thinking about the question of selfhosting. Instead of renting a VPS from somewhere, as I'm doing now, why not fire up a machine and run it myself?

The only problem is that of power cuts. We do have a UPS at home, but it's dedicated to the computer and, until recently, the antenna that provides us our Internet. We only put it on when we're actually using it—which until recently meant that the Internet, too, would be switched off when we weren't using it. Not good for running a server!

A couple of weeks ago, our Internet provider set up a repeater on our land, with an additional antenna beaming Internet signals to customers further afield. Because this has to be on 24x7, they set up a completely independent system, complete with a solar panel and battery.

This got me thinking: perhaps I could set up a similar system for a server?

The major expense in a solar panel system is the battery. We have a small, ancient mini-desktop at home that uses about 3.5 amps, which would require a battery of nearly 100Ah to power it 24 hours. Of course, the battery doesn't actually have to run 24 hours: if I'm okay with a few cloudy days' worth of downtime, I can make it work with a 50Ah battery, assuming the sun is shining at least half the day. (Perhaps an even smaller one would also work.)

Using the battery daily will reduce its lifetime. At home, our UPS battery is only being used when there actually is a power cut (or low voltage); at other times its bypassed in favour of the mains. But with a solar-dependent system, the battery would be put to full use every single day.

So I thought: do we even need a battery?

When it was at the height of its power, the Sun never set on the Spanish Empire. If four or five people spread across the timezones team up, perhaps we could borrow that idea for small-scale shared solar-powered selfhosting?

Imagine a setup like this: every day at sundown, my server knows it's time to sleep. So, it offloads data to the next server, about 72 degrees to the west, and incoming requests start getting handled there. In the morning, my server wakes up ready for an offload from its other neighbour 72 degrees to the East.

Of course, there are many details to be worked out Static websites would be relatively simple to rsync across. Dynamic websites, especially those that use databases, would be more complicated (at least, not unless there's some replication magic that I with my limited knowledge am not aware of).

There's also the question of how requests would be redirected once the handover happens. Is there a decentralised way to manage this, or do we need to have a mini-VPS going jpst for that?

And if we're hosting messaging services, we may have to rethink how exactly they work.

Ever since the historic "This machine is a server. DO NOT POWER IT DOWN!!" notice was stuck on a computer in the CERN laboratory, we've gotten used to the idea that servers stay running 24x7. Some protocols have some amount of built-in resilience: SMTP always tries again a few times if the first attempt to deliver a message fails; RSS readers refresh feeds again even if they failed to load the previous time. But I'm not aware of any protocol—at least among widely used ones—that assume servers to be constantly flickering on and off.

In some ways, our assumptions have changed as well. Early real-time chat was a serendipitous activity, only taking place when the other person happened to be online. With smartphones, that "happening" is always taking place, and we assume we can send them a message whenever we like. This is different, of course, because protocols always allow for the client to go offline once in a while...as long as the server is permanently running. Modern XMPP saves "offline" messages to be returned when the user comes back online—but if the user's server is also offline, the message immediately fails.

What if we made that a two-step process, where the sending server, too, holds onto the message for a bit until the receiving server comes online? If the sending and receiving servers are too far apart, we could also pass them to a third, intermediate, server, which is going to stay running after the sending server powers down and not before the receiving server boots up. Part of the logic may already be worked out. All we have to do is start thinking of servers the same way as we think of clients: entities that can blink off for a bit, but will be back, before long, after a good night's sleep.

If you have any suggestions or want to help flesh this idea out, feel free to contact me @badrihippo@fosstodon.org!