8:30 p.m.
Greetings list -
Inspired by the great low powered server described on the lowtechmagazine
website, I'm interested in setting up a home solar powered server for my
personal website. I set up a webserver on a raspberry pi and made an
instructable about it
<https://www.instructables.com/id/Host-your-own-blog-from-a-25-Raspberry-P...
long ago.
While I appreciate the need to accept some downtime, I wonder if folks on
this list have thought about strategies for federating solar powered
servers to share load? Up here in Denmark I have a great deal of daylight
at the moment - maybe 18 hours or so. If I could mirror other small sites,
and serve them when their hosts are low on batteries, I'd be happy to do
it. And I could use the same sort of help when winter comes.
I wonder if anyone here has considered creating a solar-energy load
balancing service. Members would get mirrorred in other member's locations,
and report their remaining battery capacity / charging status to the
balancer. The load balancer could then route requests to whoever has the
most charge / active sunlight at the moment. Or perhaps there is a strategy
that would use something like the bittorrent protocol to server websites?
Interesting in any thoughts you have. And thanks for making and sharing
such excellent documentation!
Amos
--
http://amosamos.net
11:23 a.m.
Hey! Cool idea and thanks for sharing the kind words.
Let's explore this ...
So, as I understand load balancing, it requires a piece of software that
receives HTTP requests and it makes a decision about where to route that
request based on an algorithm. An example of an algorithm is, route to
the web server that has the least amount of connections.
The first thing that comes to mind is: does load balancing require this
"central" first point of contact? And if so, who will provide the power
for that! ;) This brings along the "always online" needs, centralisation
of point of failure and a place to look at everyone's metadata, etc.
I must ask: is the idea of load balancing itself an "always online" hangover!?
RE: bittorrent, that's a nice idea too. I also thought about the DAT
protocol and it has a nice section on the considerations between:
https://docs.datproject.org/docs/faq#how-is-dat-different-than-academic-t...
Where it points to the drawback of "BitTorrent is for sharing static
files, that is, files that do not change over time." for website
content.
So, with DAT (or something similar), we would be downloading copies of
each others websites to our own computers and serving them locally. That
kind of makes sense to me as a nice approach.
If I had to guess at the considerations ...
* Content is changing, so needs to handle syncing / updating
* Needs to be redundant if one server goes down ("offline first")
* Needs to be discovered without central authority (DNS)
* Should be performant for lower bandwidths
* ???
Then to map those considerations onto a protocol ...
Interested to hear further thoughts!
Luke
On 0, Amos Blanton <amos.blanton(a)gmail.com> wrote:
Greetings list -
Inspired by the great low powered server described on the lowtechmagazine
website, I'm interested in setting up a home solar powered server for my
personal website. I set up a webserver on a raspberry pi and made [1]an
instructable about it long ago.
While I appreciate the need to accept some downtime, I wonder if folks on
this list have thought about strategies for federating solar powered
servers to share load? Up here in Denmark I have a great deal of daylight
at the moment - maybe 18 hours or so. If I could mirror other small sites,
and serve them when their hosts are low on batteries, I'd be happy to do
it. And I could use the same sort of help when winter comes.
I wonder if anyone here has considered creating a solar-energy load
balancing service. Members would get mirrorred in other member's
locations, and report their remaining battery capacity / charging status
to the balancer. The load balancer could then route requests to whoever
has the most charge / active sunlight at the moment. Or perhaps there is a
strategy that would use something like the bittorrent protocol to server
websites?
Interesting in any thoughts you have. And thanks for making and sharing
such excellent documentation!
Amos
--
[2]http://amosamos.net
References
Visible links
1. https://www.instructables.com/id/Host-your-own-blog-from-a-25-Raspberry-P...
2. http://amosamos.net/
_______________________________________________
HBSC mailing list -- hbsc(a)we.lurk.org
To unsubscribe send an email to hbsc-leave(a)we.lurk.org
11:30 a.m.
Oh, forgot one link ...
The "Network topology" documentation of the SSB[1] (offline first social
network protocol) documentation does point out to some disadvantages of
the DAT protocol for building trusted networks of sharing:
https://www.scuttlebutt.nz/concepts/
The opinion is:
bittorrent/DAT like protocols are pretty good for moving heavy data.
(video, OS images, etc) the best part is that you collaborate only
with other peers who are invested in a particular dataset.
But the weakness (in my opinion) is that they rely on a DHT. DHTs
are bad because peers collaborate anonymously, you have cannot
estimate their trustworthyness and consequently, DHTs tend to have
poor privacy (because an adversary could easily add peers that
monitor you) and poor sybil resistance (again, because you have no
way to know that a peer is "near you" or "on your side")
This happens because work is distributed between peers uniformly.
Peers are mapped into a hash ring, so to get a hash, you traverse
peers closer and closer to your target.
One of the core ideas in ssb is to map the computer network along
the social network (thus defeating spam, because you arn't friends
with spammers)
BTW, I'm not interested in a religious protocol war. I think it's nice
to focus the discussion on what protocol works for what needs. And there
are quite specific needs for low tech.
Luke
[1]: https://ssbc.github.io/scuttlebutt-protocol-guide/
On 0, Amos Blanton <amos.blanton(a)gmail.com> wrote:
Greetings list -
Inspired by the great low powered server described on the lowtechmagazine
website, I'm interested in setting up a home solar powered server for my
personal website. I set up a webserver on a raspberry pi and made [1]an
instructable about it long ago.
While I appreciate the need to accept some downtime, I wonder if folks on
this list have thought about strategies for federating solar powered
servers to share load? Up here in Denmark I have a great deal of daylight
at the moment - maybe 18 hours or so. If I could mirror other small sites,
and serve them when their hosts are low on batteries, I'd be happy to do
it. And I could use the same sort of help when winter comes.
I wonder if anyone here has considered creating a solar-energy load
balancing service. Members would get mirrorred in other member's
locations, and report their remaining battery capacity / charging status
to the balancer. The load balancer could then route requests to whoever
has the most charge / active sunlight at the moment. Or perhaps there is a
strategy that would use something like the bittorrent protocol to server
websites?
Interesting in any thoughts you have. And thanks for making and sharing
such excellent documentation!
Amos
--
[2]http://amosamos.net
References
Visible links
1. https://www.instructables.com/id/Host-your-own-blog-from-a-25-Raspberry-P...
2. http://amosamos.net/
_______________________________________________
HBSC mailing list -- hbsc(a)we.lurk.org
To unsubscribe send an email to hbsc-leave(a)we.lurk.org
4:18 p.m.
Hey Luke -
Thanks for the response and the great points! What you say about a load
balancer is very true - single point of failure, source of metadata, etc. I
guess I suggested it because it was the only approach I've heard of
technically that might be able to do the distribution. But other, more
torrent based approaches are more interesting and probably more robust.
On Mon, 27 May 2019 at 11:30, Luke Murphy <lukewm(a)riseup.net> wrote:
I must ask: is the idea of load balancing itself an "always
online"
hangover!?
Yes it is! :) I suspected I might get that feedback. Having been in charge
of the Scratch online community, infrastructure, and development team for
about 4 years I'll admit I got a little obsessed with the idea of staying
up. But my own reasoning for wanting a way to share the load has less to do
with power, and more with the human energy required to keep a local server
secure and up and running. I'm thinking of hosting my personal website
(currently here, but I'm planning a redesign: http://amosamos.net). It
might go down for lack of power, and it might go down for lack of proper
configuration, updates, my router, my ISP - there are plenty of potential
failure points besides power. I think it would be really cool if I could
federate with a bunch of other folks with some shared interests / needs /
and values so that if my server went down, my site would stay up for a
while (a week or so?) while I sort out the problem. It's not that I mind a
day or two of downtime, but potentially it could be weeks. I'd like to be
able to be flakey, and to support others when they are flakey for a while,
and still mostly be up most of the time. It's not just the weather that is
unpredictable, it's also the server admin and their time and circumstances.
Of course this leads to social challenges: For example, I won't agree to
cohosting content for a Nazi's website, or one that's disrespectful to
women. But I would welcome a conversation about general values and
guidelines with a group of people I was federating my solar powered hosting
with - say 2 to 10 or so. In many ways, I think the current terrible state
of FB and Twitter is because the people in charge pretended that the
technical challenges were the most important to spend time on while trying
to ignore the (now festering) social questions. Lets agree on what is good
and reasonable, and support one another.
RE: bittorrent, that's a nice idea too. I also thought about the DAT
protocol and it has a nice section on the considerations between:
https://docs.datproject.org/docs/faq#how-is-dat-different-than-academic-t...
Where it points to the drawback of "BitTorrent is for sharing static
files, that is, files that do not change over time." for website
content.
Searching on this topic yesterday I found this thing called Planktos which
claims to work with plain existing (recent / updated) browsers to serve
static assets via torrenting. It appears as though they have a strategy for
cache invalidation.
https://github.com/xuset/planktos#how-it-works
It appears to be using other viewers to serve the files though - not
sharing across multiple hosts? Or maybe you can setup seeds that way - I
dunno.
So, with DAT (or something similar), we would be downloading copies
of
each others websites to our own computers and serving them locally. That
kind of makes sense to me as a nice approach.
Me too!
If I had to guess at the considerations ...
* Content is changing, so needs to handle syncing / updating
* Needs to be redundant if one server goes down ("offline first")
Above seem possible.
* Needs to be discovered without central authority (DNS)
I have no idea how this could work. I mean DNS has to be involved if you
are using a domain name, but what happens after DNS to route the request to
wherever it needs to go next? The only thing I can imagine is some kind of
load balancer. :/
Finally, I'm not sure if solving this well would kind of invalidate one of
the points of lowtechmagazine's solar server: To show that constant uptime
is not a necessity, and that if we change our standards a bit we might, you
know, be able to maintain a livable biosphere. ;) I agree with that, but it
seems like it should be possible to have cheap solar servers and pretty
decent uptime (and manage traffic spikes) too.
Thanks for the fun conversation! I'm interested in any further thoughts you
or others have.
Amos
* Should be performant for lower bandwidths
* ???
Then to map those considerations onto a protocol ...
Interested to hear further thoughts!
Luke
On 0, Amos Blanton <amos.blanton(a)gmail.com> wrote:
> Greetings list -
> Inspired by the great low powered server described on the
lowtechmagazine
> website, I'm interested in setting up a home solar powered server for
my
> personal website. I set up a webserver on a raspberry pi and made
[1]an
> instructable about it long ago.
> While I appreciate the need to accept some downtime, I wonder if folks
on
> this list have thought about strategies for federating solar powered
> servers to share load? Up here in Denmark I have a great deal of
daylight
> at the moment - maybe 18 hours or so. If I could mirror other small
sites,
> and serve them when their hosts are low on batteries, I'd be happy to
do
> it. And I could use the same sort of help when winter comes.
> I wonder if anyone here has considered creating a solar-energy load
> balancing service. Members would get mirrorred in other member's
> locations, and report their remaining battery capacity / charging
status
> to the balancer. The load balancer could then route requests to whoever
> has the most charge / active sunlight at the moment. Or perhaps there
is a
> strategy that would use something like the bittorrent protocol to
server
> websites?
> Interesting in any thoughts you have. And thanks for making and sharing
> such excellent documentation!
> Amos
> --
> [2]http://amosamos.net
>
>References
>
> Visible links
> 1.
https://www.instructables.com/id/Host-your-own-blog-from-a-25-Raspberry-P...
> 2. http://amosamos.net/
>_______________________________________________
>HBSC mailing list -- hbsc(a)we.lurk.org
>To unsubscribe send an email to hbsc-leave(a)we.lurk.org
_______________________________________________
HBSC mailing list -- hbsc(a)we.lurk.org
To unsubscribe send an email to hbsc-leave(a)we.lurk.org
--
http://amosamos.net
2:39 p.m.
Ah, too many interesting things ;) Planktos is a great resource, thanks
for sharing! By chance, I just saw https://n-o-d-e.net/index.html and
they have this DAT driven "P2P Backup" button right there on top of the
menu. If you run https://beakerbrowser.com/ or have the dat CLI
installed (npm install -g dat), you can grab a copy just like that! Nice
to see these approaches appearing ...
On 0, Amos Blanton <amos.blanton(a)gmail.com> wrote:
Hey Luke -
Thanks for the response and the great points! What you say about a load
balancer is very true - single point of failure, source of metadata, etc.
I guess I suggested it because it was the only approach I've heard of
technically that might be able to do the distribution. But other, more
torrent based approaches are more interesting and probably more robust.
On Mon, 27 May 2019 at 11:30, Luke Murphy <[1]lukewm(a)riseup.net> wrote:
I must ask: is the idea of load balancing itself an "always online"
hangover!?
Yes it is! :) I suspected I might get that feedback. Having been in charge
of the Scratch online community, infrastructure, and development team for
about 4 years I'll admit I got a little obsessed with the idea of staying
up. But my own reasoning for wanting a way to share the load has less to
do with power, and more with the human energy required to keep a local
server secure and up and running. I'm thinking of hosting my personal
website (currently here, but I'm planning a redesign:
[2]http://amosamos.net). It might go down for lack of power, and it might
go down for lack of proper configuration, updates, my router, my ISP -
there are plenty of potential failure points besides power. I think it
would be really cool if I could federate with a bunch of other folks with
some shared interests / needs / and values so that if my server went down,
my site would stay up for a while (a week or so?) while I sort out the
problem. It's not that I mind a day or two of downtime, but potentially it
could be weeks. I'd like to be able to be flakey, and to support others
when they are flakey for a while, and still mostly be up most of the time.
It's not just the weather that is unpredictable, it's also the server
admin and their time and circumstances.
Of course this leads to social challenges: For example, I won't agree to
cohosting content for a Nazi's website, or one that's disrespectful to
women. But I would welcome a conversation about general values and
guidelines with a group of people I was federating my solar powered
hosting with - say 2 to 10 or so. In many ways, I think the current
terrible state of FB and Twitter is because the people in charge pretended
that the technical challenges were the most important to spend time on
while trying to ignore the (now festering) social questions. Lets agree on
what is good and reasonable, and support one another.
RE: bittorrent, that's a nice idea too. I also thought about the DAT
protocol and it has a nice section on the considerations between:
[3]https://docs.datproject.org/docs/faq#how-is-dat-different-than-academic...
Where it points to the drawback of "BitTorrent is for sharing static
files, that is, files that do not change over time." for website
content.
Searching on this topic yesterday I found this thing called Planktos which
claims to work with plain existing (recent / updated) browsers to serve
static assets via torrenting. It appears as though they have a strategy
for cache invalidation.
[4]https://github.com/xuset/planktos#how-it-works
It appears to be using other viewers to serve the files though - not
sharing across multiple hosts? Or maybe you can setup seeds that way - I
dunno.
So, with DAT (or something similar), we would be downloading copies of
each others websites to our own computers and serving them locally. That
kind of makes sense to me as a nice approach.
Me too!
If I had to guess at the considerations ...
* Content is changing, so needs to handle syncing / updating
* Needs to be redundant if one server goes down ("offline first")
Above seem possible.
* Needs to be discovered without central authority (DNS)
I have no idea how this could work. I mean DNS has to be involved if you
are using a domain name, but what happens after DNS to route the request
to wherever it needs to go next? The only thing I can imagine is some kind
of load balancer. :/
Finally, I'm not sure if solving this well would kind of invalidate one of
the points of lowtechmagazine's solar server: To show that constant uptime
is not a necessity, and that if we change our standards a bit we might,
you know, be able to maintain a livable biosphere. ;) I agree with that,
but it seems like it should be possible to have cheap solar servers and
pretty decent uptime (and manage traffic spikes) too.
Thanks for the fun conversation! I'm interested in any further thoughts
you or others have.
Amos
* Should be performant for lower bandwidths
* ???
Then to map those considerations onto a protocol ...
Interested to hear further thoughts!
Luke
On 0, Amos Blanton <[5]amos.blanton(a)gmail.com> wrote:
> Greetings list -
> Inspired by the great low powered server described on the
lowtechmagazine
> website, I'm interested in setting up a home solar powered server
for my
> personal website. I set up a webserver on a raspberry pi and made
[1]an
> instructable about it long ago.
> While I appreciate the need to accept some downtime, I wonder if
folks on
> this list have thought about strategies for federating solar powered
> servers to share load? Up here in Denmark I have a great deal of
daylight
> at the moment - maybe 18 hours or so. If I could mirror other small
sites,
> and serve them when their hosts are low on batteries, I'd be happy
to do
> it. And I could use the same sort of help when winter comes.
> I wonder if anyone here has considered creating a solar-energy load
> balancing service. Members would get mirrorred in other member's
> locations, and report their remaining battery capacity / charging
status
> to the balancer. The load balancer could then route requests to
whoever
> has the most charge / active sunlight at the moment. Or perhaps
there is a
> strategy that would use something like the bittorrent protocol to
server
> websites?
> Interesting in any thoughts you have. And thanks for making and
sharing
> such excellent documentation!
> Amos
> --
> [2][6]http://amosamos.net
>
>References
>
> Visible links
> 1.
[7]https://www.instructables.com/id/Host-your-own-blog-from-a-25-Raspberry...
> 2. [8]http://amosamos.net/
>_______________________________________________
>HBSC mailing list -- [9]hbsc(a)we.lurk.org
>To unsubscribe send an email to [10]hbsc-leave(a)we.lurk.org
_______________________________________________
HBSC mailing list -- [11]hbsc(a)we.lurk.org
To unsubscribe send an email to [12]hbsc-leave(a)we.lurk.org
--
[13]http://amosamos.net
References
Visible links
1. mailto:lukewm@riseup.net
2. http://amosamos.net/
3.
https://docs.datproject.org/docs/faq#how-is-dat-different-than-academic-t...
4. https://github.com/xuset/planktos#how-it-works
5. mailto:amos.blanton@gmail.com
6. http://amosamos.net/
7. https://www.instructables.com/id/Host-your-own-blog-from-a-25-Raspberry-P...
8. http://amosamos.net/
9. mailto:hbsc@we.lurk.org
10. mailto:hbsc-leave@we.lurk.org
11. mailto:hbsc@we.lurk.org
12. mailto:hbsc-leave@we.lurk.org
13. http://amosamos.net/
_______________________________________________
HBSC mailing list -- hbsc(a)we.lurk.org
To unsubscribe send an email to hbsc-leave(a)we.lurk.org
606
days inactive
609
days old
4 comments
2 participants
participants (2)
-
Amos Blanton -
Luke Murphy