Post · bonfire.cafe

Post

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

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)

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 5 hours ago

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.)

Lycoris

@Lycoris@retro.pizza replied · 47 minutes ago

@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.

ShutterBugged

@developing_agent@mastodon.social replied · 3 hours ago

@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.

ShutterBugged

@developing_agent@mastodon.social replied · 2 hours ago

@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.

ShutterBugged

@developing_agent@mastodon.social replied · 2 hours ago

@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."

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 2 hours ago

@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 thing

Scoped 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.

ShutterBugged

@developing_agent@mastodon.social replied · 2 hours ago

@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."

~14 more replies (not shown)

ShutterBugged

@developing_agent@mastodon.social replied · 2 hours ago

@lina Asking forgiveness instead of permission, so to speak, and going ahead and building a client anyway.

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 2 hours ago

@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)

ShutterBugged

@developing_agent@mastodon.social replied · 2 hours ago

@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 part of the initial hack might be clientside, trying to handle other people who are also running multi-server clients. Thinking about that makes my head hurt.

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 2 hours ago

@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.

ShutterBugged

@developing_agent@mastodon.social replied · 1 hour ago

@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.

Pxl Phile

@ppxl@social.tchncs.de replied · 4 hours ago

@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

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 4 hours ago

@ppxl Oh yeah, Discord was never the right place for docs and things like that ^^;;

Tired Bunny :comf:

@tiredbun@akko.wtf replied · 5 hours ago

@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.

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 4 hours ago

@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.

Sophie

@sophie@chaos.social replied · 5 hours ago

@lina Quassel tried to fill that hole.

四

@yon@sakurajima.moe replied · 5 hours ago

@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 :)

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 5 hours ago

@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@sakurajima.moe replied · 5 hours ago

@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 :)

Plana

@Planatarium@mastodon.social replied · 5 hours ago

@lina that won't happen because discord probably won't allow that

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

@lina@vt.social replied · 5 hours ago

@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.

Plana

@Planatarium@mastodon.social replied · 5 hours ago

@lina fair enough

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.2-alpha.23 no JS en

Automatic federation enabled