That's… not true? https://ourworldindata.org/grapher/per-capita-electricity-fossil-nuclear-renewables?facet=none&country=CHN~USA
So if we put aside the fact that some amount of GHG must be emitted to lift a country out of poverty, you are saying that you would put blame on lobbyists rather than on corrupt politicians? ...
Interesting. Were the apps/features installed comparable between the OC and NC instances? I can't even find an "email" equivalent app for owncloud from their marketplace.I don't want to sound like I'm coming in defence of NC, but I'd be curious to find an as factual as possible comparison between "bare-bones NC" vs "bare-bones OC".
Matrix problems become unmanageable at scale, but the effects of the underlying complexity can be felt long before: https://telegra.ph/why-not-matrix-08-07
If you read between the lines, Matrix 2 is practically about handing the client state over to the server (what they refer to as "sliding sync"). Realistically, this is an admission that the protocol is too complex to be handled efficiently on the user's devices. I'm not saying there are not clear benefits (and new trade-offs) to the approach, just that in the grand scheme of things the complexity is shifted elsewhere (and admins foot a larger bill).
Yup, like pretty much everyone else :) https://nlnet.nl/project/XMPP-MLS/
Please, don't recommend pidgin, it's a security hellhole, and a pretty terrible XMPP client at that. If you want something with a similar vibe, check-out https://dino.im/ or https://gajim.org/ if you are more on the "power-user" side of things :)
I assessed XMPP vs Matrix about 8 years ago, and strikingly, the basis on which it didn't make the cut still applies today. Here's what I responded to a sibling post: https://programming.dev/comment/5408356
In short, Matrix dug themselves into a complexity pit with an inadequate protocol, survived for a while on venture capital money (upscaling servers and marketing at all cost), all of it dried up, and now they are in financial trouble. Matrix won't disappear overnight, but is definitely losing the means to run the managed instances and the client/server ecosystem.
Neither XMPP nor Matrix will ever become “the next WhatsApp”: the current internet has seen too much consolidation for the tech majors to permit it (and open and federated protocols can’t compete, do not have the marketing budget nor the platforms to promote their software, but I salute the EU’s Market Act attempt to shake-up the status quo).
But that doesn’t really matter IMO. What (I believe) is important in the grand scheme of things is that such protocols remain alive, maintained and secure, so that:
small-scale instances can flourish and contribute to a more resilient/efficient internet (think of family-/district-level providers ; this is the kind of service I personally offer: family members and friends at large appreciate that the messages and data that we exchange aren’t shared over some cloud or facebook server for no good reason)
IM identities can persist over time: if you are a business or an individual, you may want to look into having a stable/lasting contact address, that will survive the inevitable collapse of facebook/whatsapp/instagram/… If you are old enough, your current email address probably existed before facebook. Why not your IM address?
And yes, I hear you, this is rather niche, but what got me there (and on XMPP in particular) is having been long-enough on the internet to become tired of the never-ending cycle of migrations from service to service. More and more people will have a similar experience as time goes, so this niche will only grow :)
Edit: Sorry, I responded to the wrong parent.
I don't believe Matrix is better positioned than XMPP to succeed. On a technical aspect, Matrix hasn't managed to stabilize its protocol, and they've been a decade into it. This has resulted in only a single organization being in charge of the protocol, the client and the server implementations. This isn't sound, this isn't sustainable. And now, unsurprisingly, this organization is in a financial crisis, has lost important customers, has no budget secured to maintain its staff in the next years, and recently underwent a major licensing change that we can only interpret as a shift towards an opencore model at the detriment of the regular user.
The thing is that I have experience with other complex or high usage PHP applications and I know how to optimize things. What I see in NC is poorly structured code, warnings and erros thrown around left and right.
Well, on my instance, logs are pretty quiet and I am not a PHP developer to form an opinion on the overall architecture. But if you take the time to write down what you feel is wrong with the nextcloud codebase, I'm pretty sure many people (and me first) will read it with interest and perhaps even do something about it (typically the kind of "HN frontpage" content, if it's well written).
The OP also said that ownCloud gave him a much better experience out of the box, and that’s still a “complex” PHP application.
Last I heard of ownCloud, people were saying that it had been rewritten in go or something similar. Funny bit of history, nextcloud forked off of owncloud, got a ton of mindshare in the early days, and quickly became the better/faster of the two (perf was one compelling reason for me to migrate back then). I wouldn't mind NC following suit (in the end, we benefit from this type of competition).
NC webmail is unusable
I don't plan on ever using it, but thanks for the heads-up. That said, if you feel that roundcube performs better, it happens that someone has packaged it for NC, so you should be able to use that instead of the troublemaking client.
Yup, that's a big reason why centralized protocols aren't sustainable. XMPP is 25 years old (which is older than almost anything else on the contemporary internet) and thriving. Unfortunately, judging by the cycle of messengers coming and dying, and people still being eagerly part of that, this isn't something that people value very much.
If you are curious, you should give XMPP a shot, it's equivalent to Signal in terms of encryption, but anyone can host their own. Signal is ideologically opposed to anyone but themselves being in control of your account, and because of that I don't want to trust them.
Yeah sure. I’m not the only complaining as you can read on this post
I'm not saying that you are the only one complaining, but from what I can tell, most people in your situation are deploying their instance from "cookie-cutter" docker images. In practice, it often means that the same machine end-up hosting multiple web servers, database servers, application servers, etc etc. And those servers are developed around heavily-optimized event loops that assume direct access to the full server resources. So if you want predictable and good performance, there's no way around tweaking some knobs and be very mindful of how each and every service is deployed alongside the next one. And of course, you can't trust someone else to know better than yourself what's running in your box (not even the nextcloud developers) and which service should get preference over what under heavy load.
Nextcloud has that against itself that it uses advanced php features and large objects that need to be cached at different layers. That makes it a slightly more complex app than your go-to php CRM, but it's not unheard of either (you'd be at the same spot hosting a large mediawiki or wordpress).
Does that make it garbage? Well, you are entitled to your own opinion, of course.
Also your comment tells me that you’re full of shit, because you’re implying that both a generic Docker setup and mines are all shit. You can’t have it both ways. What are you suggesting? That the NC guys made a bad job out in their Docker images?
Do I deserve the insult? I answered the docker part, though. In general, I'd say that you are better-off not using docker in PROD , unless you have the time and energy to spend rebuilding images to make them fit your pre-existing deployment (what nobody does), and then invest the time in fine-tuning through multiple containers (which very much goes against the "fire and forget" mindset of most docker users).
How many users? How much data?
About a dozen, 2TB, upwards 700k files
Btw do you use the webmail at all or are you about to tell me that these screenshots are hallucinations?
I'm definitely not using the webmail. If you have performance issues, you should rather start with just the "core" (i.e. files) and add on incrementally.
And again, I'm not saying that nextcloud doesn't deserve being optimized, or somehow be made more foolprof. I too went through a phase of "that can't be real, this cannot be that slow" and walked my way out of it.
That might tell us more about how badly your php process manager and/or db connection handler is set up, seriously. I run nextcloud "natively" (no docker, no nonsense) on hardware that was modest 15y ago (Intel Atom/2GB RAM), and it's pretty good.
How isn't that even better, then? Those countries set a bar for themselves, no matter what China decides to do
- JumpDeleted
Permanently Deleted
tout dépend de ce qu'on entend par "thread"
s'il s'agit de messages qui font référence à d'autres messages, avec un client qui sait remonter l'historique pour remettre le message cité en contexte, alors beaucoup le supportent (dino, movim, en cours de dev dans Conversations, …)
s'il s'agit de marquer/grouper/filtrer des messages appartenant à un même fil de discussion, je pense que le plus avancé est Cheogram: https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8 .
L'utilisation de threads est assez peu courante aujourd'hui dans le monde XMPP, même si beaucoup de clients plus ou moins expérimentaux s'y étaient essayés il y a une dizaine d'années (Google Wave en était un fameux…). Mon avis est que les implémentations dans les autres protocoles sont assez peu convaincantes car requièrent beaucoup de discipline (zulip), ou génèrent beaucoup de bruit (slack, …), du coup je serais curieux de voir ce que tu considères comme étant un "bon client" de ce point de vue :)
- JumpDeleted
Permanently Deleted
Effectivement, il n'y a pas de solution idéale.
Je pense qu'au vu de l'existence même de XMPP et en particulier de son progrès de ces dernières années, Matrix est une solution en recherche d'un problème, mais cet avis n'engage que moi (et les quelques centaines d'utilisateurs que j'y héberge).
- JumpDeleted
Permanently Deleted
Objectivement, à 10 ans, Matrix n'est toujours pas mature et peine à stabiliser son protocole. Et le mot circule que l'État français aurait arrêté de payer pour son support.
Après j'ai pas l'impression que olvid soit franchement mieux : la partie serveur n'est pas à sources ouvertes, et il s'agit d'un énième système centralisé où, peu importe le modèle de sécurité, chaque compte est tributaire d'une entité dont on ne peut qu'espérer (mais jamais garantir) qu'elle a à cœur les intérêts de ses utilisateurs (même problème que Signal).
We've yet to see it materialize in numbers (fingers crossed). So far we are mostly observing a significant decrease in economic activity, which China has made a habit to compensate with large scale infrastructure projects and dumping (e.g. steel), which are inherently large GHG emitters, irrespective of how much renewable electricity is produced.
Also, China seems very far from reaching the inflexion point where domestic consumption-based emissions stabilize: https://ourworldindata.org/grapher/production-vs-consumption-co2-emissions . This graph also answers how much CO₂ outsourcing actually happens here (i.e. territorial emissions minus consumption-related emissions), which isn't much at all.