TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Matrix Client Tutorial

141 点作者 whereistimbo6 个月前

6 条评论

alwayslikethis6 个月前
The lack of good clients is really holding Matrix back. Element is rather bloated, and most of the other clients are missing significant amounts of features.
评论 #42144926 未加载
评论 #42143606 未加载
评论 #42144766 未加载
评论 #42144922 未加载
评论 #42144777 未加载
Arathorn6 个月前
There was a comment here complaining that Matrix is a failure as an open protocol because encryption in Matrix is too complex and hard and PFS is overrated and &quot;why can&#x27;t we have a simple protocol for chat like Wireguard is for VPNs&quot;... but it got deleted while i as writing my reply. I&#x27;ll post the reply anyway:<p>Matrix without encryption is as simple as it gets - e.g. here was a younger, happier me writing a working client in 8 lines of bash: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20948530">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20948530</a><p>With encryption, inevitably things get way more complicated - especially in a decentralised network which needs to be byzantine fault tolerant. As you say, we&#x27;ve successfully simplified this by providing best-in-class implementations like matrix-rust-sdk-crypto - which i&#x27;d argue is the equivalent to Wireguard (which under the hood is a bunch of gnarly crypto, even if the API it exposes it simple).<p>In the end, encrypting messaging is just way harder than a VPN. The encryption hooks need to know the membership of the room (as users), the membership of the room (as devices), verify identities of all devices and their users to prevent MITM, verify that only the right devices can be added to the room, handle accessing history for new logins and new joiners, handle backing up history if you log out of all devices, handle receiving msgs if you log out of all devices, handle encrypted push notifs and allow multiple processes (push, share extension, etc) to share the same crypto state, scale to thousands of devices, etc etc.<p>Meanwhile if you simplify that by removing PFS - sure, some of it gets better (&quot;the room history gets encrypted by a static password!&quot;) but then breaching that secret from any client at any point trivially leaks the whole history of the room.<p>In terms of &quot;Matrix as an open protocol isn&#x27;t very successful&quot;, i suggest taking a look at <a href="https:&#x2F;&#x2F;2024.matrix.org&#x2F;watch&#x2F;" rel="nofollow">https:&#x2F;&#x2F;2024.matrix.org&#x2F;watch&#x2F;</a> for the zeitgeist from a few weeks ago. It&#x27;s working for some folks at least.
评论 #42145376 未加载
评论 #42146334 未加载
评论 #42148882 未加载
评论 #42145579 未加载
huxflux6 个月前
I&#x27;ve been setting up servers for everything ranging from IRC to Teamspeak, Exchange, and you name it. But how come setting up a Matrix server is still a science in itself?<p>Yes, I&#x27;m aware of the Ansible script, but should that really be the only somewhat reasonable option? When Matrix wrote &quot; Matrix 2.0 a new chance if you gave up on us in the past&quot;.<p>I listened, but without a somewhat reasonable setup process for the server and the ongoing confusion in terms of clients, it hasn&#x27;t gotten any easier to onboard to Matrix, unfortunately.
评论 #42146778 未加载
评论 #42146350 未加载
评论 #42145515 未加载
solarkraft6 个月前
Oh my, this looks nice and comprehensive!<p>I’ve been wanting to write a Matrix client for a while now, but found myself too caught up in getting even an existing library to work: The Rust SDK, the most maintained and batteries-included SDK, doesn’t have JS bindings and the JS SDK is insufficiently documented and generally seems a bit crusty.<p>In general I find there to be a bit of a lack of guides on implementing Matrix, which is probability a factor in there not being that many implementations.
评论 #42186616 未加载
ranger_danger6 个月前
Finally something besides the matrix foundation&#x27;s &quot;lol the auto-generated API docs are enough&quot; nonsense. This really helps a whole lot better.
amstan6 个月前
I tried to do something similar. It&#x27;s infuriating how the client must be stateful and have local storage, for both the access_token and even last message recieved. That&#x27;s right you must remember as the client where the last events [1] you&#x27;ve seen (even if you already told the server to mark it as read) was or else the server will happily send you the same messages over and over again.<p>I kind of miss making IRC bots where things were much simpler and ... quicker honestly (latency wise).<p>[1] <a href="https:&#x2F;&#x2F;uhoreg.gitlab.io&#x2F;matrix-tutorial&#x2F;sync.html#:~:text=we%20retrieve%20the-,next_batch,-property%20to%20use" rel="nofollow">https:&#x2F;&#x2F;uhoreg.gitlab.io&#x2F;matrix-tutorial&#x2F;sync.html#:~:text=w...</a>
评论 #42144114 未加载