Following the example of GitLab and other VC-funded open source companies, @element goes 'open source almost everything' with "Synapse Pro";
"Synapse itself remains open source, and Element will continue to develop it proactively, just as it has for the last 10 years ... Available under a commercial license, Synapse Pro will help fund and accelerate the continued open source development of Synapse for the benefit of all of Matrix."
https://element.io/blog/synapse-pro-slashes-costs-for-running-nation-scale-matrix-deployments/
@strypey @element big sigh. Sad. Tom Preston-Werner's 'open source almost everything' https://tom.preston-werner.com/2011/11/22/open-source-everything.html is one of the most depressing things I ever read. It assumes that only proprietary software has value. Which is flat out wrong.
@lightweight
> the code or the VCs or both? I'd be tempted to vote for both
Where did I leave that pitchfork ... ; )
@lightweight @strypey @element sure also the MIT license says a lot. It doesn't protect against Open Washing and that's exactly what they did with GitHub.
https://os-sci.com/blog/our-blog-posts-1/why-is-open-washing-a-thing-14
@os_sci @strypey @element the only reason it's difficult to sustain some larger #libre projects (e.g. Copyleft) is because the market is stupid and continues to pay a mint to be monopolised by proprietary software vendors. Libre software would be quite sustainable *if the market rejected proprietary software*... or if regulators did. As a proxy for this, gov'ts could regulate to require open standards compliance for all software purchased by gov't. I wrote this about it: https://openstandards.nz
@lightweight @os_sci @strypey @element governments should go further and have a long term vision that require all their software to be free/libre to invest directly in development, customization, and supportโnot in marketing, business expansion, or dividends for investors
Plus this would retain the freedom to move to a different service provider if the current one no longer fits their needs.
And of course software obsolescence, sovereignty, security, education...
(1/?)
@lightweight
> weak 'open source' (as opposed to Copyleft) license is essentially saying "we want the option of closing this codebase at some future point"
If I may copyright nerd for a moment;
As long as any outside contributors assign copyright to the company, the project license can't prevent that, even with a copyleft clause. The copyright owner doesn't need a license to use, so public license conditions don't bind them.
@lexoyo @lightweight @strypey @element Swiss did this. All code paid for with public money needs to be foss. Also the EU is trying. In the Netherlands each ministry has an OSPO. The main problem is the workforce, they want the proprietary shit. Have this problem at home too. Need to have WhatsApp because of my wife and daughter refusing to use Signal or Telegram
(2/2)
What a weak license does is allow a company to sharemilk the goodwill associated with Open Source, while making their main product proprietary. Even before BorgSoft enshittification made it obvious, GritHub was *always* exactly that.
Ubuntu's scAmazon Lens scandal was only shocking because we thought they were on our side, not because the DataFarming was an uncommon business model, even then.
@os_sci @lightweight @strypey @element EU is trying to get to open source right ? Not necessarily free/libre ? It's a first step but still the money goes to marketing and investors most of the time
@lexoyo
> EU is trying to get to open source right ? Not necessarily free/libre ?
Not sure what the distinction means in this context.
(1/2)
@os_sci
> Need to have WhatsApp because of my wife and daughter refusing to use Signal or Telegram
A shame their choice is WhatSapp, but good on them refusing fake solutions like TeleScam and Signal.
Any chat platform that isn't part of a multivendor, standards-based network is a proprietary chat platform. Even if all the code used in their deployment is published or linked, under libre licenses.
(2/2)
Making sure all the code used in a centralised platform is under libre licenses protects *their* freedoms, not those of the people using their platform;
@strypey @lexoyo @lightweight @element How can anything which has a recognized foss license be proprietary?
@os_sci @strypey @lightweight @element the problem is either when they claim to be open source with a non recognised lisence (fsf) or when just part of it is open
Also when a company wants to involve a community of passionate devs but also control and monetize everything, then this is not foss even with a gpl right?
(1/2)
@lexoyo
> this is not foss even with a gpl right?
Any code under the GPL respects your freedoms to use, study, modify and redistribute that code. So it's libre/ Free Software/ Open Source. As I've seen people use it, FOSS is a synonym for the same set of things.
Does the whole system respect your human rights and civil liberties, which is the founding goal of this style of software licensing? Not necessarily, but that's a larger issue.
(2/2)
I like to use Free Code to express this. It hasn't had much use by anyone else, but I like it because it includes a reference to Freedom, unlike Open Source.
But unlike Free Software, the phrase "Free Code" focuses our attention on the *code*, because that's what Free Software licenses have influence over. Not what the code does, nor what other software people used on the same computer. But on our ability to know what code is running on our own computer, and have it changed as needed.
(1/2)
@os_sci
> How can anything which has a recognized foss license be proprietary?
To access the Signal network you are obligated to use the server and apps binaries they offer. If you make use of Freedoms 2 and 3 to fork their app, or Freedom 1 to create your own, and you connect your app to their server, you're breaking their network license. So while the *code* is libre, the network is proprietary.
Does this make sense?
#Signal
(2/2)
It's like how all the core code of the Linux kernel is libre, but most of the versions distributed are proprietary, because to use them you are obliged to follow the license conditions of the binary blobs bundled with them.
Similarly, most GNU/Linux distros are proprietary, because while the majority of the code they're compiled from is libre, you can't run their without implicitly agreeing to the license terms of any proprietary binaries bundled with them.
This reinforces the confusion that Linux is more than a kernel.
Please write; "the kernel, Linux", "Linux, the kernel" or just "Linux" to mean Linux.
It is impossible to simultaneously comply with the requirements of the GPLv2-only and the bundled proprietary software, thus you are obliged to not distribute the proprietary version of Linux, otherwise you immediately and permanently lose your license.
Of course GNU Linux-libre can be distributed under the terms of the GPLv2-only.
@strypey @lexoyo @lightweight @element but could you connect it to your own server? Can you download the server code?
(1/2)
@os_sci
> but could you connect it to your own server? Can you download the server code?
Yes, you can make your own personal Signal server and connect whatever apps you like to it. But that would be pretty useless, since Signal isn't federated, so the only person there to talk to would be you.
Or you could make your own personal XMPP or Matrix server, and talk to anyone on the nonproprietary networks using those protocols.
(2/2)
Yes Signal software (currently) has some advantages over (current) XMPP and Matrix software. If your threat model requires those advantages, it might be worth the trade off of using a proprietary network at times.
I can't think of a single good reason to use TeleScam, unless you need to chat with someone who refuses to use anything else.
> The savings [...] are enormous, literally millions of euros if [...] deployments were built on Synapse Pro rather than Synapse.
Got to love that the #Matrix protocol is so computationally expensive it costs millions of euros in public funding to run. How much more millions of euros would they be saving if they would off-the-shelf #XMPP servers instead?
(1/?)
@uexo
> Got to love that the Matrix protocol is so computationally expensive
If you add enough XEPs to an XMPP server to do everything that a full Matrix server can do be default, the resulting protocol soup is no more computationally efficient than Matrix.
(2/?)
True, Synapse is written in Python, so it's not as efficient as the next generation Matrix servers written in modern production Go, Rust etc. Yes, they're not as feature complete as Synapse, and they have more catch up work to do with Matrix 2.0. But once this is done, the resulting servers will be more efficient than Synapse.
Where XMPP has an advantage is being much older, so the server software has been in development longer, and it's more mature.
(3/3)
A shame the same can't be said for XMPP client software. Much of which is stuck in the 1990s. Honourable mentions for the ModernXMPP project which is trying to drag it kicking and screaming into the 2010s ; )
Yes, funding is much more difficult for present day XMPP devs than VC-funded Element. But Jabber Inc, the creator of XMPP was funded by Webb Interactive and acquired by Cisco. Where did that money go?
@strypey ok. Got your point here. What's then the reason that the majority of the foss universe uses Signal and Telegram? I am thinking about writing a blog about this. What's your opinion about Delta Chat which doesn't use any servers at all. ?
@os_sci
> What's then the reason that the majority of the foss universe uses Signal and Telegram?
Do they though? I see Signal as more infosec people than software freedom people. I don't know why anyone would use TeleScam, since their server is proprietary, and their mostly unused E2EE is a joke.
To the degree that the Free Code dev world still use centralised platforms, it's for the same reasons people usually do; network effects. A lot of them are still on IRC (eg https://libera.chat/).
@strypey The computational effort of Matrix is not an issue of the programming language. It probably doesn't improve things that Synapse uses Python, but the main issue is in the protocol. XMPP has negligible computational overhead over fully centralized solutions due to using traditional message passing to get messages from sender to recipients. Matrix in contrast synchronizes an eventually consistent DAG of messages across all devices in the room.
@strypey We don't know exactly what Synapse Pro changed to be more efficient, but what we do know is that this is due to "shared microservices and components" for "high density multi-tenant deployments", which I guess is referring to Matrix complexity. In most XMPP servers, it makes little difference to resource consumption if a deployment is single- or multi-tenant, just because the workload is exactly the same.
@strypey We do know that open source XMPP servers have been used for huge deployments (talking about hundreds of millions of devices) and I doubt those cost even close as much as the way smaller "nation-scale" systems Element is talking about.
(1/2)
@pixelschubsi
> XMPP has negligible computational overhead over fully centralized solutions due to using traditional message passing
Like I said;
https://mastodon.nzoss.nz/@strypey/113727921159611399
If you compare email lists to other groupware solutions, without factoring in the computational and financial costs of listservers, and list archives, of course email lists are going to compare well. If you don't compare apples with apples, your comparison is meaningless.
(2/2)
Few if any XMPP servers offer everything a Matrix homeserver does by default. Eg are there even XEPs for server-independent chat rooms? How many servers offer them?
A lot of features that are at parity were only added to XMPP via FEPs after the Matrix protocol had them first. Eg DoubleRatchet E2EE, device cross-signing and sync of E2EE messages across apps.
Projects like ModernXMPP and Snikket are doing good work bringing these features to XMPP software. But they're well behind Matrix.
@strypey When it comes to XMPP clients: Yes some of them look a little dated, though most of them are also developed by some nerds in their spare time. If you look at commercially developed clients like https://prose.org, they don't give me exactly a vibe of being outdated.
@pixelschubsi
> commercially developed clients like https://prose.org, they don't give me exactly a vibe of being outdated
They've got a very nice website. Let me know when it's ready to test and I'll happily kick the tires.
@strypey Funding is certainly important and I'm confident that if the amount of money that went into Matrix and its ecosystem was directed at XMPP instead, we wouldn't even consider any alternatives today - but also you don't attract VC by doing the same thing as others, so what Matrix folks did made sense economically. The overarching issue is not Matrix vs XMPP, but how our economy works.
@pixelschubsi
You guys really do have your script don't you. Some day soon I really must write up the tired old XMPP vs Matrix script as a blog post and FAQ. Then any time someone wants to go through it again, I can just post a link.
> you don't attract VC by doing the same thing as others
Exactly! Matrix offered things XMPP of 10 years ago did not, and in most cases still doesn't. You can pretend all you like that actually-existing XMPP is a drop-in replacement, but it just isn't.
Do I get this right?
We can go for non-free Synapse Pro, which is #nonfree.
Or we can go for #freeSoftware Synapse (Con?) and kill the planet?
@debacle
> Do I get this right?
No. Most people are not running hosting farms for an entire country's public service, or realtime communications for armed forces. Deployments where there are potentially millions of simultaneously users, and every second of latency can matter.
So we can do without the kind of industrial strength hosting glue needed by Element or government IT public-hosters. Which is what the secret ingredient of Pro.
Besides, the solution to Synapse is funding Dendrite, etc.
@strypey In contrast to Matrix, XMPP actually has server-independent rooms (that is rooms purely managed on the clients). Matrix has server-duplicated rooms, that is rooms duplicate across all involved servers, but still on the servers. However this is all a technical detail. In practice, people join a server-managed room using a room id that is hosted on a single server - and that is in both protocols.
@pixelschubsi
> rooms purely managed on the clients
As I said, only a couple of posts back;
https://mastodon.nzoss.nz/@strypey/113729590562290538
You're ignoring resilient archiving of messages for both public *and private* groups, as if that's not a feature. Well I can assure you that it is, and one people care a lot about. Especially when we use chat rooms to deliberate and make decisions about our work.
@strypey What do you mean with ready to test? The web app and macOS version are available on their website https://prose.org/downloads and it's all open source so if you want to use their server to have some extra pod-logic, you can just follow their instructions on the git (it's probably also on docker hub)
Thanks for the link.
@pixelschubsi
> What do you mean with ready to test?
At the top of their website front page it says;
"Prose is almost ready"
At the bottom it says;
"Join the waitlist"
Both those messages are much more prominent than the tiny download link hidden right at the bottom, or tucked away in a non-obvious hamburger menu.
I also had a brief look at their code forge but saw nothing offering ready-to-use releases there.
So it wasn't obvious there were any releases to test.
@pixelschubsi
I don't have a Mac so I tried to test the Prose web app. It seems like it can only be used with an account on Prose's server? Do you know how I can get a Prose account?
@strypey Double ratchet E2EE in XMPP via OMEMO was introduced in summer 2015. The first version of Conversations shipping it to endusers was 1.6.0 in August 2015. The initial beta release of Element (back then called Vector) was July 2016.
@pixelschubsi
> Double ratchet E2EE in XMPP via OMEMO was introduced in summer 2015
Comment from Bugzilla from 2017;
"OMEMO is now based on the OLM Protocol instead of the Signal Protocol"
https://bugzilla.mozilla.org/show_bug.cgi?id=1237416#c1
OLM, of course, is the E2EE protocol in Matrix. AFAIK the work to allow for E2EE of MUC chat rooms was based on MegOLM.
@strypey server side long-term archiving of double ratchet encrypted messages is not really a feature, no. Double ratchet means: as soon as a client has decrypted the message once, they won't be able to decrypt it another time. And only the clients that were part of the chat when the message was sent are able to decrypt it. So once all clients have received and decrypted a message, it's completely safe to get rid of the archive.
@pixelschubsi
> Double ratchet means: as soon as a client has decrypted the message once, they won't be able to decrypt it another time
This is not what DoubleRatchet means in the context of the Signal protocol and its derivatives. You seem to be getting confused between encrypted messages and vanishing messages.
BTW this habit of dictating to users what we do and don't want as a feature, rather than listening to what we say we want, is a big part of why XMPP remains niche.
@strypey I'm not sure how you define the difference of public and private rooms, but in XMPP, their archiving works exactly the same. And yes, they do have archiving, just not with infinite backlog and duplicated to servers that don't want to store a duplicate. In XMPP, it's on the server to decide which messages to archive and which not to archive. That holds for public and private rooms and direct messages in the same way.
@pixelschubsi
> I'm not sure how you define the difference of public and private rooms
Messages in private rooms are visible only to the people in them. This seems like a basic and obvious distinction to me.
> their archiving works exactly the same
If you think that, then like most Jabber fanboys, you don't really understand how Matrix works and don't care to learn.
@strypey Most servers use the following configuration:
- Messages in public and private rooms are archived on a single server (the one hosting the room id) and all others don't archive these messages by default.
- Anonymous room whispers (matrix doesn't have those) even though they use the room id are typically archived not on the room but on the sender's and recipients'
- Messages to rooms that don't have a room id (client-managed rooms) are archived on the sender's and recipients' server
@strypey But then, as I said, you can change your server to also store the messages of rooms with room id where your clients are a member. All major clients support this and will be fine to fetch those messages from their home server's archive instead of the archive of the server hosting the room id.
@pixelschubsi
> they do have archiving, just not with infinite backlog and duplicated to servers that don't want to store a duplicate
Exactly! XMPP archiving doesn't have the same storage resilience. Nor the same ability to allow to login to a new app, cross-sign, and then access any any message from any room your account is in. Whether or not the homeserver hosting your account stores a full copy of all room histories or not.
Rooms are first class ctizens in Matrix, not janky bolt-ons.
@strypey Just like every XMPP client, it works with every fully compliant server. I don't think there are even accounts on prose.org and that's only meant as a placeholder. Which server did you try to use?
@pixelschubsi
> Which server did you try to use?
Jabber.org. I've been using the network since the pre-XMPP days, when it was just Jabber.
@strypey OMEMO is not and never was based on Olm. There was a copyright/trademark issue with Signal so it wasn't allowed to say that OMEMO is derived from Signal protocol anymore and instead some people said it's derived from Olm (which itself is derived from Signal protocol, so this was technically not completely untrue). Nonetheless, all implementations of OMEMO at the time and still most today use Signal's libraries and not libolm. Using libolm would actually be incompatible.
@pixelschubsi
> OMEMO is not and never was based on Olm
I consider this quite unlikely, but let's say it's true. XMPP had existed for about 15 years when someone suddenly decided it needed E2EE. Why? Was it just the desire to compete with Signal?
Or the fact that from 2014, if not earlier, people at AmDocs were building a room-centred protocol for federated chat networks, with E2EE as a standard feature? And talking about making it a new open standard for chat.
@strypey I meant that public and private rooms in XMPP work the same, not that XMPP and Matrix work the same. As you can easily see from my previous messages, I'm well aware of how Matrix works. And as I'm in fact developing a commercial secure messaging platform for work (neither XMPP nor Matrix) I actually do understand the protocols (including their e2ee properties) pretty well, as doing so is part of my job.
@pixelschubsi
> As you can easily see from my previous messages, I'm well aware of how Matrix works
You'd really like to think so, but even as a power user, not a software or protocol developers, I can see it's not the case. You can't understand a protocol function if you can't understand the usefulness of the features it allows for.
And you can't, because you're mental model of desirable features is clearly defined by what XMPP can do, not what people wanting chat services actually need.
@strypey Well, it's a company, they're talking about their commercial offering coming soon and they're obviously not loudly telling everyone "please use our stuff without paying" before they are ready to sell it.
@pixelschubsi @strypey Meh. I used to be excited about Prose too, but the two guys that started it do it in their spare time cuz they run a big AI chat startup. I'm not too hopeful to see much delivered on the Prose side, unfortunately.
So is the problem the protocol, or the implementation?
- replies
- 0
- announces
- 0
- likes
- 1
@strypey In our perception, a lot are on Telegram. OCA community UBports. Both are the main projects which are supported by us.
@os_sci
> In our perception, a lot are on Telegram
Well, as with social media, the fragmentation of chat networks remains a problem to solved. I had high hopes that we'd get a lot of the interop work done by the EU enforcing DMA, and the US DOJ doing antitrust enforcement against the same DataFarm.
The erection of Orange Stalin as US President, with the backing of DataFarmers like Husk and Bozos might slow that down. But they're on the wrong side of history and public sentiment.
@mmu_man
> "open core" is the wrong term, should be called "proprietary shell"
Makes sense. FWIW ...
"...the phrase 'Open Core' has apparently become a slur word, used by those who wish to discredit the position of someone else without presenting facts. I've done my best when using the term to also give facts that backed up the claim, but even so, I finally abandoned the term back in November 2010, and I hope you will too."
@BradleyMKuhn, 2011