Solving the Historical State Problem in Matrix (gpn21)

This talk goes into depth on why historical state is such a thorn in our side and how we may be able to finally put it to rest with the work proposed in [Matrix Spec Change 3901](https://github.com/matrix-org/matrix-spec-proposals/blob/andybalaam/deleting-state/proposals/3901-deleting-state.md)! From the name of your [Matrix](https://matrix.org) room to what users are considered a part of it, the "state" of a room determines everything about it. It's a wonderfully decentralised, append-only management system - where any update is simply stacked on top of an old one. But what happens when you've updated it over and over on the course of months, or even years? You and your friends may start to notice some performance problems! How can the average Matrix user, with little knowledge of the underlying protocol, ever hope to diagnose, let alone fix this? This is a well-studied problem in Matrix, and often affects rooms with lots of member changes - such as those bridged to IRC. It can be a problem for those running their own homeservers, and can take a disproportionately large amount of CPU resources, something we should do our best to conserve in a federated network. This talk goes into depth on why historical state is such a thorn in our side and how we may be able to finally put it to rest with the work proposed in [Matrix Spec Change 3901](https://github.com/matrix-org/matrix-spec-proposals/blob/andybalaam/deleting-state/proposals/3901-deleting-state.md)! Slides: https://nc.amorgan.xyz/s/E6wd3Nz32zWmdNg about this event: https://cfp.gulas.ch/gpn21/talk/9Y3NFU/