I think in the fediverse such services are not designed for fully private mode. And to be honest I can’t even remember any other services. Maybe set up an instance of Mastodon and defederate it, plus add something like basic auth. But that’s not a ‘out of the box’ solution.
The first step is to understand what you want exactly. Microblogging like Twitter? A social network like Facebook? A video hosting like YouTube? This depends on a lot. Lemmy communities can’t be closed out of the box, but YouTube for example can be closed to registered users or with a private link.
Good. It seems I unconsciously used my own experience. In my country, even having users limit on a platform requires you to register with the state service.
In that case, it doesn’t matter much what you set up. If you just need a chat, Matrix is a good option. Or maybe Mattermost if you need a nice client. There are also several social network platforms in the Fediverse.
Well then, your choices are: 1. Buy a server under a false name 2. Never connect directly to the server or the host’s site. Use proxies for management (preferably proxies in another country). 3. Change keys more often. 4. Reinstall the system on a VPS so that the disk is fully encrypted in case the VPS is seized or management is intercepted. LUKS is the best choice. 5. Don’t keep any logs on the server.
Even with all this, your VPS provider can still reveal the addresses of everyone who connected to the instance, so the most challenging part from a user experience perspective is: none of your users should connect directly to the instance, only through proxies or VPNs on other nodes.
Honestly, it’s much easier to publish an instance on Tor or I2P networks. But in any case, even if the server is published on I2P, follow all the points from the first paragraph.
UPD: honestly, it’s better to put a i2p Floodfill router on a VPS to support the anonymous network within the country. And promote node hosting. This will give much more benefit. Publishing something inside an anonymous network is much less risky than on the internet, though caution must still be exercised.
My provider doesn’t provide IPv6, but I rented a server in a data center, bought a subnet, and tunneled it home via WireGuard. So the scheme is roughly: VPS (fd00:1::/64) <-> (fd00:1::/64) Home router (realv6/64) <-> Home network
Router configuration:
/etc/sysctl.d/10-ipv6-privacy.conf
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
/etc/radvd.conf
interface br0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 30;
AdvManagedFlag on; # M=1 → Address via DHCPv6
AdvOtherConfigFlag on; # O=1 → Additional options via DHCPv6
# SLAAC is still possible for Android
prefix realv6::/64 {
AdvOnLink on;
AdvAutonomous on; # Allow SLAAC
};
RDNSS realv6::1 {
AdvRDNSSLifetime 1800;
};
DNSSL home.lan {
AdvDNSSLLifetime 1800;
};
};
/etc/kea/kea-dhcp6.conf
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "br0" ]
},
"lease-database": {
"type": "memfile",
"persist": true,
"lfc-interval": 86400,
"name": "/var/lib/kea/dhcp6.leases"
},
"renew-timer": 21600,
"rebind-timer": 43200,
"preferred-lifetime": 43200,
"valid-lifetime": 86400,
"subnet6": [
{
"id": 1,
"subnet": "realv6::/64",
"interface": "br0",
"pools": [
{ "pool": "realv6::1000 - realv6::ffff" }
],
"option-data": [
{ "name": "dns-servers", "data": "realv6::1" },
{ "name": "domain-search", "data": "home.lan" }
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{ "output": "stdout" }
],
"severity": "WARN"
}
]
}
}
And of course, iptables is necessary. Something like: /etc/iptables/ip6tables.rules
# Generated by ip6tables-save v1.6.0 on Thu Sep 8 13:29:11 2016
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#BASE INPUT
-A INPUT -i eno1 -j DROP
-A OUTPUT -o eno1 -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eno1 -j DROP
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
COMMIT
Yes, it is. But I have llama-swap, openweb-ui. If you spend some time on the llama-swap configuration, then the you have a good chance to run the model on 2 cards is through llama.cpp. The winnings, however, will not be x2 of course and will fall non-linearly from the number of cards. And you need motherboard with good PCI-E lines (2 pci-e x16 or more). But it’s still cheaper than one large card. Example:
HIP_VISIBLE_DEVICES=0,1 \
/opt/llama.cpp/build/bin/llama-server \
--host 127.0.0.1 \
--port 8082 \
--model /storage/models/model.gguf \
--n-gpu-layers all \
--split-mode layer \
--tensor-split 1,1 \
--ctx-size 32768 \
--batch-size 512 \
--ubatch-size 512 \
--flash-attn on \
--parallel 1
There is a less stable but more productive one: --split-mode row
P.S. By the way, one RX9070XT on my instance translates posts and comments. You can test it if you want. =)
not a very popular opinion, but if you want an inexpensive, really inexpensive variant, take the AMD MX9070XT. AMD is not the most popular AI cards, but they are not bad with ROCm and for the price of 5090 you can put 5 cards (80 GB vram)
I think the problem has been slightly exaggerated. If you’re not hosting several dozen services, you can reduce your attack surface down to one Nginx server. For an even stricter setup, just enable mTLS.