-
> I don't think the intent is malicious, but the system is definitely leaky. My homeserver config doesn't mention vector.im (perhaps it's a hidden default somewhere?), I checked.
IIRC, identity server is something primarily set on the client (element.io here) rather than the homeserver.
It really needn’t and shouldn’t ping an identity server as part of the sign-in process (esp before/without privacy policy agreement)
FWIW it seems the issue is that there’s a fallback process for identity server; if neither your account nor your homeserver has one set, it defaults to the client default. if you host your own Element-web instance you can change this.
https://github.com/vector-im/element-web/blob/develop/docs/c...
Or check out ma1sd. You don’t need to enable all the bells and whistles if you don’t want to.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
Unfortunately XMPP<->Matrix end-to-end encryption is a contradiction in terms. You have to speak the same protocol from end-to-end, otherwise you'd have to break the end-to-end encryption to translate from one protocol to the other. The closest you could get would be to run the Matrix<->XMPP bridge clientside alongside your Matrix client... but at that point you might almost as well be running a multihead messenger that speaks both Matrix & XMPP.
In terms of adding Matrix to MUCs; i believe we're working on it in Bifrost, which is in active albeit slightly sporadic dev: https://github.com/matrix-org/matrix-bifrost.
-
I reverse-engineered the comms for my cheap Ecovacs robot vacuum and was surprised to discover that, like some angsty teen, it spent all day hanging out in an XMPP chatroom waiting for somebody to talk to it: https://github.com/wpietri/sucks/blob/master/developing.md
-
Give Cinny[1] a go. It's a new client built to be familiar to Discord users. I've switched to it as a daily driver, even tho it doesn't implement 100% the protocol. It has all the main features in a nice UI which is more than enough for me to daily drive it.
[1]: https://cinny.in
-
I made a better standard for this: https://github.com/tinspin/fuse
But of course it's suffering from this: https://xkcd.com/927/
-
There are a few other server implementations (polyjuice in Elixir https://gitlab.com/polyjuice/polyjuice_server; https://github.com/clecat/ocaml-matrix in OCaml; the abandoned mxhsd in Java) - but the most stable ones alternatives to Synapse right now are Dendrite (Go) and Conduit (Rust).
Matrix's API surface is big, and servers deliberately handle all the heavy lifting in order to make clients trivial to write, so writing servers is not trivial. But Dendrite & Conduit are both very usable and making good progress right now.
And yes, the APIs are all standardised (while also constantly evolving) as per https://spec.matrix.org :)
-
There are a few other server implementations (polyjuice in Elixir https://gitlab.com/polyjuice/polyjuice_server; https://github.com/clecat/ocaml-matrix in OCaml; the abandoned mxhsd in Java) - but the most stable ones alternatives to Synapse right now are Dendrite (Go) and Conduit (Rust).
Matrix's API surface is big, and servers deliberately handle all the heavy lifting in order to make clients trivial to write, so writing servers is not trivial. But Dendrite & Conduit are both very usable and making good progress right now.
And yes, the APIs are all standardised (while also constantly evolving) as per https://spec.matrix.org :)
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Lots of interesting stuff there - thanks :) We're using https://github.com/mwarning/meshnet-lab rather than imunes.net for network simulation currently, but will take a look.
Power usage is looking pretty positive so far; as long as we route the Matrix traffic over the routing topology rather than going full-mesh it should minimise radio usage (the main battery suck, other than screen).
For store-and-forward, honestly using P2P Nodes as intermediaries is an okay approach other than exposing metadata to them. Our plan in the longer term is to switch to loopix-style mixnets to obfuscate the store and forwarding, a la nym.
In terms of joining the network by deriving a private key from a passphrase... yup, that could be cute, although slightly terrifying in terms of the risk of weak passphrases :)
We're hoping to get the P2P network stable in the coming year (although we were also aiming for this year originally :P)
