Honestly Matrix E2EE and federation is a bit like cryptocurrency (without going into all its other social problems).
-
@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.
-
@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.
@developing_agent You'd just have to migrate the account to have non local scope (presumably set a scope/domain field). Whether this breaks past mentions depends on whether those are stored by name or by ID... (I hope id)
But the more interesting thing is designing a flow to "take over" a local account and migrate to remote identity without risk of ending up with two unmergeable accounts too easily...
As for multiple clients, an existing legacy client miiiight be able to keep its auth token and stay logged in but there are a lot of asterisks on that. And to log back in you'd need, at minimum, "app passwords" or something.
-
@developing_agent You'd just have to migrate the account to have non local scope (presumably set a scope/domain field). Whether this breaks past mentions depends on whether those are stored by name or by ID... (I hope id)
But the more interesting thing is designing a flow to "take over" a local account and migrate to remote identity without risk of ending up with two unmergeable accounts too easily...
As for multiple clients, an existing legacy client miiiight be able to keep its auth token and stay logged in but there are a lot of asterisks on that. And to log back in you'd need, at minimum, "app passwords" or something.
@lina You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.
-
@lina You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.
@lina Not sure what you mean by the "multiple clients" case.
-
@lina You mean having two accounts that mutually point to each other as "I log in other there"?
I think it might be an unlikely race condition if it requires manual conversion as exists in mastodon. But I think two problems could be solved at once with a cool-down between pushing the button and actually becoming a non-local account. If servers refuse to become that external authenticator during the cooldown that might fix it, and it ads a guard against hostile takeover.
@developing_agent Nono. What I mean is that if you have a local account, and then federated auth is implemented, any interaction from your home base account in its capacity, with a server you already have a local account in, would end up with a duplicate account situation that's hard to fix (one local, one remote), while what you want is to convert the existing local account to remote.
My gut feeling is the safest solution to this is email matching. If you're already requiring emails for account creation, then they can be used to check for a preexisting local account. You'd have to verify via email confirmation, but it would avoid the risk, and it can also be used for remote account recovery when you lose your home server. The flip side is it exposes your email to all servers, and in fact allows "does this email exist in this server" lookups by alll third parties (modulo rate limits etc), but I feel the advantages outweigh the disadvantages here (though you could still turn the feature off if you know/accept the risks, there's room for more paranoid opt in choices here).
There are subtle tunables here, e.g. you could do a bit of "proof of work" stuff for email lookups to avoid blatant spammer/scraper abuse.
-
@lina Not sure what you mean by the "multiple clients" case.
@developing_agent I mean having a (legacy) client logged in while an account is transitioned from local to remote.
-
@developing_agent I mean having a (legacy) client logged in while an account is transitioned from local to remote.
@lina tbh, I think that's a can of worms you don't want to open if you don't have to. It's already standard practice to log someone out everywhere when their password changes, and this is a much bigger change to their account that that. Maybe if there's a waiting period it only happens at the end of the cooldown when the result finally sticks.
-
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 think “porting the discord experience” is exactly the issue here. People have suggested matrix to me as an alternative multiple times. The issue is that I don’t think my “non technical” friends and community would enjoy it as much. It’s too complicated for them - and too different. I’m currently checking Stoat since it seems almost like a clone, I’m just a bit worried about how scalable it actually is.
