End-of-summer TODO list

[gabrc52]

By FPOP:

• Try to reproduce end-to-end encryption flows to see if I can, well, reproduce the bugs
• Dormspam to get user feedback and more understanding of the messaging context before launching
• Must have: Tweak directory behavior (by overriding user directory endpoint) - this is synchronous I'm pretty sure
  • Prefer local accounts (strict - show them first)
  • However RIP... Element discards this ordering and sorts it again. Figure out a solution?
  • Prefer non ghosts (strict) (perhaps hide ghosts altogether)
  • Hide remote users who the user does not share a room with (no idea how to implement, there is the users_who_share_private_rooms table but uh it'd basically need rewriting the whole SQL query I think)
  • Compromise: for now, just exclude remote users from the search altogether
  • Element also shows client-side results, including ghosts which we excluded. For remote users, this ends up being helpful due to the compromise above, but for ghosts, we need to make them autorespond that they're ghosts as a result.
• Ideal: User directory with People API (User directory #53)
  • Diagnose why asynchronous endpoints are not working
  • Diagnose why duplicate headers are being sent
  • Override user directory endpoint
  • Override profile endpoint to not return 404 if the kerb does exist
  • Do so only for GET requests
  • Note however that this isn't used when creating a room and inviting people, because it is the homeserver that prefills the thing
  • Alternative: Configure Element to not give a warning (not necessarily a good idea because of mobile clients and other web clients)
  • Very important: Send emails to people who have not signed up but receive messages.
    • Create a Synapse module with a on_new_event callback
    • Handle DMs
    • Handle rooms
    • Handle spaces
• Update Element and Synapse
• Deploy changes to production
• Double-check that email notifications are only sent if you haven't logged in a while. Otherwise oops it might be too much spam.
• Check whether looking up profiles over federation is sensible (it appears to be enabled, do we want to disable it?)
• Dormspam so people can know matrix.mit.edu exists

Other misc (also by FPOP):

• Important: Explicitly set width for Element icon in welcome message (Yike giant Element icon #86)
• Make sure room creation defaults are sensible (Inconsistent room creation defaults #85)
• Element - nice to have - show spaces on the directory by default without having to click on a checkbox
• Fix double-click to change theme bug (even if it is fixed by changing the default theme to dark) ()
• Fix rename bug on the SIPB space
• Enable Maunium sticker picker for all users - https://github.com/mizhgun/synapse-stickerpicker plus retroactively
• Compress background image in both places (and just use one place)
• Change bug_report_endpoint_url to point to us (Collect bug reports #51)

Other misc (whenever possible):

• Add public free food room
• Debug why "showDisplaynameChanges": false is not being respected (sent an issue, it doesn't seem on my end)
• Add notification mechanism (doesn't support matrix, discord doesn't work, i refuse to use slack, and email fails with a certificate error) (Rageshake notifications #79)
• But make it point to Element devs too (Send bug reports to Element and not just us #80)

By registration:

• Update Element and Synapse
• Develop custom access control plug in (Develop custom access control plug in #104) - for now it should only work with custom state events, then we can document them and put them into our upcoming integration manager
• Good enough, however federated users can still join. Not sure how to do this over federation.
• Must have: class group chats (Class chats integration #42)
  • Choose a backend for the class list. Options: Subjects API or the Hydrant json file
  • Look at the Courses API to see if it is of any use (not atm)
  • Figure out a way to get the current term in a way that will scale through time - possibly latestTerm.json from Hydrant or the Terms API (Hydrant is better. I couldn't get Terms API to work, and we can trust Hydrant will keep being maintained, and it stores the upcoming term, which the Terms API doesn't; useful in transitional periods.)
  • Write backend with the following methods:
    • Get details about class by class name Probably unnecessary. Let's skip for now.
    • Get number of members in class group chat (0 if it doesn't exist)
    • Add kerb matrix user ID to class group chat (create if it it doesn't exist)
    • Add endpoint to query whether a matrix user ID in the class group chat
    • Make it authenticate with a shared secret
    • Stretch: search API with member count
  • Custom SvelteKit web app with minimal functionality but a class/group chat search
  • Figure out authentication mechanism for said app. Let's figure out minting an identity-only token and passing it to the server.
  • Hydrant: Add an advertisement/button - make it generate a clickable link button with the class list as a query string
  • Make sure you set the target to _blank for said button
  • Interstellar "Join group chat" or "Create group chat" button with a member count
  • Interstellar: warn anonymous users that they are joining a group chat where they can't be anonymous
  • Stretch: even adding a button in Element itself??
  • Judiciously use the Matrix directory itself (maybe make a space per term) (not willing to do right now, probably not a good idea yet?)

After the semester starts:

• Stop exposing the admin API
• Publicity: posters, lobby 10 tabling, possibly infinite display
• Being writing a new integration manager
• Develop the ability for everyone to create plumbed Messenger rooms in a user-friendly manner
• Second round of posters after this feature is added
• Documentation! We need our own docs on how to use Matrix, that are written with MIT's context in mind (for instance, instead of just saying "spaces exist" you can say "spaces exist which you can create for your club or organization and they are similar to Slack workspaces but with these differences")
• Element - show all spaces

Scalability:

• Set up workers (Set up workers #73). Put that RAM to use and anticipate a large wave of users.
• Tune postgres options for performance (Optimize postgres #43)
• Increase file handle limit
• note: see [meta] Improving Presence Performance matrix-org/synapse#9478

Once the stud reopens:

• Update Element and Synapse
• Possibly set up RAIDs for data redundancy
• Move the mxc:// data store to HDDs if SSD performance is not necessary, or move sufficiently old media
• Set up postgres backups, e.g. https://gist.github.com/tcpipuk/f68fb199ea8b1c1bdf48833fde86b418