[HN Gopher] This Year in Matrix
___________________________________________________________________
This Year in Matrix
Author : Arathorn
Score : 160 points
Date : 2021-12-22 17:12 UTC (5 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| onefootincode wrote:
| This was truly a great year for matrix. Thanks to the whole team
| for making a dream about decentralized www come true!
|
| But I have a great pain with that bug: https://github.com/vector-
| im/element-web/issues/469
|
| Everytime I'm fighting with myself to not be sarcastic when
| speaking about this issue, but I want to say I have hard time
| believing that Element could we a main communication platform for
| anyone without this being fixed. It drives me mad, and I have
| just two people to communicate with!
| Arathorn wrote:
| Weird; the reason we haven't prioritised it is in that in
| practice it doesn't seem to be a big problem? You don't get
| push notifs while you're active in the app itself, and the fact
| that i get push on my phone while also reading on desktop
| almost feels like a feature (I often read the msg first via
| push on phone before then going and hunting on it desktop,
| especially as Element Web's notification panel needs love).
| beepbooptheory wrote:
| Really get good vibes from the company, can't quite put my finger
| on it... Never hearing back from them about a job was a bigger
| disappointment than usual.
|
| Problems with synapse are true, but it was a good compromise to
| push out an early implementation so things could get rolling
| quicker with getting people to actually use the clients.
|
| Just when I get used to some issue/missing feature in the
| clients, they seem to fix it.
|
| And in general I trust and know that decisions with the spec are
| being made carefully.
|
| I use it for an intimate chat server with never more than 8
| users, so I can't speak to some of the problems. I can just say
| the trajectory itself for Matrix is strong. A good effort to
| fight slack and discord. Wish all the discord servers people use
| were matrix instead.
| kevincox wrote:
| > And in general I trust and know that decisions with the spec
| are being made carefully.
|
| This is one place where I strongly disagree.
|
| Almost all features have "We will add encryption later" which
| is _not_ a way to build a secure messenger. Stickers, polls,
| profiles, spaces, relations, reactions... they all start with
| and unencrypted version with the promise that "encryption will
| come in a later MSC". They should really take "secure" out of
| the tagline until they actually add E2EE for all of these
| features. Basically all clients allow users to use these
| insecure features in encrypted rooms with no warning at all.
|
| And I constantly see hacky quick fixes get accepted because "we
| need to do something", "no clear use case for $X" (even when
| there is) and "N other MSCs depend on this so we'll merge it in
| and deal with a proper solution later". For example the
| relations MSC just got merged with support for only 1 relation
| per message even though it is clear that editing replies would
| be a problem with this system.
|
| I love Matrix and hope it does in fact unify messaging but I
| think "carefully" is not the way to describe how the spec is
| progressing. More like "shoved in whatever direction is needed
| to implement the newest Element feature". Maybe that is for the
| better, we do need a featureful protocol to get users after
| all, but personally it irks me the wrong way. Especially when
| security and privacy are ignored "for later".
| Arathorn wrote:
| This is a really interesting point. We deliberately built
| Element to help prove the spec and define its direction
| (including ensuring it has decent privacy properties), to
| avoid all the failure modes where folks build a protocol
| without a real app or product in mind and end up with
| something which tried to be all things to all people and
| useful to none.
|
| While I'd have loved us to have infite manpower getting all
| the security features in from day 1, we had to bootstrap and
| we prioritised usable apps over optimising for a perfect
| spec. And judging by some of the rest of the thread, we
| didn't so well even then; it would have been even worse
| otherwise.
| kevincox wrote:
| I think it is helpful to have Element to test out the spec.
| I think the problem is that the "bar" for accepting
| features is too low for my taste.
|
| > While I'd have loved us to have infite manpower getting
| all the security features in from day 1, we had to
| bootstrap and we prioritised usable apps over optimising
| for a perfect spec.
|
| I get the decision. But it leaves a sour taste in my mouth
| that Matrix advertises itself as "secure" but almost any
| user is leaking sensitive information without knowing. I
| suspect that 95% of users would be surprised if you told
| them about the number of things that leak in E2EE rooms.
| Probably the better approach would have been to skip
| pushing E2EE as the default, and disable all insecure
| features in Element for E2EE rooms (or have an explicit
| opt-in). The marketing team would hate this approach but it
| least it is honest and safe.
| Arathorn wrote:
| There isn't a marketing team for Matrix, unless you count
| me & the dev advocacy team. I actually have another (big)
| blog post called Metadata And Matrix which attempts to
| enumerate the privacy properties we have today to try to
| educate everyone, and how we're improving it in future -
| will post it shortly. Agreed it could be better, but if
| you're on your own server you are in a pretty good place.
| twicetwice wrote:
| I want to voice strong agreement with kevincox. I use an
| encrypted Matrix room daily and had no idea that
| reactions, relations (does that mean that edits are in
| cleartext??), etc are completely unencrypted. I've read a
| little bit of the spec (though clearly not very much),
| I've written a bot, I've patched the Element desktop
| client, I've even been working with a JSON export of my
| message history and didn't notice--perhaps I should have,
| but my point is that it's not obvious at all, and users
| SHOULD be proactively made aware of what's encrypted and
| what's not.
|
| Sending things unencrypted that users have every reason
| to think are encrypted is extremely irresponsible. And I
| assumed, as I think is perfectly reasonable, that
| everything in an E2EE room is in fact end-to-end
| encrypted. I'm very disappointed to find out this way
| that it's not (and won't be for the foreseeable future),
| and I don't see any justification for failing to making
| users aware of that.
|
| All that said, I love Matrix, will continue to use it
| every day, and am hugely rooting for the success of the
| project. Thanks for all your hard work on it!
| Arathorn wrote:
| Is it really that surprising that the act of reacting to
| a message with an emoji isn't E2EE, given the server
| needs to count the number of reactions? One could encrypt
| the emoji itself, but it doesn't seem like a massively
| sensitive datapoint in its own right. (That said, we will
| encrypt them eventually, but it's just not very high
| priority given the fact it doesn't practically feel very
| high impact, relative to all the other things we could be
| doing to improve Matrix).
| kitkat_new wrote:
| > relations (does that mean that edits are in
| cleartext??), etc are completely unencrypted.
|
| The text/content of the edit itself is actually
| encrypted, you can check in Element by viewing the event
| in de/encrypted form
| kuon wrote:
| I tried to adopt matrix for our small business and here is
| summary of my experience.
|
| - Synapse is very resource hungry even for a small server
|
| - Synapse creates a gazillion of TCP connection and keep them
| open, it was a real problem for my ISP router (SOHO router for
| 1gbit/s) and it took a very long time to debug, be sure to limit
| the number of TCP connection on the server
|
| - Synapse is hard to get a good idea of the health of the server,
| the federation can break without warning
|
| - If the federation broke for some reason, when submitting
| messages, they will show as delivered, this was one of the major
| problem for us
|
| - Encryption is very cumbersome to get right for non technical
| users, there should be a server wide option to make it "easier
| but less secure". Even for me, it was hard to get rid of a
| warning popup about some device error.
|
| - Group VOIP is hard to setup, it should be as easy as discord to
| be viable.
|
| - Webhook is really hard to setup too, I want to be able to right
| click a channel and "copy webhook URL" to be able to post to it
| with CURL (discord has that)
|
| - Globally it is very slow when joining federated rooms, it can
| take days to sync 500+ people room
|
| In the end we just use discord, it's free and do the job. Of
| course they can read our messages and this is a problem for me as
| I am for privacy and encryption, but it works for everybody, it
| is friendly and easy to use.
|
| I will keep a close eye on matrix and try to adopt it again, but
| right now it is not usable for us.
| 3np wrote:
| > federation issues
|
| > gazillion TCP connections
|
| We've been running a Synapse server with quite a bit of
| federated rooms, even larger ones like you mention. Never
| noticed a single issue like this that I recall.
|
| I wonder if the reason is that we're doing whitelisting,
| instead of federation with everyone by default. The
| whitelisting is quite liberal; I'll add a server as soon as I'm
| in a conversation thread with someone from that server, or just
| want to see their avatar. Sometimes when I'm waiting for
| something else I'll just scroll through a room and add a
| handful of servers. Essentially this is my proxy for only
| federation with "legit" servers and avoid being DDoSed.
|
| > there should be a server wide option to make it "easier but
| less secure"
|
| Disagree. Sure, UX can be improved, but compromising here
| defeats the purpose of why we're doing this in the first place.
|
| Another one of mine:
|
| - E2EE seems complex to implement and very few of the clients
| implement it fully and properly.
|
| This is the one point I think needs to be resolved before
| Matrix can be ready for wider adoption. It's kind of pointless
| without E2EE, or if Element is the only client that can work
| for all rooms and messages.
| kuon wrote:
| I didn't whitelist anything, maybe that was a source for
| issue.
|
| > Disagree. Sure, UX can be improved, but compromising here
| defeats the purpose of why we're doing this in the first
| place.
|
| The thing is, as I ran my own server in my office, SSL (with
| no E2E) is already a good privacy. And even with that setup,
| the server users got "harassed" by the UI asking them to sync
| devices keys.
|
| For many users, a single prompt about security is enough to
| discourage them.
| CameronNemo wrote:
| So you are asking for a client setting (in Element I
| presume) to stop nudging users to set up e2ee? Did you file
| an issue for that?
| kuon wrote:
| If I try again to "convert" non technical people around
| me, I'll try to document properly what is wrong in the UX
| and experience. (but maybe it will all be fixed)
| IceWreck wrote:
| Your problems are with synapse. I had a similar experience with
| it in 2019. Dropped matrix for a while and started using
| Dendrite in 2020.
|
| It still lacks features compared to synapse but I'm happy with
| the performance. Notifications are sorely missing but I think
| the PR to add them is finally ready to merge.
|
| Give it a year or two and you'll have a full featured matrix
| home server that can run on a raspberry pi.
| blitzar wrote:
| I believe that is when the Year of the Linux Desktop is
| scheduled as well.
| italwayslags wrote:
| Arathorn wrote:
| When was this? I suspect most of the problems here are due to
| users joining lots of big federated rooms, which will use loads
| of resources irrespective of how many local users you have.
| This is also what Fast Joins are trying to improve (at least
| for join speed) from the original post. Likewise the matrix-
| hookshot webhook bridge.
| kuon wrote:
| I discontinued the server 2 months ago, and I operated the
| server for about 2 years.
| janikvonrotz wrote:
| Marked as spam.
| teitoklien wrote:
| Synapse is bloated and mostly good for very large
| organisations.
|
| Use conduit.rs or dendrite. I use conduit and it takes a couple
| of MB ram even while I'm in large rooms
| kuon wrote:
| Last time I checked critical features were not supported,
| like read receipts.
| teitoklien wrote:
| I use conduit to run multiple rooms, read receipts have
| been working just fine.
| kuon wrote:
| I will give conduit another look if I ever try to setup a
| server again. I am quite active in the rust community and
| maybe I could also participate.
| teitoklien wrote:
| goodluck!
| nisa wrote:
| I'm running a small (at the beginning it was completely public,
| now I'm keeping an eye on registrations) homeserver with
| synapse for a few years - I really like Matrix on a conceptual
| level and I'm happy that it exists even through it's not
| perfect it works pretty well mostly. I don't want to be too
| harsh because it's the best decentralized alternative for chat
| at the moment and it's open-source and there is a lot of
| progress but damn' it was a pain in the ass to run that
| server... we solved our problems mostly with throwing resources
| and memory on the problem... it's a nice tour de force if you
| want to learn about debugging distributed systems but it's
| nothing to install somewhere and just keep running.
|
| synapse is quite a mess and there are a lot of hidden footguns
| if you just run a server - this is just the tip of iceberg to
| keep the postgres database somewhat sane:
| https://levans.fr/shrink-synapse-database.html - lot's of other
| issues in the issue-tracker where you can just scratch your
| head.
|
| bridges are all subtly broken - the xmpp bridge is horrible and
| broke in so much interesting ways that I'm not going to touch
| it ever again - telegram works okay most of the time, irc-
| bridge also have some warts - but it's easy to criticize from
| my chair and probably unfair to talk so negative about it here
| but it's often buggy and broken for edge-cases - it works most
| of the time pretty okay but it's quite a mess to get a mental
| model for the code and so it's difficult to debug things.
|
| moderation/spam/etc.pp is all hackable but not there out of the
| box - it looks and feels like mostly quickly hacked up nodejs
| code that at least for us exploded in all kinds of interesting
| ways. https://github.com/matrix-org/mjolnir writing 3tb of logs
| in a few day and eating memory like crazy for instance. You
| have to babysit it and there is no simple ui for anything.
|
| So it's powerful but requires quite a bit of dedication and
| patience to get right. It's a full blown distributed system and
| often state is all over the place and once you make a mistake
| it's difficult to impossible to get that thing do work correct
| again without starting over.
|
| But there are so much promising projects that I'm confident
| that these issues will be resolved and it will only get better
| but in my experience it will break badly on all kinds of edge-
| cases - the mentioned xmpp-bridge created usernames that can't
| be deleted via the http api for instance. someone bridged 1000
| channels via our telegram-bridge and there is no code to remove
| those channels - you have to code something up in python for
| yourself. irc bridge kicks you after 30 days idle because they
| can't handle the connections - freenode (before the takeover)
| said it's not them - maybe single threaded nodejs is not such a
| good idea for that.
|
| Could I do it any better and delivering? Probably not. But
| except some adventure and if you want to deploy it for an org
| carefully test any assumptions you take for granted. It's cool
| but it's also kind of quick'n'dirty in a lot of ways. Still
| better than anything else I'd use it over any megacorp
| messenger anytime but maybe don't switch your family yet.
|
| But for using it you don't have to care - and there are great
| projects like https://github.com/spantaleev/matrix-docker-
| ansible-deploy that solve most of the problems out of the box
| and mobile clients and web clients and E2E crypto also works
| really well.
| jeroenhd wrote:
| I've looked into putting Cactus Comments [1] on my website, but I
| kind of had to can that plan when I found out that it requires
| the slow and resource hungry Synapse homeserver implementation at
| this point in time. I was hoping to use Conduit or Dendrite, but
| those are simply not ready yet.
|
| In my opinion, the biggest problem with the current Matrix
| platform, especially if you self-host, is the server
| implementation. It's not buggy, but it's just awfully slow. The
| "dpt of ping" [2] section at the bottom of the weekly Matrix
| updates show that five seconds of latency between servers
| (measured by basic ping bots) is far from uncommon. The latency
| is still significant in the non-synapse version of the graph, but
| it's much better already.
|
| With the speed new MSCs are accepted every month I don't think
| any alternative server stands a chance at catching up to Synapse
| any time soon, and I don't know how I feel about that. Yes,
| Matrix is an open platform with an open source spec, but it's
| effectively impossible to develop an alternative backend
| implementation with the way development is currently done, unless
| you've got a lot of developers and money to throw at the
| platform.
|
| I'll probably look into Conduit again in a few months, hopefully
| the project will keep up it's impressive pace so that it's useful
| for my purposes.
|
| [1]: https://cactus.chat/
|
| [2]: https://matrix.org/blog/2021/12/17/this-week-in-
| matrix-2021-...
| karmanyaahm wrote:
| I'm running Synapse and Cactus chat on a 1gb memory, 1 vCPU
| Linode and it's just fine.
|
| Given, I have a small blog (ie low load on cactus), but I'm in
| many (15+) medium sized (100-1000 members) federated chats and
| it's just fine on a day to day basis.
|
| There are some limitations tho:
|
| - I can't join large rooms (2000+ members and whatever number
| of servers that entails on average)
|
| - Initial sync (first time log in on new client) is crazy slow
| - syncv3 will hopefully fix this
|
| My definition of not being resource hungry is being able to run
| on a 1gb, 1 vCPU VM - however you and me might have a
| difference in that opinion
| jeroenhd wrote:
| I think the initial sync issue is one of the worst problems,
| because someone joining in to leave a quick comment will be
| waiting for the system to synchronize. You can run the system
| on 1GiB/1 vCPU, but that comes with a performance penalty.
|
| My instance of Synapse definitely can't join any matrix.org
| chatrooms, no matter how hard I try. Even rooms with a few
| hundred participants are awfully slow and leave scrollback
| state a broken mess. When I tried to join the main Matrix
| channel, both of the CPU cores I had dedicated to Synapse
| were pinned for at least half an hour, even after I tried to
| cancel joining the room!
|
| I hope sync v3 lives up to the hype, but I'm wary. Synapse's
| Pythonic base seems ill-fitted for an instant messenger
| backend in my opinion, and no amount of protocol trickery can
| work around that.
|
| It's not that I think the 1GiB is necessarily that excessive,
| but Dendrite and Conduit are blowing Synapse out of the park
| in terms of performance, to the point that I'd almost rather
| see the Matrix folks dedicate their development efforts more
| on bringing Dendrite up to speed than to expanding
| functionality.
| Arathorn wrote:
| Well, you can try sync v3 today via sync-v3 proxy (which is
| written in Go) and Hydrogen, as per the video linked in the
| post. It solves the initial sync problem completely; it's
| not hype; it's real.
|
| The main thing that bogs down Synapse is if users join
| massive federated rooms and you end up replicating huge
| amounts of traffic onto your server. So we're working on
| that too via Fast Joins and better-than-full-mesh
| federation for P2P.
| altantiprocrast wrote:
| > I think the initial sync issue is one of the worst
| problems, because someone joining in to leave a quick
| comment will be waiting for the system to synchronize
|
| The initial sync issue is only a problem for large accounts
| which have joined many rooms. Cactus comments creates a
| guest user for non-logged-in commenters, and an empty guest
| account is pretty much instant to load in my experience.
|
| You can go to my cactus comments instance (running on
| aforementioned 1gb machine) to test out the speed
| https://karmanyaah.malhotra.cc/tech/2021/06/website-things/
| trumpablehump wrote:
| Can I use separate identities in the same Element instance yet?
| Especially with Spaces I feel like this is an obvious feature
| where it should be easy for people to protect their privacy by
| using different accounts for different hobbies or peer groups.
|
| I would love to finally be able to use my employer's chatrooms
| with my real name, the animal rights group with my one pseudonym
| and the techie chat with the other one.
| jeroenhd wrote:
| Fluffychat allows multi-account logins on the same device, if
| that's what you're looking for. I haven't tested it myself, but
| it seems similar to the way the Gmail app operates with
| multiple accounts (you switch over to a new account and get
| content specifically for that account, rather than mixed rooms
| from different accounts all in one list).
|
| In practice, though, I'd be impressed if you could even find
| three different circles that are all on Matrix. I haven't found
| many people who are willing to switch yet over, anyway.
| mroche wrote:
| It sounds like you're asking for a Slack style configuration,
| e.g. where each workspace (in Slack terminology) needs to be
| authed into and can use different accounts within one app
| instance?
| kevincox wrote:
| Slack is a bad example here because you can't really use
| different accounts at a time (at least on web). It just
| provides a relatively easy link to switch between them. Maybe
| app/mobile are better?
|
| But yes, I think OP is asking to be logged into two accounts
| and see the rooms/contacts/notification from both in the same
| application. This is not currently supported in Element and I
| don't think it is on the near roadmap. But some other clients
| do have multi-account support.
| Arathorn wrote:
| Not yet. Hopefully one for 2022!
| jeltz wrote:
| Is there any Matrix to Matrix bridge? Such a bridge should be
| able to solve the problem short term.
| MayeulC wrote:
| > nightmarish pain point that is the amount of time we spend
| implementing the same features across the three different
| platforms
|
| I've been toying with the idea of providing dynamic extensions to
| Matrix rooms by sending a WASM payload as an event.
|
| That WASM could then provide new UI elements, interactions,
| interpret events, etc. This could be used to implement polls (I
| know it's coming, but that's an example) or whiteboards inside
| existing clients.
|
| It's just an idea, not sure how it would work in practice... But
| if anyone wants to have a go at it, be my guest!
| yjftsjthsd-h wrote:
| That sounds terrifying from a security perspective. I know wasm
| is sandboxed, but it's in a sandbox with all the user's data
| and parts of the user interface, which is quite enough to do
| damage.
| MayeulC wrote:
| I agree that the attack surface needs to be carefuly thought
| about. It shoudln't be much harder than current "widgets",
| though.
|
| I was thinking of something that only does I/O with data
| contained in the room it's in. I think the UI would be the
| hard part, but it could be doable with a few HTML tags and an
| extensible UI.
|
| For instance: add an "insert poll" button, or an "add voice
| message" button. Or an "add sticker"/emoji/gif, etc.
| Currently every client needs to build this individually.
| Users could pick the features they want in their clients.
|
| Moreover, not every plugin needs to be third-party. A
| "trusted store" could very well be maintained.
| Arathorn wrote:
| Fun fact: this blog post comes out at 26 pages of A4. If anyone
| wants assistance digesting it, I can try to help answer stuff
| here :)
| 2Gkashmiri wrote:
| android element. why can't we forward a text or a photo or
| anything? i have to "share" and then select a chat or a room to
| forward to. any reason for this issue to exist? i personally
| never joined whatsapp and quit telegram during the last mass
| exodus to telegram.
| marginalia_nu wrote:
| It's more like 18 if you remove all the videos and images and
| various other cruft.
| anchpop wrote:
| In what way are the images "cruft"?
| marginalia_nu wrote:
| In the sense that they take almost an entire screen, yet do
| not convey information comparable to an entire screen's
| worth of text.
|
| The hex of these types of graphics is that they don't
| actually say a lot at all beyond "one thing is slightly
| bigger than the other", or "the thing is a bit faster now".
|
| There are things that are easier to convey with a picture
| than with words (like the how much bigger the sun is
| compared to the earth, "really really big" doesn't quite
| cut it), but this is not such a case.
| MayeulC wrote:
| typo: minimising battery life on mobile
| Arathorn wrote:
| fixed, thanks
| slickdork wrote:
| I've been attempting on and off the last few years to spin up a
| non federated matrix server in my homelab to make an alternative
| to discord for my friends. I run into some various issues every
| time. I'm pretty good at tech, but for whatever reason the
| barrier to getting a working self hosted matrix server seems too
| high for me.
|
| I really would like to move to an e2e encrypted discord
| alternative. Maybe someday I'll be able to do that with matrix,
| when ether it gets easier, or I get smarter.
| AndroidKitKat wrote:
| Have you seen this repository[0] that automated most of the
| configuration? I have a similar goal to you (get family off of
| Google Chat), and I was pulling my hair trying to manually set
| things up. Now the hard part of getting them to migrate...
|
| [0]: https://github.com/spantaleev/matrix-docker-ansible-deploy
| slickdork wrote:
| I was just looking at this yesterday, actually! Thank for
| sharing. It looks very promising. I think my main issue is my
| only hypervisor right now is unraid, and I'm a bit hesitant
| to open ports on my firewall directly to a VM on unraid since
| it's also my personal NAS (I think there's security questions
| there, even if it is just a VM on it's own vlan? Not sure how
| possible VM escape is on unraid with this playbook).
| davidhyde wrote:
| > "Social Login via multiple SSO providers (MSC2858) - almost 50%
| of new registrations on the Matrix.org homeserver now use social
| login!" Interestingly the split of SSO usage is roughly 70%
| Google, 12% GitHub, 11% Apple, 6% Facebook and 1% GitLab.
|
| Congrats to the matrix team, really great work. However, I'm a
| little confused by the excitement around "social login". Why is
| it such a great thing? Aren't you just giving someone else power
| to shut you out of Matrix? We hear so many stories about lives
| ruined because of arbitrary (often automated) account locking
| that I just don't understand why anyone would risk using social
| login at all.
| blitzar wrote:
| Welcome to federated decentralised service. Please log in with
| your facebook account.
| twicetwice wrote:
| This seems like a flippant insubstantial criticism. Facebook
| is one of many many options--including first-party
| username+password auth.
|
| It's more like, "Welcome to our federated decentralized
| service. You can log in with your Facebook account if you
| want to." Which doesn't sound like a bad thing to me.
|
| More choices for users is usually a good thing. If users'
| choices have bad consequences, that's not Matrix's fault.
| Though maybe Matrix should warn people that if 3rd-party cuts
| them off they'll be locked out of their Facebook account too
| --choices need to be informed!
| Arathorn wrote:
| The excitement purely comes from the fact it makes it way
| easier for casual users to try out Matrix (even at the expense
| of then being beholden to the SSO providers), and it forced us
| to dogfood and land first class SSO support :)
| dane-pgp wrote:
| If someone uses a third party SSO provider, can they create
| recovery codes to mitigate the risk of having their account
| closed by that provider? That would be a nice feature to
| prompt such users to make use of, once they've tried Matrix
| out for a while and have built up some chat history and
| connections they wouldn't want to lose.
| Arathorn wrote:
| Not yet, but it's on the horizon (it's the account
| portability / multihomed accounts stuff in the OP)
| lsowen wrote:
| A big thank you to the entire matrix team. You've tackled a big
| problem space and made great progress. Here's to a great 2021 and
| and even better 2022!
| exdsq wrote:
| On the release day of Matrix: Resurrections too!
| 2pEXgD0fZ5cF wrote:
| I have been using matrix for quite a while now, and managed to
| get the people I write the most with on it too!
|
| Back then I rented matrix hosting with modular.im (now called
| ems) once I noticed that I did use Riot/Element on a daily basis,
| and the latency of matrix.org servers was too big for my taste,
| combined with the lack of online status display.
|
| Now that dendrite is starting to finally mature, I will probably
| switch to hosting it myself to save some costs.
|
| Main things stopping me are the possible headaches around domain
| names and federations: How hard is it to move to a different
| hoster once I have an instance running?
|
| I read in the documentation that things can become problematic if
| I don't carefully backup parts of my dendrite matrix instance.
| What would happen if I (or rather my hosting provider) lose my
| files and have to setup my matrix instance from scratch, will my
| domain then remain blocked on the federation, even when I still
| have control over the domain?
|
| It's not that I don't do backups, but I'm curious what would
| happen in a worst case scenario.
| MayeulC wrote:
| I think this scenario isn't handled too well, and I'm afraid
| servers that have seen your previous server will refuse to talk
| with it, and continue spamming the old address. Make sure to
| backup your server's private key so that you can properly leave
| rooms. It's usually better to leave all rooms prior to
| decommissioning a server, too, but I am not 100% sure it would
| prevent that issue.
| jeroenhd wrote:
| I believe federation recovery should be possible assuming you
| have access to the server's signing key. Without it, you'll
| probably run into conflicts.
|
| You'll definitely have problems with missing rooms, missing
| user encryption, the lot of it. I think it _should_ be possible
| to re-create and re-import signing keys onto a new server, but
| I wouldn 't rely on it. You'll probably end up with broken
| clients for ages. You'll also definitely run into loads of
| clients 404ing on your server, trying to download media that no
| longer exists. Personally, if I'd lose access to my server, I'd
| just start over with a new domain and get my backups in order
| that time.
|
| If you have backups you can recover, you can get everything up
| and running painlessly by pointing DNS to the new server and
| waiting for DNS propagation to finish.
|
| As for moving between hosters, there's a tool for that:
| https://ems.element.io/tools/matrix-migration; it's a tool
| that'll invite your new account into every room your old
| account was part of, transfer profile pictures and such and
| optionally kick the old client from rooms after migrations.
| That'll only help if your new account is on a different server,
| though.
| brunoqc wrote:
| Any big progress on p2p? I mean more in the MSC side (multi-homed
| identity and stuff like that).
|
| Also, arewep2pyet.org pretty please.
| Arathorn wrote:
| Only the stuff mentioned in the blog post. I've written the
| content for arewep2pyet.com; need to just get it live.
___________________________________________________________________
(page generated 2021-12-22 23:01 UTC)