Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

the matrix is the great irc replacement that never was. i wanted to like the matrix, i still do, yet every time I use it, the list of terrible user experiences remains the same. its slow. its so slow. the riot design/layout is klunky. its slow. the federation is confusing. for example searching or browsing the list of channels 'works' maybe 5% of the time and its not clear how broad the search is attempting to be. its slow. I've got an invite that cannot be accepted or declined, so its there forever. its slow. the distinction between a person to person chat vs a room is confusing. i cant get the freenode bridge bot to change my nick. it says the bridge bot is offline when im talking to it and its responding.

there has been time to fix all this but it has happened. at this point I'm not sure if the api is simply hard to implement or if the go-lang server will help.

i've even looked at the ircv3 spec for innovation. thats how desperate ive become for some kind of advancement (grin). I enjoy writing chatbots and new features are hindered by irc's lack of per-message ID. I've run a synapse server and an irc bridge and was disappointed in the complexity and resource usage. so i stay in 1992 with good ol' irc and freenode.



have you tried riot.im/develop for a less clunky riot?

in terms of perf: yup, synapse is still nothing like as performant as it should be. as the talk in the OP explains, we opted to focus on getting a 1.0 which is 'correct' (in terms of stability and bugs and no design flaws) rather than fast. Fast comes next, and it should be more than noticeable.


thanks for the tip on riot.im/develop. looks like progress.


Independent Matrix Server developer here. You might be interested in a community-driven implementation that I work on which aims to address these issues. I'm delighted to read from you here that we share a goal for a great IRC replacement: https://github.com/matrix-construct/construct


thanks for the link. do you have a sense of whether the slowness is more in the web client or in the server response times?


It's really a confluence of factors. There are even elements rooted from the specification itself that contribute, for example requiring many round trips in network interactions with a lot of different servers; requiring large amounts of random disk access to implement core features... These things tend to shape the experience born out of client and server implementations even after a fair amount of performance work. I hope that Matrix-org makes an effort to consolidate the specification into something more streamlined for any upcoming versions.


Synapse, the reference impl server, was always pretty slow. It got a lot faster with its Python 3 transition and there is a Go server in development that I think the core team means to focus on once 1.0 is out.

There are also native clients like Fractal and Quaternion that use GTK / Qt UIs that are just as fast as any other native app.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: