Meeting Attendees
Grégory Schiano (@gschiano), Aaron Rainbolt (@arraybolt3), Nils Büchner (@nbuechner), Michal Kohútek (@Tylnesh)
Meeting chair
Grégory Schiano (@gschiano)
Meeting Agenda
- Update on Ident server
- Discussion on homeserver implementations
- What is our policies with tangentially related rooms in the Ubuntu Communtiy space?
Update on Ident server
The way Ident works is by keeping a map of outgoing port and the user associated with it on the bridge side. Then the IRC server maintainer can query our Ident server using the port they see through the TCP connection to identify which user is being that connection in order to ban (instead of banning the whole IP that would ban the whole bridge).
Unfortunately Ident don’t work behind NAT since the source port are impacted by NAT, the current Synapse and IRC bridge deployment are in K8S that uses NAT for its network, it’s also likely that the outgoing connection are NATed on Canonical’s firewall.
Potential solution that still need to be discussed:
- Confirm outgoing NAT on Canonical firewall
- Eventually move the bridge directly to an openstack instance putting it outside K8S
- IPv6 might be also a solution by using a dedicated IPv6 address for every outgoing connection on the bridge
- Eventually hosting the bridge on cloud provider with a direct IPv4 address without NAT
Discussion on homeserver
Grégory re-explains the evaluation of other homeserver implementations purpose.
Synapse is probably the most feature complete in terms of Matrix protocol, but goal is to see what is proposed.
The Conduwuit maintainer contacted us on the public Ops channel, we will organize a call with him to discuss this project.
Discussion around HA and Synapse, which is very limited because Synapse wasn’t designed with HA in mind. The current approach is more an horizontal scaling solution.
On the other hand, Synapse doesn’t take much time to restart, but having an HA solution will increase availability. For example the downtimes faced today due to Canonical IS doing some openstack instance restarts would have less impact with an HA approach.
What are our policies with tangentially related rooms in the Ubuntu Communty space?
There are currently 5 rooms in our space that don’t adopt our CoC and didn’t invite our moderation bot.
What should be our policy and how to communicate with these rooms ?
- The CoC and the bot are a space thing, every room in the space should adopt these rules.
- Some of those rooms were added before we set the policies.
- Let’s open the discussion with room owners.
- The council works on a message that will be approved and then communicated.