Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support selective JOIN/PART of channels without affecting Matrix-side channel membership #66

Open
ToxicFrog opened this issue Feb 12, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@ToxicFrog
Copy link
Contributor

The idea is simple: rather than force-joining you to all your Matrix channels, support LIST to list all of them and let the user opt-in from the IRC side using JOIN and PART, as normal. If we want to get fancy we can replay some backscroll on channel join. The existing behaviour of JOIN would need to be moved to another (non-standard) command.

This would help with the case where you have a bunch of Matrix channels that are only infrequently useful, or a bunch of automatically created ones (e.g. from a bridge like mautrix-discord) that you don't actually care about; it might also help with the "doesn't feel quite like a real IRC server" issue. At least, it does for me. :)

I have a working prototype here and have been using it for a few days successfully; that said, it's pretty messy, no unit tests, etc which is why this is a feature request and not a PR. I suspect a production-ready version will want significant design revisions (like, say, keeping all the state in the Matrix room_state rather than the "mirror state" setup evinced in that commit). Still, it might be useful for someone (perhaps even future me) as a starting point.

@progval
Copy link
Owner

progval commented Feb 12, 2024

The existing behaviour of JOIN would need to be moved to another (non-standard) command.

ircv3/ircv3-ideas#91

@progval progval added the enhancement New feature or request label Feb 12, 2024
@ToxicFrog
Copy link
Contributor Author

I think that this proposal, if implemented, would make support for something like JOINRESTORE unneeded. Sorry if I've missed your point, or if I'm not explaining myself clearly; I don't have the brain this month today.

But the idea is to decouple "M51's view of what channels your IRC client is in" from "the homeserver's view of what channels your Matrix account is in", with JOIN/PART affecting only the former. So it would look something like this:

  • when you first connect, M51 doesn't join you to any channels
  • /LIST shows you all the channels M51 knows about (i.e. all the ones your Matrix account has membership in)
  • You use /JOIN and /PART like any other IRC server to control which channels you're in; if you try to /JOIN a channel that you aren't already in matrix-side it 403s rather than trying to join it
  • Matrix-side channel membership is managed through /MJOIN and /MPART commands, which effectively add and remove channels from the /LIST output

That last is what I mean by "the existing behaviour of JOIN"; currently M51 assumes IRC-side membership in all channels it knows about, and JOIN is used to manage the matrix-side channel memberships. Decoupling them would require moving matrix-side channel management to other commands so that JOIN/PART would have their expected IRC-like behaviours.

And that means that if you end up a situation where (say) you join #foo and #bar from your IRC client, then disconnect from M51, then use a different Matrix client to leave #foo, then reconnect, your client will try to JOIN both and M51 will reject the attempt to join #foo with a 403, because the channel has vanished from its view of Matrix and you need an MJOIN to tell the homeserver to rejoin it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants