Standard Change: Connect ProgCode Channels to Element

[jpb5013]

Required Information

Description

Connect standard ProgCode Slack channels managed by ProgCode to the ProgCode Element instance.

Problem

Slack is limited to a 10,000 message history and 10 integrations. It is also closed source, so limited ability to make customizations.

Benefit

Will enable improve collaboration and increased productivity.

Plan

• [ ] Schedule Element/Matrix/Networked.Community Overview/Q&A session
• [ ] Based on Overview/Q&A session, update to consent to implement to connect the following channels to +progcode:networked.community in Element: Introduction, Operations, Team Announcement, Pitch-Zone, General Chit Chat, Dumpster Fire, Ask The Team, The Newsroom, Jobs and Vols
• [ ] Add additional members to Element in Networked Community overall and ProgCode Community
• [ ] Begin building plan for additional bot integrations (specifically, message archive)
• [ ] As individual project leaders/channel owners wish to create a bridge to ProgCode Element, we can use this change to continue updating

Decision Making

Consent to proceed

Optional Information

Reference link(s)

...

[joemcl]

So is this the start of a transition from Slack over to Element? I've never used Element, can someone post a side by side comparison? Is Progcode self hosting? Thanks!

[joemcl]

Found a side by side here - https://sourceforge.net/software/compare/Element-Messenger-vs-Slack/

[noahsbwilliams]

@joemcl from what I gathered last night, there seem to be two different visions.

One is more "replacement" & the other is more "value add/augmentation".

Personally, I think the latter is more appropriate for ProgCode. Trying to rip everyone out of Slack could cause a fracture in the community with lots of confusion, which we don't want.

[noahsbwilliams]

Technical outline (what binaries run where):

Matrix server

Image: matrixdotorg/synapse

• Provides a Matrix API backend
• Dependencies:
  • Postgres (hard)
  • TURN (soft)

Postgres database

Image: postgres

• Primary datastore for Matrix backend)

TURN server

Image: coturn/coturn

• Allows people to actually communicate with each other through the Matrix instance

Element Web

Image: vectorim/element-web

• Appears to be a simple, "dumb" web frontend for the Matrix synapse backend
  • Only persistent data is a config.json
  • Hosting our own is important since doing otherwise can easily leak our users' metadata

[noahsbwilliams]

Production Considerations

Should we decide to stand this up in production, we'll have to consider...

Moderation

• [ ] We must provide a user-friendly means of moderating the community no more complicated than that of Slack
• [ ] External users must not be permitted to read or write any data to/from the ProgCode community without passing the official ProgCode vetting process.
  • Federation with other Matrix servers must be disabled.

Security & Privacy

• [ ] Transparency re: Encryption
  • Any sort of Element bridge to slack will negate the End-To-End encryption benefits of its' respective bridged channel.
  • This must be clearly explained to users.
• [ ] Where we want the data to live
  • Hosting these services outside the US means better privacy laws against subpoenas, but at the cost of fully legalizing packetsniffing for 100% of comms.
  • If we we intend to do this, we should consider proxying user traffic through a US-based server and encrypt requests between the proxy and the backend with mutual TLS. This can alleviate some metadata slurping.
• [ ] Limit Element Bridge's privilege scope explicitly to authorized Slack channels
  • We do not want to install backdoors in any portion of the ProgCode slack without the knowledge and express consent of our members.
• [ ] Host the Matrix & Element instances on our own domain.
  • The ongoing security implications of having this live on the networked.community domain are "unknown unknowns" which are difficult to fully enumerate.
• [ ] User authentication
  • The Element Bridge bot can (apparently) display whatever personality it likes (Name, Profile Pic, etc)
  • If someone hacks the bridge they can impersonate anyone.

Availability

Any crucial component of ProgCode comms infrastructure must be highly available.

• [ ] Service must be highly-available and elastic.
  • This essentially means either using a managed app service (Heroku, DO app platform, etc) or Kubernetes.
• [ ] Dedicated staff must be available for routine and emergency maintenance, including but not limited to:
  • Routine upgrades
  • Security patches

Proximate services & external dependencies

Anything that will have a privacy policy we have to read

• [ ] SMTP (user signup, password resets, etc)
• [ ] VPS hosting

Costs

• [ ] Costs must be calculated in accordance with the demands of real-world use.

[beriniwlew]

@noahsbwilliams, keep in mind that we are thinking about puttting networked.community under the ProgCode umbrella. That's something we'll have to discuss in the next meetings.