I still can't believe there's been no response to the nickname colour proposal. This has been sitting in the queue for 2!!!! years now.
It's ridiculous.
This Year in Matrix
81–90 of 109 posts
Re: This Year in Matrix
#82I 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…
Ack, pretty all of those points are true, which is partially due to python.
Re: This Year in Matrix
#83Earlier quoted context omitted.
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.
Tried Matrix (and Synapse) the 3rd time a couple of months ago and gave up after a few days. Joining any larger federated room took days or did not complete at all. And then the messages were also delayed for quite a while. That must be the stupidest design I have seen. If it was not so messed up, Matrix probably would have become huge by now. I agree with others in comments, devs should have probably improved the fe…
It might be worth reading the actual post to see how we're fixing slow joins.
In terms of the language: it's not Python's fault at all. Instead, Synapse baked in a bunch of naive assumptions (being originally a prototype) which we have been steadily fixing... while also adding features, which pulls in the opposite direction. Given a choice between a featureful server that's resource-heavy (which we can then make go faster later) versus one which lacks the features to compete with centralised alternatives, we chose the former.
Re: This Year in Matrix
#84Earlier quoted context omitted.
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 fed…
The following comment is not well considered. I once installed Litecoin Core (on Windows 10) on my desktop PC. I had Comcast (branded as Xfinity) broadband, whatever speeds my region and apartment supported. I had a 1TB monthly limit before throttling. I lived in the east SF bay area. I downloaded Litecoin Core software at the beginning of the month. I got dial-up speeds for the rest of the month. I got a 5x average…
Totally agreed. Our goal is to support self-hosting on an RPi on modest broadband... or just to self-host P2P on the app itself. We are categorically not optimising (in the medium/long term, at least) for requiring massive hardware in order to self-host.
Re: This Year in Matrix
#85Earlier quoted context omitted.
> 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…
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 ab…
> And even with that setup, the server users got "harassed" by the UI asking them to sync devices keys.
I think Element is the only client doing this. So if you don’t care about E2EE, there are several options.
My point is, this is something that should be addressed in the client UX, not on the server- or protocol level.
Re: This Year in Matrix
#86This 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 be…
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).
It's not a problem; it's an intense frustration. It is irritating to be told "here's a new message X" at your desk, only to see and hear the same notification "new message X" on a phone within a few seconds. Your phone even vibrates, as if to demand your attention and chide you for not acknowledging the message. It's an additional distraction when we're all short on time.
My previous work used a system which queued notifications for delivery. The logic was something along those lines:
- send notifications for urgent items, e.g. incoming calls, immediately to all devices - if there are no active devices, send all notifications immediately - otherwise send to all active devices st internally along with testers.
I ended up tweaking this; it took us a few tries to get it right. I'd be flabbergasted if Facebook messenger, iChat, discord et al haven't done something similar.
Re: This Year in Matrix
#87I have been through two unsatisfactory home servers (librem and privacytools) and am trying to decide what to do next, maybe even self-host. In the meantime, Signal :--P
Whatever I step to, I will need to get my extended family onto it, and that is a big enough hassle I don't want to repeat another move..
I saw that, E2E notwithstanding, your home server has plaintext access to all traffic, which makes me leery of using cloud servers.
The other big roadblock is that I don't know of any client that can manage multiple accounts. I would have to use e.g. fluffy for personal, and element for work.
And I found what was labeled a Signal-Matrix gateway, but could not figure out how to set it gu he. If you are not accessible via Signal, your existence fades.
Re: This Year in Matrix
#88Re: This Year in Matrix
#89Can 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.
This would be MSC 3189 [1]. It is just a draft for now. So expect it to be shipped to clients in 3-6 months(?)
Re: This Year in Matrix
#90This 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 be…
Is there any other chat app that does this? Or want other app? Would be interested to see a PoC and experience how this feels.