31 May 2021 |
sunweaver | ah, alright. | 07:44:31 |
sunweaver | Thanks! | 07:44:32 |
sunweaver | Cool. | 07:44:35 |
andrewsh | to prevent joinflood | 07:44:39 |
sunweaver | I love this! Really really cool! | 07:45:27 |
andrewsh | 😀 | 07:45:37 |
sunweaver | @andrewsh: and ow did you do the bridging now? | 07:45:59 |
andrewsh | "Add widgets, bridges & bots" → IRC | 07:46:26 |
sunweaver | Nice! | 07:47:02 |
andrewsh | it only works for networks supported by the matrix.org bridge — otherwise I’d need to set it up manually | 07:47:35 |
sunweaver | Yeah, I supposed so. | 07:58:17 |
sunweaver | Just created an #x2go room on matrix.org and bridged it to #x2go on libera.chat. | 07:58:34 |
sunweaver | very cool | 07:58:38 |
Jörg Sommer | In reply to @andrewsh:matrix.org what I don’t like about newer "room versions" is that you cannot un-admin someone Is it possible to add the bot with level 99 or something lower than admin? | 08:56:48 |
davo | In reply to @andrewsh:matrix.org what I don’t like about newer "room versions" is that you cannot un-admin someone Hasn't that always been a thing, except for bugs? | 10:09:48 |
andrewsh | I think room v1 allowed admin status to be taken away by other admins | 10:12:07 |
davo | In reply to @joerg:alea.gnuu.de Is it possible to add the bot with level 99 or something lower than admin? Adding the bridge via the Element integration manager automatically gives the bot PL 100. If you heavily modified your client you could get around that, but it's probably easier to "just" give yourself a higher PL when creating the room. | 10:12:50 |
emorrp1 | In reply to @andrewsh:matrix.org there’s supposedly a debian.social bridge too but I’m not sure it’s a great idea to have for multiple bridges to the same network yeah, there's a minor benefit for all matrix users to be on the same bridge, so they can see full matrix features to each other.
I'm hoping that the libera.chat homeserver implementation becomes the new standard for cooperative IRC networks. I.e. oftc.net could delegate via DNS to Element hosting | 13:06:53 |
sunweaver | Hi all! I have just tested matrix-synapse with matrix-synapse-ldap3 against a slapd database I already have in my company. | 13:14:00 |
sunweaver | When I try to login to an already existing account, I get long delay during login (via element) and nothing happens. | 13:14:45 |
sunweaver | I then at some point have to kill -9 the matrix-synapse PID... | 13:15:10 |
sunweaver | I haven't tried logging into a new account, yet. | 13:15:26 |
sunweaver | Has anyone encountered this? Has anyone tested the LDAP auth? | 13:15:43 |
emorrp1 | sunweaver: freedombox uses the LDAP auth without issue https://salsa.debian.org/freedombox-team/freedombox/-/blob/master/actions/matrixsynapse#L26 | 13:24:45 |
sunweaver | emorrp1: thanks for the info. Might there be a problem, when I use an account that got created via register_new_matrix_user and has its own password in the PgSQL DB and then I impose an LDAP user on this DB user? | 13:27:30 |
emorrp1 | don't know, sorry | 13:28:05 |
sunweaver | I think, I will set up another server for a customer and check LDAP auth provisioning there from day 1. | 13:29:37 |
emorrp1 | I would have assumed that the LDAP config would override the postgres default, but note the password_providers.config.attributes.mail: '' may be relevant for the mapping too | 13:30:00 |
sunweaver | so, you are saying I should set an email address to the same address as found in LDAP? | 13:31:18 |
emorrp1 | not sure again, but I think that config line is saying don't check LDAP for email addresses, you can enable debugging https://github.com/matrix-org/matrix-synapse-ldap3/#troubleshooting-and-debugging | 13:53:43 |