stoat.chat but with federated identity (login) and a multi-instance client (one client unifying data from multiple backends).
Just those two features. Add those two things and you get viable distributed Discord.
stoat.chat but with federated identity (login) and a multi-instance client (one client unifying data from multiple backends).
Just those two features. Add those two things and you get viable distributed Discord.
@lyokanthrope @lina ah i see, well that's good, it must be quite new
i was snooping and they already have "fluxer premium", i mean i know they don't have like a marketing dept. and are looking for a way to fund it, but the "premium" and "pro" thing and attaching some of the arbitrary limits that discord nitro had is a lil concerning. Ultimately though, I do think even if it has a Nitro-like issue, it'll still cook Discord as a solution if the dev follows through
@be_far Bluesky/Fedi is a completely different problem. These are public interaction platforms, that's how you end up with "good" federation but jank/discoverability issues (fedi) vs. "bad" federation but a better experience (bsky).
Discord doesn't have that problem. You simply don't need content federation at all. You just need to solve the "having to sign up in different servers" problem and identity federation solves that.
@lina I see. The one UX hole in this would be that to join your friend’s space that was created on another hosting, you have to sign in again. (The Gitlab problem.)
Unless you’re storing your token client side and the app handles all the authentications with additional data sources. But then how do your different clients know what spaces you’re in? There would need to be some state that is updated and passed back to the identity server.
@be_far @lina I assume it might be more like Matrix, where your "home" server is responsible for your identity *and* your configuration? (Or sort of like connecting to an IRC bouncer.)
At least that's my understanding of identity federation, i.e. many identity/account servers but you still live on a specific one – not necessarily "my identity is based on my id_ecdsa.key".
@be_far @grawity Yes, that's the idea. Your home server is your identity root and knows where you have logged in with that identity.
The home server could also proxy to other servers, coalesce notifications, cache, etc. This is not federation, it's just more like an IRC bouncer as you say. It would be driven by practical needs of mobile clients etc. But the remote servers are still the sole source of truth for their spaces, handle all space moderation, etc.
You'd still want some sort of recovery/backup/portability system so that if your home server goes away you can say "wait, I'm this identity" to servers you were in and recover. There's various ways this could work, for example simply using an email, or a backed up private key. But this (with the complexities it brings to UX) would be a special case. It should be *possible* to survive a home server failure and not lose all your remote accounts, but this mechanism shouldn't be what's needed for normal login.
@lina Not having to have a gazillion damn accounts would be the biggest free software social media step forward.
There are ways to do it. But I haven’t seen nearly as much will:(
@gabboman I don't think that's the right call. Content federation makes sense for stuff like Fedi where communications are public and it's supposed to be "one huge public space", but it doesn't make sense for something Discord-shaped where you have private "servers".
Content federation is really hard to get right without running into UX/performance/jank issues, and should not be used where not needed.
@gabboman Isn't that federated messaging? "polyproto is a federated identity and message exchange protocol".
Unless you only use it for identity I guess?