Closed ahs3 closed 2 years ago
@ahs3 There is a larger problem that Matrix doesn't really have a way to query for dead homeservers (obviously, dead homeservers don't talk). It's also hard for us to tell what's a intermittent outage, and what's continuous.
That said, if your user doesn't interact with the bridge for 30 days it should be kicked out of rooms and disconnected anyway (though your settings will still linger). I suppose we don't do this for OFTC / the other bridges yet because we don't have such strict rules over ilines, but we probably should enable a cleanup script anyway.
I'd suggest anyone who is suffering from this contacts support@matrix.org who can deactivate your account on the bridge. Please state your request and your Matrix ID.
I don't think we have a way to fix this. I'm going to close for the moment. The advice above still rings true.
Describe the bug I experimented with running a synapse home server and created @ahs3:matrix.ahs3.net. I used OFTC via bridging for a bit. Unfortunately, that server "crashed and burned" and will not be replaced. However, OFTC still shows the matrix user 'ahs3[m]' as a nick associated with the crashed server. Now when I try to use the matrix.org bridge to OFTC, I end up with the nick 'ahs3[m]1' which is usable, but since the original server crashed, there is no way for me to log in and deactivate the account using 'ahs3[m]'.
To Reproduce Steps to reproduce the behavior:
Expected behavior I suppose the bridge should check in with the server once in a while and verify that the user -- and the server -- are still present. If for some reason they are not, disconnect the nick and !quit the channel. I happened to see this behavior on OFTC, but I doubt it is exclusive to them.
Desktop:
Additional context I cannot tell if this is an issue with the IRC bridge or with Matrix. I have not found any workaround though I am still experimenting with NickServ commands. Granted, it's mostly annoying, but it does put a small load on clients and servers to manage the nick and username. I did review a dozen or so issues already reported here and this seemed different but I have not read enough of the bridging code to know for sure.