Hi. I’m kinda of a noob in the world of self-hosting and matrix, for that matter. But I was wondering how heavy is it to host a matrix server?

My understanding how matrix works is each participating server in the room stores the full history and then later some sort of merging happens or something like that.

How is that sustainable? Say in 5 years matrix becomes mainstream and 5 people join my server and each also join 3 different 10k+ people rooms with long histories. So now what I have to account for that or people have to be careful of joining larger rooms when they sign up in a smaller-ish server?

Or do I not understand how Matrix works? Thanks.

  • poVoq@slrpnk.net
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    2 hours ago

    This is a fundamental issue of the Matrix protocol, yes. For regular small scale use it doesn’t matter so much, and the state history gets reset every time you do a room upgrade, which is another annoying “feature” of Matrix, but it eases the fundamental problem a bit.

    But IMHO the Matrix protocol is a child of the Bitcoin hype era and is built on a similar data-structure that is inherently impossible to scale and the developers of Matrix should have realized that early on. Their bosses back then actually did, but they spun it off as a separate company and got some crypto-currency investments so the can was kicked down the road and here we are…

  • Kairos@lemmy.today
    link
    fedilink
    English
    arrow-up
    5
    ·
    3 hours ago

    It can baloon as it scales up. Matrix.org (homeserver) has had at least one DB corruption and that’s with their proprietary Rust bindings for Synapse. Small communities, especially ones that share rooms between them, should be fine on most systems. Make regular backups of the DB.

    • northernlights@lemmy.today
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      2 hours ago

      And, importantly, run the db on postgre, not sqlite, and implement the regular db maintenance steps explained in the wiki. I’ve been running mine like that in a small VM for about 6 months, i join large communities, run whatsapp, gmessages and discord bridges, and my DB is 400MB.

      Before when I was still testing and didn’t implement the regular db maintenance it balloned up to 10GB in 4 months.

      screenshot of cloudbeaver

      • drkt@scribe.disroot.org
        link
        fedilink
        English
        arrow-up
        3
        ·
        30 minutes ago

        It is my understanding that all of the ballooning DB is room states, something that you can’t really prune. What exactly are you pruning from the DB?

    • Kairos@lemmy.today
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 hours ago

      There’s also issues with the state disagreement / resolution algorithms across federation.

      Has this been solved? Maybe it’s also due to database corruption, where some state is forgotten across the federation, and thus the algorithm breaks down?