Recently I added deployment scripts to Epicyon for hosting on onion or i2p domains. These methods may provide greater independence, since you could easily self-host your own social media presence from your laptop and without a server, but using the long random domain names is very cumbersome. Is there a way to square the triangle of Zooko? It turns out that there is, using something called "petnames".
In Epicyon now if you select the avatar image of a person then you can optionally assign a petname for them. If you subsequently want to send a direct message to them then within the send to field you can just enter @petname. With something like an i2p address this massively simplifies the problem of specifying the intended recipient and keeps the amount of typing or copy-pasting to a minimum. When the post is sent the petname is then looked up and the full ActivityPub handle is substituted. Each account can have its own preferred petnames.
So this should make p2p ActivityPub more of a practical proposition rather than just a proof of concept.
The Epicyon ActivityPub server is now able to be installed on i2p addresses (aka eepsites). This means that it's now possible to run fediverse instances in a purely end-to-end encrypted peer-to-peer mode.
i2p is a bit slower than using a Tor browser, so don't expect rapid page load times. Be prepared for a leisurely pace of events. Get ready to drink coffee and stare out of the window, similar to dialup internet in the 1990s for any older hackers who still remember that. As a practical example, the inbox timeline which takes a couple of seconds to refresh on the clearnet in Firefox might take 10 seconds for an onion instance in a Tor browser or 15-20 seconds or longer on an i2p instance.
Within the deploy directory there is a script called i2p which can be used to install an i2p instance on Debian or Arch/Parabola. With some modifications to package names it could be adapted for other distros.
To access i2p sites use an ordinary browser, like Firefox, and within preferences/network select manual proxy and set http to 127.0.0.1 port 4444 and socks5 to 127.0.0.1 port 4447. Also turn off DNS via HTTPS if that is enabled. Then your i2p domain name should resolve. Unlike in a Tor browser, when in this proxied mode you won't be able to access clearnet sites, only i2p ones.
When not running on an ordinary domain name there are also limits to federation. Instances on i2p domains will typically only federate with other i2p instances. Familiar instances are typically not set up to use i2p and so won't federate. So on an i2p instance don't expect to be able to federate with mastodon.social.
It really depends on your situation. The obvious advantage is that servers aren't needed and you get end-to-end security without any additional coding effort and without needing to rely upon dodgy certificate authorities or DNS/ICANN. The client/server model does have some advantages though, since the server and its admin provide a rallying point around which to build a community with common interests and shared moderation. This could still happen in the peer-to-peer model though, because there's nothing to stop each peer having more than a single user account. So interesting semi-server hybrid architectures are possible.
The point at which distributing Freedombone images from my own server started to become infeasible was probably reached some time ago. A couple of years ago I also tried using dat as a distribution method, because it's designed for large data sets. But my adoption of dat was premature, and it really wasn't up to the task - typically failing at NAT traversal. So now I've gone back to the older 2000s-era tech of bittorrent, and there are some magnet links via which disk images can be downloaded.
p2p distribution obviously is the way to go with this. It makes it relatively easy for others to re-seed the files and keep them available even if my server isn't. Some people have remarked that I should get a better server, but even if that was economically possible I don't think I'd want to go down that route. I'd much rather keep my own hardware minimal and cheap to run - possibly with low enough energy consumption that it could go solar at some point. I also as far as possible want to avoid utilizing "the cloud", aka corporate data centers. Running your autonomous systems from a centralized data center owned by the world's richest oligarch is not really consistent with a decentralization project.
A comical thought occurs that maybe for distributing large images snail mail might once again become viable. In the olden times people would ship GNU/Linux CDs in the mail. USB sticks are quite cheap and posting them might not be very expensive. But waiting a couple of days for bittorrent to sync is probably faster.
With the new Epicyon fonts capability a few new themes have been created.
The Blue theme has a large handwriting font, and is very blue.
The LCD theme somewhat resembles an LCD screen, with a font reminiscent of that of the Sinclair Spectrum from the 1980s.
The Zen theme is designed to reduce stress, with its simple earthy colors and modest font keeping you grounded and serene as the flamewars pass by.
One advantage of self-hosting is that you have the opportunity to really customize the internet systems that you're running to reflect your own personal style. This is something which you'll never get from commercial silo systems, who always impose a boring user interface consistency.
Epicyon now has better support for fonts. Within theme.py a particular font can be defined as part of a theme, and the font file should exist within the fonts directory.
If you want to use a particular font with your instance then you can add it to the fonts directory, rename it as custom.ttf/woff/woff2/otf and then restart the daemon. Many fonts are under the Open Font License and so could be used freely.