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.
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.
Epicyon now has the ability to post and receive git patches. If you make a commit to a git repository and then use the format-patch command and paste the result into a new post in Epicyon then you can send patches to other people over the fediverse. On the receiving side they will appear shown in a monospace font. This only works if you include the name of the project within the CW/subject line and on the receiving side the project name needs to be added within the profile settings (i.e. you need to opt in to receive patches for a project).
When a patch is received it will be put into a patches subdirectory within the users account directory. This can then be applied in the old-fashioned manner, or you could have a script do something with the incoming patches.
So this provides a non-centralized way of receiving git patches, other than via email. There is however a small problem. The character limit on most fediverse instances isn't big enough to be able to paste anything other than the most minimal patch. So that's a fundamental obstacle.
Why bother with the fediverse as a way of transferring patches? The traditional decentralized way of doing software collaboration, which is still used by the Linux kernel, is via mailing lists. But for that workflow to perform well you really need to be on top of your email client with your procmail rules tweaked to perfection. Not everyone is at this level of ubergeekdom. Also keeping spam out of mailing lists can become time consuming and demoralizing. By contrast leveraging the existing moderation and http signature features of the fediverse means that many of the problems with the traditional development model can be averted.
I've also been reading the ForgeFed specification. It doesn't look as if this has had much uptake, and reading through the various issues I can see that there have been years of argumentation with very little implementation. Crucial features such as pull requests appear to have been forgotten about entirely.
So I might divert some effort into making a git server which is genuinely decentralized but doesn't depend upon using mailing lists. I could use the existing ForgeFed framework and add in the parts of the spec that are missing. This would help with other projects, because it has to be admitted that my current collaboration workflow is less than ideal. People can make pull requests on GitLab mirrors, but then there isn't any straightforward way to get those upstream to my own server.