u_tamtam @ u_tamtam @programming.dev

Posts

6

Comments

454

Joined

2 yr. ago

A prime one is that the entity that you (have no choice but to) trust today will eventually turn against you at some point down the road.

How does that change with federation, you always trust someone. Why should I trust the shady person running software on their basement, even if you self host, you are trusting the developers not to ship bad or poorly written code.

Federation is different in that:

• you can chose amongst a very diverse pool of providers, including local ones that you actually have a chance to meet in person, those with shared ideals that enable long-lasting/mutually-beneficial relationships, some operating truly in the open and enabling a just and provable retribution for the offered service (i.e. "you are not the product"), etc
• you can be your own provider, and with "turnkey" self-hosting options like https://snikket.org/ , it's never been easier to do it safely at small/medium scale, and cheaply (e.g. for a family/neighbourhood/association on a shared instance/RPi/…)
• choosing a provider never cuts you off from the rest of the network: you are not tied to anyone, and you can migrate with no drama nor loss of contacts/histories/data like is the case when the captive networks "flavour of the year" inevitably shut down.

using a 3rd party client is against Signal’s ToS

As far as it being against signals tos, molly exists and had not received any problems from the signal foundation to my knowledge, discord has the same clause and they don’t seem to give a rats ass.

You must be new on the internet to believe that this is a sustainable state of affairs. Google was letting you use GApps for free until it didn't. Reddit used to be mostly usable and ads/clutter-free until it wasn't. Recently Unity pulled a weird one against their users and customers for a quick buck. Examples are plenty, and more recently people have referred to this as "enshittification" or "the tyranny of the marginal user". Such monopolistic networks are particularly prone to that phenomenon, by design. Personally I don't want to live under the constant threat of a single entity potentially changing its mind/ToS, and I certainly don't want to drag my family, friends and peers into the gamble.

pushing controversial features like crypto payments

The crypto stuff wasn’t great but you know what’s cool? You don’t have to use it. Simple as that. You don’t have to engage with it and you and I both know that. It’s buried in settings and you have to find it yourself.

fair but you missed the point: Signal already controls and enforce this aspect of your user experience, which only benefits themselves, in spite of the significant backlash. Sure you can feign blindness, but what's next and what recourse will you have ?

Signal is an entity that’s incorporated in a jurisdiction and might be compelled by law or to degrade its encryption to comply with the local regulator.

I’ve always used integrity as a metric as to how trustworthy a service is, and in terms of signals e2ee, they’ve never lied about it, it’s been proven in court multiple times not having any data on their users, no government can compel anyone or any company for things they don’t have.

Integrity has nothing to do with that, Signal can absolutely be forced by law to suspend its service in some countries (e.g. to implement sanctions) and whole regions can disappear from the network overnight. In terms of resiliency, that's pretty much how email (federated) just works from anywhere, but things like WhatsApp are blocked in e.g. China or allowed to work without E2EE (e.g. in some Gulf countries).

You can’t really confirm what any software can or cannot do

Sure, but you missed my point, in case of sealed senders and contacts discovery, we are not talking about zero-knowledge/E2EE but about Signal basically saying "trust us, bro, we ain't looking at it" which can't be proven one way or the other.

If everything is encrypted, what could Amazon tap? You do realize sealed sender and PFS take away any trust from the server correct?

I'm not sure that you understand what's really going on. All your messages are routed through Signal. You can absolutely infer who's talking to whom with enough frames by just matching packets popping out of X and being received by Y. Encryption plays no role in that because this takes place at a lower level. At least some protocols like XMPP let you host services entirely on Tor or to even skip the central server.

https://gultsch.social/@daniel/109828650796048124

FYI that's an app that's used by the German police and in several other "sensitive" contexts where users won't just pull it from the play store :) ISIS even had their own fork at a point.

And since that time, XMPP has improved significantly (more integrated with other protocols, more efficient client and server implementations, bridges from and to activitypub, more approachable, easier to self-host...), but Signal.looks to have ... stagnated? Well... the crypto payments/web3 shady stuff aside :)

It would, just looking at how much data gets transferred

Thanks for taking the time to reply. There are multiple issues with centralization.

• A prime one is that the entity that you (have no choice but to) trust today will eventually turn against you at some point down the road. In the case of Signal, the writing is on the wall already: using a 3rd party client is against Signal's ToS, and Signal has been seen pushing controversial features like crypto payments that, as a user of their captive ecosystem, you have no choice but to engage with.
• Signal is an entity that's incorporated in a jurisdiction and might be compelled by law not to provide service for certain users, or to degrade its encryption to comply with the local regulator. Using a centralized service like Signal makes you an easily identifiable/prime target in such a scenario.
• No matter what Signal says, nobody but themselves can verify what code runs on their servers, and what amount of logging/data processing goes there. Because every account checks in through them, because every message is routed through them, there is no technical barrier to knowing who's who, who's talking to whom and when, with the nature of the communication (text, video, image, …) from which a lot can be inferred. As far as I understand the American law, any agency could tap into that, either directly, or via Amazon on which the whole thing is running. I am not paranoid enough to believe that 3 letter agencies belong to one's typical threat model, but with SGX contact discovery from phone number and sealed senders, Signal kindah panders to those? Either way, those are unverifiable mitigations to problems that decentralized systems do not have.

I could go on and on, but the first one is the main one IMO: we are past the need to trust anybody with our instant messaging and put a fundamental aspect of our lives at the mercy of (geo)political and societal woes. That's practically a solved problem in the opensource world, and we can make it ethical and sustainable by just opting out of the dominative model of monopolistic and centralized systems.

And an objection by the author of a popular XMPP client: https://gultsch.de/objection.html

The page isn't loading currently… What protocol is it using? and if neither XMPP or Matrix, then why even bother?

I managed to convince my family to use XMPP. Since about 2015. It's been great, and apparently is getting better since more are joining :)

A truly better signal is one that's not using a centralized service.

Octoprint has tons of great plugins and features that mainsail/fluidd have no equivalent for, and can be used to control klipper printers too.

This is a project I am already keeping a close eye on, but I would rather qualify it as a "better SQL" than as an alternative to your typical (framework's) ORM. For instance, it won't morph CRUD operations and data migrations into a language/stack that's native to the rest of the project (and by extension, imply learning another language/stack/set of tools...)

Ohh, so you were talking about finding communities in the literal sense. Most clients these days hook into the https://search.jabber.network/ API, so you can just go to the "discover channels" section of your client and type "selfhost" and find xmpp:selfhost@chat.disroot.org?join and xmpp:selfhost@chat.moparisthe.best?join

My point was more that creating a chatroom doesn’t create a community.

how would you define a "community"? And how big a deal is this effectively?
As far as I'm aware, communities (if defined as a list of rooms under a same namespace) are native to XMPP in the sense that MUCs can be namespaced at the domain level (e.g. "welcome@mycommunity.server.tld"), and then it's up to clients to do something about it. I've seen some discussions going over jdev recently but there didn't seem to be too much interest (even though clients have had a decades-long head-start to tease potential users).
IMO/IME, the "community" approach as found in discord & al. is rather detrimental and makes the relevant information hard to track because of excessive (per-server/community) rooms & notifications micromanagement. Decades old communities and projects have collaborated successfully on IRC over a single/couple of rooms and this doesn't seem like a problem in practice.
More than the proliferation of rooms, I'm more interested in threading which is seeing a comeback as of late (e.g. in Cheogram), which is somewhat more comparable to zulip and "gentler".

ORMs introduce a different API for making SQL queries, with the aim to make it easier.

I wouldn't say that, but instead, that they strive to keep everything contained in one language/stack/deployment workflow, with the benefit of code reusability (for instance, it's completely idiotic, if you ask me, that your models' definition and validation code get duplicated in 3 different application layers (front/API/DB) in as many different languages.

ORMs are not a 100% solution, but do wonders for the first 98% while providing escape hatches for whatever weird case you might encounter, and are overall a net positive in my book. Moreover, while I totally agree that having DB/storage-layer knowledge is super valuable, SQL isn't exactly a flawless language and there's been about 50 years of programming language research since it was invented.

That's kind of how we all get to use and enjoy the GPS today

Apparently they say it's the Ukrainians shelling themselves...

with no user benefits for this extra complexity,

This is not true. One of the benefits I’ve enjoyed greatly is being able to point a group of non-techies at a URL and have them up and running […]

I was talking about the protocol's complexity, Matrix is indeed notorious for that (you can lookup "Matrix state resolution" if you want to know more). That's not removing anything from the good work they've accomplished on the client-side, which you've highlighted, but just to be fair to XMPP, that's not unique to Matrix and you can find something comparable e.g. here: https://jabberfr.org/

with only a single entity […] being in charge

Also not true.

It's true and easily verifiable in practice, just check-out who's doing the work, who's operating the network (still very centralized), who's operating the gateways/bridges, and where the finances are going. Being an open protocol is a good start, but more important is how diverse is the ecosystem of client and server implementations and actors, and although the client-side has seen some diversification in the recent years, it's still very much an issue. New Vector Ltd is failing in one area, and now tens of thousands of users are disconnected from thousands of rooms. Now, compare that with the XMPP ecosystem, and the dozens of companies, individuals and NGOs contributing/sponsoring and authoring the protocol and its implementations.

There is no single client or server.

There is only one client that's fully featured, and it's element, there's only one server that's mature and that's synapse, none are fully spec-compliant, both are maintained by New Vector Ltd. You don't encounter such a rift between "the reference client" vs "the rest" in the XMPP world, and you don't see situations where the spec is updated "best-effort" from the implementation.

but it’s a niche within a niche. It doesn’t address the problems that Matrix solves.

What do you think are the problems that Matrix solve, essentially?

• It won't ever become a "messenger for the masses", it's just not that good compared to WhatsApp and Messenger.
• It won't ever become the reference "open-source, open-protocol" messenger, Signal is there to stay.
• Remains the niche of "the messenger that I self-host because I can" which is shared with XMPP.

In this regard, Matrix is much harder and costlier to run. It addresses the same problem space with more overhead and complexity, which costs them in terms of diversity of implementation and resilience. When I wrote earlier about large users dropping them, I had in mind the French government which cut their losses and stopped subsidizing New Vector Ltd, while much larger XMPP instances comfortably run millions of users privately and quietly (in things like online games).
I also have in mind the upcoming "Matrix 2.0" shake-up, which is the 3rd or 4th reboot of the Matrix protocol. It has a good chance of being the last one, though, because the new design basically starts from the realization that "the protocol is too complex, the client can't efficiently deal with that on the user's device, so clients will now run remotely, and a dumb frontend will connect to the proxy". So, expect even greater self-hosting costs and marginalization.

You could just roll out your community on XMPP and offer a web+anonymous access to it (converse and movim could be good options). In the end, that's no different than discord and many users' first exposure with Matrix. Now that I think of it, there's a mod_converse for ejabberd and maybe even for prosody as well.

What bothers me is that similar "words of caution" can be had about Matrix: it established itself in the same niche as XMPP, but with a much more convoluted and resource intensive protocol (that many already gave up on hosting at scale due to creeping costs and complexity), with no user benefits for this extra complexity, and with only a single entity (consistently experiencing financing challenges having measurable impacts on the quality of the product) being in charge of developing both the client and the server. That's some big red flags.

I don't believe Matrix to have any edge over XMPP nor any characteristics to make it more successful where XMPP isn't. It is definitely not learning from XMPP's history and consistently repeating the same mistakes. And this is written as someone who was an early XMPP adopter around the turn of the millennium, moved on, and while learning about it, wanted to love Matrix thinking it could be "XMPP, modern, reborn, without the boomer etiquette". Turns out current XMPP is just that and Matrix isn't, and I am happy to self-host XMPP accounts for a few hundred people, family and friends and to no longer have to do it with Matrix.