Homebrewserver Club

> self-hosting an XMPP server isn't something you can just install and have it work

For basic needs ala IRC it should just work out of the box by defining a virtualhost. For respect of advanced features as defined in the XMPP Compliance Suites, it'll need a few more settings but there's good guides:

prosody: https://homebrewserver.club/configuring-a-modern-xmpp-server.html

ejabberd: https://www.process-one.net/blog/ejabberd-xmpp-server-useful-configuration-steps/

All in all it should take a novice (who has some experience of sysadmin, can deal with DNS records, firewall, etc) a few hours to setup to their taste... Or you could go with Snikket, a XMPP distribution, to have everything pre-configured in a docker container.

> XMPP clients on iOS were unusable

Sorry I don't know about iOS mostly because my acquaintances can't afford Apple devices and/or are not interested in a walled garden where a private company owns all your computations. Though i heard similar stories as yours, but there is progress with Siskin, with some development (eg. OMEMO groupchats) being funded by the Snikket project.

> notifications sometimes don't work

This may have to do with your OS settings. I don't know how iOS handles low power mode but i know for sure some Android distros restrict network queries (apart from the privileged, centralized push notifications service) and there's settings to uncheck for that.

> in a business situation

In a business situation you might find the resources…

Regarding image compression: https://homebrewserver.club/low-tech-website-howto.html#image-compression

The original is 160KB. When I save it in GIMP, the re-encoding (at 90% quality be default) brings me to a baseline value of 164KB. If I turn the quality down to 50%, it appears to be almost identical but is only 72KB, less than half the size. Turning it down further until I can only barely make out more detail than in the dithered image (for example, I can see that the operator on the bottom left is looking at something, whereas in the dithered image I originally thought her face was a headphone and she was facing away from the camera), and at 7% the limit is finally reached. At 6%, the quality is no longer better than the dithered image. So at 7%, what's the size? 20.9KB, much less than the dithered image that is claimed to be 36.5KB.

I'm not sure why I double checked, but I did. You know what? The dithered image is not 36.5KB as the article claims, but a 76KB PNG. Which is impressive because with PNG, I can't get it below 140KB in GIMP. JPG and GIF also can't reduce it beyond 76KB. Their PNG encoder is much better than GIMP's, but I don't know where the 36.5KB claim comes from. What I do know is that JPG can get it to 72KB with virtually no quality loss, or 21KB at a quality still slightly higher than the dithered version. All you have to do is change the quality setting, an option available in almost every editor (no fancy tools or skills needed).

Dithering seems to…

There's a more technical version of the original Low Tech article available[1]. I've been tracking this project for a while and found it really inspiring.

I've been starting to build my own systems based upon the Raspberry Pi 2/3 and the ODROID-C2, and currently use the ODROID as an ultra-low-power server. Most of my documentation and configuration so far has been in a private repo, but with this much interest I made it public[2] in hopes that others would be willing to issue PRs and work on it with me. If you're interested in this type of optimization definitely contact me, I'd love to work on this stuff more with environmentally-interested people.

[1] https://homebrewserver.club/low-tech-website-howto.html

[2] https://github.com/rarecoil/ecoserve

As they describe being open to ideas and feedback: maybe using static compression could help. The concept is to pre-compress files (have foo.html.gz available next to foo.html) so that the web server does not have to compress on-the-fly. nginx supports it[0] and gzip_static does not appear in their nginx config[1].

It might not make a difference if nginx has a in-RAM cache of the compressed files. Otherwise, it has the potential to be pretty significant assuming most requests are made using "Accept-Encoding: gzip" and assuming the web server does not prefer other compression algorithms (eg. Brotli).

[0]: https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html

[1]: https://homebrewserver.club/low-tech-website-howto.html#full-nginx-config

> Would love to be pointed to the best counterarguments, but again the focus on product was the interesting take for me.

I attempted to summarize the trade-offs in this post: https://snikket.org/blog/products-vs-protocols/

There are also a number of responses written by others, such as:

- An Objection to "The Ecosystem is Moving": https://gultsch.de/objection.html

- "Re. The Ecosystem is Moving": https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/

- "Have you considered the alternative?" https://homebrewserver.club/have-you-considered-the-alternative.html

> Can you run a Prosody server on a rasPI?

Easily.

> Do you need a static IP?

No, but you need access to a domain record to add the required entries for XMPP, and update them if your IP changes. One can do this for free (once you have a domain that points at their DNS records) with a provider like Digitalocean and their API to update the domains.

Set up guides: https://prosody.im/doc

Community to ask:
https://homebrewserver.club/