User avatar
5225225 @5225225@furry.engineer
6mo
federated protocol musing(as someone who's not actually self-hosted anything): ease of self-hosting is related to how centralized your protocol is (and as such, if you're federated but it's a pain in the ass to actually practically self-host, it will end up being centralized (email, matrix to a lesser extent but still matrix)

but if you can spin up an instance on a shitbox VPS and point a domain name to it[optional] and you're Done, that is preferable

ig the takeaway is "if you want a less centralized ecosystem, writing guides and providing support to hosters and making the servers easier to use and work in more places will help achieve that"

(also easy migration tools. migration tools that just consist of "log in to each account on a single client, press a button, leave it for however long it takes" are also needed to counteract the effect of existing centralization)
3
2
5
0
User avatar
5225225 @5225225@furry.engineer
6mo
but also "ease of hosting" (low resources) and "ease of hosting" (it's more okay for it to fail) are in conflict :3

matrix does very complex shit in order to (try) to allow many distinct servers to cooperate to host a given room, so any individual failure doesn't break the room for anyone not on that server. (and i suspect the way matrix does it is just cursed to always have state resets and fuckery)

while xmpp just goes "a room is on a server. if that server is down, no one can access that room"

which one is better? idk.
(i think experimenting with "there is a linear timeline of messages, coordinated across N servers(chosen by the room, and can change at any time), N/2 of which can go down at any time gives you both some level of distributedness and also hugely simplifies the protocol)
1
0
1
0
User avatar
neocat_polyproto polyproto federation protocol @polyproto@amazonawaws.com
6mo
@5225225 An argument is perhaps to be made, that
- A service being down is something that users begrudgingly accept, but do not take massive issue with
- The much reduced complexity through "a room is on a server" making for less engineering challenges, which, in turn, may actually contribute to the real-world uptime being higher on these services, compared to ones using more complicated distribution logic
1
0
2
0
User avatar
5225225 @5225225@furry.engineer
6mo
@polyproto also : you can move "chat in this room" from 2 SPOFs (your server, their server) to 1 SPOF (their server) by just talking directly to their server from your client, akin to how IRC works without a bouncer

(a proxy server / tor / i2p / whatever would probably be smart there to avoid IP leaks, but that's just smart anyways)

and with encrypted rooms, the server can't correlate your IP and your name anyways unless you talk in a room the server can see, even if you do connect directly.
0
0
1
0