Honestly Matrix E2EE and federation is a bit like cryptocurrency (without going into all its other social problems).
-
Honestly Matrix E2EE and federation is a bit like cryptocurrency (without going into all its other social problems).
It's clever, it's an impressive technical achievement that it works at all... and it completely ignores all the practical reasons why server-centric systems exist.
You don't solve Visa and Mastercard censorship with crypto, you solve it with payment platform diversity. And you don't solve Discord with Matrix, you solve it with something with a design closer to IRC or XMPP.
(Reposted & lightly edited from a DM reply I wrote)
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
-
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina that won't happen because discord probably won't allow that
-
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina I agree with you in spirit, but I don’t think I could ever use IRC again with all its janky weirdness (I mean, usernames!).
But a spiritual successor to IRC would make sense.
Just my two random small coins
-
@lina that won't happen because discord probably won't allow that
@Planatarium Look, I know "billionaires run the world from a shadow cabal" is a popular thought these days and it's not *wrong*, but I don't think we're quite at the "disappearing people because they dare design a chat network" point yet.
-
@Planatarium Look, I know "billionaires run the world from a shadow cabal" is a popular thought these days and it's not *wrong*, but I don't think we're quite at the "disappearing people because they dare design a chat network" point yet.
@lina fair enough
-
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina Quassel tried to fill that hole.
-
@lina I agree with you in spirit, but I don’t think I could ever use IRC again with all its janky weirdness (I mean, usernames!).
But a spiritual successor to IRC would make sense.
Just my two random small coins
@yon I'm talking in spirit, not literally IRC, of course. Just the idea that IRC clients kind of pioneered the "one chat client many visually unified networks" thing (and many Jabber clients copied it).
And an "IRC bouncer" type component is a necessity for good mobile UX (and it can double as a web interface).
-
@yon I'm talking in spirit, not literally IRC, of course. Just the idea that IRC clients kind of pioneered the "one chat client many visually unified networks" thing (and many Jabber clients copied it).
And an "IRC bouncer" type component is a necessity for good mobile UX (and it can double as a web interface).
@lina I like the idea of separating things and making them composable. Authentication isn’t part of the app, the UI isn’t part of the app, and apps and UI can integrate so you can have a wider set of working together services that can be swapped out.
Also there are a good number of people suggesting a literal move to IRC. So, yikes there.
Those were the days, email, IRC, and Usenet. But I don’t want to go back
-
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina
I'd add integrated Jitsi Meet (or VoIP software on par with it and Discord, with screenshare, video, etc.) to that idea.
Not everyone needs it, of course, so it may be optional, but in my expirience it's the hardest to replace part of Discord. -
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina sounds nice. I would be happier if devs would avoid closed/unsearchable discord servers for issue tracking, FAQ, and documentation discovery.
But an open platform for text/voice chat with same features would be nice
-
@lina
I'd add integrated Jitsi Meet (or VoIP software on par with it and Discord, with screenshare, video, etc.) to that idea.
Not everyone needs it, of course, so it may be optional, but in my expirience it's the hardest to replace part of Discord.@tiredbun The good news is that part is relatively easy to bolt on after the fact, so it doesn't affect the core design (much). But yes, it's a necessary component.
-
@lina sounds nice. I would be happier if devs would avoid closed/unsearchable discord servers for issue tracking, FAQ, and documentation discovery.
But an open platform for text/voice chat with same features would be nice
@ppxl Oh yeah, Discord was never the right place for docs and things like that ^^;;
-
What I want is a Discord UI/UX running on top of an IRC bouncer+OAuth provider gateway that connects to a diverse universe of IRC networks (but with all the stored state Discord has).
(And yes, the average instance would co-locate the bouncer/gateway instance and the underlying chat network and the average user would just sign up there and wouldn't even know the difference, they wouldn't be running their own bouncer. But people like me would.)
@lina I've asked myself for years if revolt (now stoat) could be molded into something like that. People have been pushing them for *ages* to "add federation" but the limiting factor has always been that the team is a tiny group of volunteers.
-
@lina I've asked myself for years if revolt (now stoat) could be molded into something like that. People have been pushing them for *ages* to "add federation" but the limiting factor has always been that the team is a tiny group of volunteers.
@lina I think someone could even push in this direction this today, without *any* work on their side. They allow 3rd party clients, explicitly. Building one which could remember the credentials for and connect to multiple servers (computers) and display all the servers (chatrooms) and DMs on those (computers) in one UI would be a big step.
Invite links to join other servers (on other servers) could probably be handled client-side too, though handling DMs might be a little hairy.
-
@lina I think someone could even push in this direction this today, without *any* work on their side. They allow 3rd party clients, explicitly. Building one which could remember the credentials for and connect to multiple servers (computers) and display all the servers (chatrooms) and DMs on those (computers) in one UI would be a big step.
Invite links to join other servers (on other servers) could probably be handled client-side too, though handling DMs might be a little hairy.
@lina And of course this would become way simpler with support for portable identity, even something simple like the openID connect we had in 2005-7. That way you wouldn't need to create an account on each new server, you could just tell it "I log in over here."
-
@lina And of course this would become way simpler with support for portable identity, even something simple like the openID connect we had in 2005-7. That way you wouldn't need to create an account on each new server, you could just tell it "I log in over here."
@developing_agent Yup, it could be built on Revolt/Stoat. You need three things though:
- Scoped users (user@domain or whatever format), this does require core changes (more or less depending on how well factored it is)
- Authentication federation (only)
- The multi-server client thingScoped users are important because you don't literally want to register "local" accounts on every server, that's a namespacing problem (you need the accounts but you can't have local *usernames* is the issue). There have to be scopes, there's no way around that for distributed auth (how much or how little you expose them in the UI can vary, but they have to be there)
It's not a massive project but it does need buy-in/coordination with the core team.
-
@developing_agent Yup, it could be built on Revolt/Stoat. You need three things though:
- Scoped users (user@domain or whatever format), this does require core changes (more or less depending on how well factored it is)
- Authentication federation (only)
- The multi-server client thingScoped users are important because you don't literally want to register "local" accounts on every server, that's a namespacing problem (you need the accounts but you can't have local *usernames* is the issue). There have to be scopes, there's no way around that for distributed auth (how much or how little you expose them in the UI can vary, but they have to be there)
It's not a massive project but it does need buy-in/coordination with the core team.
@lina I was actually _literally_ suggesting registering "local" accounts on every server and letting the client manage the credentials. Yes, this is incredibly, incredibly dumb.
100% agree that it would be better to get scoped users and federated authentication going as official parts of the protocol. This was just a thought experiment in "what could we do if we had to go it alone and were willing to break the rules a bit."
-
@lina I was actually _literally_ suggesting registering "local" accounts on every server and letting the client manage the credentials. Yes, this is incredibly, incredibly dumb.
100% agree that it would be better to get scoped users and federated authentication going as official parts of the protocol. This was just a thought experiment in "what could we do if we had to go it alone and were willing to break the rules a bit."
@lina Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.
-
@lina Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.
@developing_agent Oh yeah I mean, you could totally start with that to build out the client side of the UX. It's just only half the intended puzzle ^^ (and then you'd have to build a migration path towards unified accounts, but I guess you'd kinda need that anyway)
-
@developing_agent Oh yeah I mean, you could totally start with that to build out the client side of the UX. It's just only half the intended puzzle ^^ (and then you'd have to build a migration path towards unified accounts, but I guess you'd kinda need that anyway)
@lina I think it could be done without rethreading history, just changing the user account type so that the server knows to go elsewhere for auth. Then sending new information to the client whenever you're talking about a truly non-local account....
...actually, the hardest might be trying to handle other people who are also running multi-server clients, clientside in the initial bodge-client. Thinking about that makes my head hurt.
