All the immutable system solutions out there pretty much all make your rootfs immutable, but leave your home folder and system config folders (i.e. /var and /etc) as mutable. It's pretty obvious that if you make the config folders and/or home folder immutable it starts causing most people problems, since in the vast majority of cases people just want to be able to persistently change the desktop background color or spaces vs tabs setting in their IDE without having to locate the setting in a full system config, set it, and regenerate.
This does cause some interesting tension in the immutability though. /etc in particular is really a mix of things that a sysadmin should really only be setting, and things a regular user may set indirectly. This usage has grown organically over time with the tools involved in the implementation, so it's not at all consistent which are which. The immutable system solutions recognize this by usually handling the whole /etc folder the same way package managers handle package installs that include /etc file: by doing a 3-way merge between the old provided files, the new provided files, and the current existing files to see if the existing are unchanged from the old provided and can just be directly replaced by the new provided or if a merge conflict needs resolving. Additionally, a separate copy of /etc is maintained associated with each available bootable system version so when you roll back you get the old /etc files you had before. Though this does introduce a system-unique variation since you now have new /etc being affected by the state of /etc when it was forked.
If you want all your home folder and system config to be identical, nix or guix really are your primary way to go, that extra lockdown of the user and system config is exactly what most people don't want for usability reasons.
I personally use nix home-manager on top of Aurora DX from Universal Blue. I have my nix home-manager config setup to manage only the things I want to be locked down in my home config, and to provide some extra tools that are easier to manage/supply via Nix than a system package manager (where I would need to do a whole system update to get the new version). My IDE for example is installed on a specific version via Nix, but I don't have Nix manage the settings of it so I can separately tweak as needed without need a home-manager rebuild.
sysexts are indeed a very interesting feature, though it really only complements some other whole-system solution since it can only affect files under a non-root folder location.
I'm struggling to see how sysupdate is really equivalent to bootc or ostree though. Sysupdate is just the sw-update tool from Yocto that's been around for 10+ years with a little more syntax sugar, which itself was just a common shared implementation of what all embedded systems had been rolling-thier-own of for almost 20 years before that. It says it requires an A/B/.../N partitioning scheme, which is exactly what bootc/ostree/etc is designing to avoid.
If you don't use the whole disks update thing from sysupdate, then instead you're just talking about a transactional package manager that is still in its infancy and hasn't addressed the many gotcha and corner cases that the dozens of more mature package managers have. It's not actually "transactional" in the sense of undo for example, it's "transactional" only in that you won't get partial install, which hasn't been a problem with any existing package managers for almost 40 years. All thier listed things you can list together for a "transaction" association are either things that are already linked via existing package maager packages, or are only useful for embedded systems.
I'm not saying sysupdate isn't useful, upper end of embedded design is pushing into the space where systemd is standard now so it could be useful for those devices, but it's not really equivalent at all to bootc/ostree, and doesn't really have amt applicability outside initial system imaging from a live disk, or embedded devices.
Ironically the first implementation of ostree required an HTTPS server to serve the ostree commits, allowing a much smaller subset of what's needed to be transferred. However that became an adoption hurdle since it required unique infrastructure.
Ostree switched to using containers because zstd allows compressed chunks now rather than the old all-or-nothing image layers, and the existing widespread container image registry infrastructure could be reused without modification. And both utilize layers for their construction so there were possible benefits there (that never really materialized, but are still available to pursue).
yea it switched to a in general much better distribution method then custom https server, for one thing authentication is built in something many of these https solutions forget(look at every linux package manager)
That is pretty obviously how it started, and for the very reasons you describe. But there have been some other benefits that have come out of going down this alternate path as well.
In particular, the remote composability and local deployment is extremely useful for "cattle" edge system deployment. Installing a package reacts to what's currently on the system when installing. Even something as simple as the order you install your packages in can affect the result. Not having to run an entirely duplicate "golden" system to generate snapshots on and then push them to the cattle from is a pretty nifty benefit.
> In particular, the remote composability and local deployment is extremely useful for "cattle" edge system deployment.
A legitimate point, but I feel that there must be better, cleaner, simpler, more elegant ways of doing this.
I mean, Nix does this and it's clean in its way, but the price is, a filesystem layout that is not navigable or maintainable by humans. IMHO and that of many people, that's a price too high, but it shows that there are alternative routes.
CoreOS is in a weird space. It's been desperately playing catch up with it's sibling products for the last few years, but it also is where a lot of the Fedora/RHEL developers in this space are focused primarily.
In fact, if you want to use something like Nix on a UniversalBlue system, you have to spin your own. The "hotfix" and chattr solutions of pre-composefs don't work anymore.
Anything that needs to go into a read only location and isn't package as an RPM requires you to "spin your own".
Luckily UniversalBlue makes it incredibly easy, they have a template repo you can use that has all the GitHub action setup included to auto-bills on every change, and directions for how to set it up. It took me about 10 minutes
Someone mentioned (I believe?) after talking to Element/Matrix at FOSSDEM this year that the organization has been struggling a lot to get this going. Apparently issues with thier project organization forking and funding the last few years has made one of thier primary contributors, who already had fully functional and working video/voice, all but give up on the project because the upstream forming means it's now forked from a commercial/defunct version of the original code(?)
This has been brought up on HN before, and people smarter than me identified that this view is about 10 years out of date.
Yes it's a bunch of XEPs, but there are standardized "sets" apparently that include all of the things any other similar tools do. It sounds like only very niche old/minimal XMPP clients don't support encryption by default for example, and virtually all servers have supported it for many years.
Is there a recommended or "blessed" server and client combo for someone who just wants to migrate their friends off discord?
The main site https://xmpp.org/software/ lists lots of different options but I have no idea what core/advanced means and comparing all of these would take ages.
The ironic part is that those software description files are meaningless. AstraChat claims Advanced in all categories, but it's a proprietary commercial software, so nobody ran any kind of test suite to verify this.
That software list, how it's done and how it's ranked is literally confirming my initial point of critique :D
Last time I tried out several chat clients, most of them were alpha software, had lots of bugs appearing in normal conversation flows, well, or were so broken that they broke compatibility in subminor version updates to their very same client apps.
I just wish there was some kind of ACID test suite for XMPP or something else to reproducibly validate spec compliance. Maybe a test server or similar as a reference implementation. This way client or server maintainers would have to run their programs against the official test server to increase their compliance stats.
> I just wish there was some kind of ACID test suite for XMPP or something else to reproducibly validate spec compliance. Maybe a test server or similar as a reference implementation. This way client or server maintainers would have to run their programs against the official test server to increase their compliance stats.
This is exactly what the Compliance Suits are for, and the XMPP Software Fundation is taking care of telling all the clients what they misses directly on the official website, for example: https://xmpp.org/software/movim/
There is the XMPP Compliance Tester[0] by the author of Conversations. It does a good job at testing servers. On the client side I'm not aware of any kind of benchmark.
Because the declaration file of the clients says that it is actually compatible with everything in this section.
You can't run scripts on all the XEPs declared, some of them are purely redaction or bound to specific UI/UX behaviors. This is based on trust that the developers actually implemented things as stated.
Not being able to automate something is not the same as not being able to verify at all. It sounds like the parent commenter is arguing that at least some of the clients listed are not worthy of this trust because (either intentionally or due to developer error) they don't actually hold up to scrutiny. Obviously they're just one person and their opinion might not be representative but it's hard to argue that if some random user is expected to have enough time to try out various clients and figure out which ones work or don't that the official people in charge of making the recommendations of clients should probably be able to find the time to as well even if it's just a volunteer that they, well, you know...trust.
Hasn't social media like HN, Reddit, fediverse, etc. become the real clearinghouse of information about those sorts of questions? I can see how it would be nice for xmpp.org to be an authoritative source of truth, but user response/consensus seems more relevant these days, at least to me.
The targeted audience of this website is, for now, developers. Communicating is hard.
https://joinjabber.org/ is/was an attempt at something more user-focused. It is not linked to the XMPP Software Foundation. BTW, joining the XSF and participating in discussion around protocol evolution, communication strategy and these sort of things is free, and only requires asking for write permission on the XSF wiki to add an application page. Everything happens in the open (mailing lists, chat rooms). We value democratic processes.
>Is there a recommended or "blessed" server and client
Not sure about servers, but for clients there's Gajim, Dino, and Conversations. Not much else is super relevant these days. Profanity exists but is significantly worse than irssi or weechat despite looking superficially similar. Kaidan is a KDE/Qt alternative to Gajim but I'm not sure if it's usable yet. It may be worth switching when it's fleshed out to escape the bugs and slowness of the GTK-based clients.
If you stick with mobile use, there is Snikket[0], which provides a branded server+mobile app ecosystem that should "just work". YMMV; I haven't tried it myself.
The developer is very active in updating and maintaining the software (both client and server), and it already supports most of the XEPs.
It's open source and fully supports self-hosted as first class, but if you want to support the developer he offers a cloud hosting paid offering as well. There's a crossover offer with JMP.chat too. If you pay $5 upfront for your first month of JMP.chat, you can get a free cloud hosted Snikket server for it to be setup on. As long as you maintain at least one number with JMP.chat, you keep the server maintained. If you don't, you get a chance to migrate your data. The Snikket cloud server gives you an XMPP server admin account, and you can setup as many accounts as you want. The caveat is that Snikket implementation is optimized for <1000s of user accounts per server.
Monocles chat is best one for Android, it is the most complete chatting app for todays standards, unlike Conversations it has swipe to reply, last seen, emoji reactions etc. The only issue is making account there, need to use other homeserver like @conversations.im if you don't want to pay for their @monocles.eu .
For IOS the only option is Monal.
For web I find conversejs better than mov.im as movim doesn't encrypt sent pictures in chat at all, and encryption of text messages is sometimes broken depending on how you set it up in settings of account and in chat, as it needs to be activated on both places, so conversejs is better, but less enjoyable UI than movim
Basically you need a server, which you host, pay someone else to host for you, or you join am existing server someone else hosts.
Then you find a client. There are a ton of clients around, but it's like picking a browser before Chrome ate the world. Tons of options and everyone has thier own opinions and information about them.
Conversations is a great Android client (also brings their own backend instance if you don't want to host your own), I don't know about iOS or server though.
It's overwhelmingly more of an outsider talking point than an actual issue in practice. There's a category of people that just says any extensible protocol must fundamentally have massive amounts of incompatibility, and brings it up every chance they can... and while that is technically always possible, it only happens in practice if clients diverge greatly. XMPP clients mostly work together much better than Matrix clients, from what I've experienced, as long as they've been actively developed at some point in the last decade. Which is by far most clients in use.
For Matrix clients I'm given to understand the issue is the lack of XEP equivalents. Either your server(s) and clients are all on the latest available version or you're SOL.
This makes third party clients effectively impossible since every change is basically a breaking change and the client and server are tightly coupled.
XMPP took it a step further and has feature segmentation by defining XEPs. This is basic minimum for defining an extensible protocol for client-server communication and has been for decades (maybe it was a new idea when XMPP first started). Notably, browsers use this same thing with w3c specs, which is why they keep working too. If you don't have this feature segmentation and negotiation, you don't have a functional open source client-server protocol full-stop (looking at you Matrix).
I think what XMPP has gotten better at is doing like with w3c and setting baseline minimum features, which has allowed more standardization of clients.
Don't get me wrong, I have been hearing about XMPP forever, and I would love to have an opportunity to try it. Unfortunately it hasn't happened. I have been forced to use Slack, Discord, I have had opportunities to try Matrix, Zulip, of course I have been using IRC for a long time. But XMPP? I may have installed an app, but I haven't had an opportunity to actually use it. Is there a list of communities there?
Then about it being confusing: you're right, that's an outsider point. Because I haven't been able to try it (again nobody ever told me "oh, this project is on XMPP, you can go ask your question with this app/website"), but I have been genuinely interested in it, I ended up on the official pages.
- Check the RFC list: https://xmpp.org/rfcs/#6120. The first one is more than 200 pages, the second more than 100. There are 5 "basic RFCs" and 19 "further RFCs" (whatever "further" is supposed to mean). There is no way I will even open them all. Conclusion: I have no idea how XMPP works, except that there is XML in the mix and a whole bunch of stuff around.
- There is a "technical overview" here: https://xmpp.org/about/technology-overview/. I invite you to have a look at it. Apart from the fact that it seems to use "XMPP" and "Jabber" interchangeably (I think? I'm confused), it kind of loses me at "Jingle", which seems to be a "multimedia specification" (does that mean it's for video?), and has a bunch of implementations, like "pidgin". Isn't pidgin an XMPP client? Here it's under the Jingle section. And then there are extensions, with a whole section just for "Multi User Chats": so the default is that there are no groups, and if my client supports this extension and the server supports it, then I can join a group? I gave up at "PubSub", I did not even read anything from "BOSH".
As a person who wrote his own IRC client, contributed to Signal and looked into the Matrix protocol (which seems more complex than I am comfortable with), I must say that XMPP is in its very own league.
My conclusion with Matrix was that nobody would ever want to write it from scratch, so there has to be some kind of `libmatrix` on top of which people could build. Seems hard in practice because it feels like it keeps changing.
I don't know how fast XMPP is moving, but I would hope that it is now stable. Is there a libxmpp that contains all the necessary features to write a client? Not clear to me. It feels like it's still a complex ecosystem where it depends on the client, and on the server, and on what you want to do.
> XMPP clients mostly work together much better than Matrix clients, from what I've experienced
I can only take your word on it: I don't know a community that is on XMPP, so I haven't had a chance to try. Matrix has been frustrating, that I can say.
XMPP has had less allure as "the new thing" since it's been around for a very long time. It was _the_ chat protocol in the 2000s when it started, and all chat apps used it (when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated). Vendor lock in started taking off not long after though, so Facebook Messenger (also originally XMPP) stopped interoperating and went fully closed along with a number of others, and the ones that interoperated didn't shift business models and disappeared.
None of that means there's anything wrong with XMPP, it just means it's not in the public mind.
IRC has been getting the retro nostalgia kick start, and it briefly came back to attention when Slack started as "wrapper" of IRC. In my experience IRC channels are used by about 50% of open source projects, even though it's abysmal for access on mobile devices, very unfriendly for users, and extremely limited in functionality. About 50% of those have a bridge to Matrix so the mobile access is at least somewhat solved, and there are some more usable client options.
It seems because you haven't seen people already adopt it, you believe it must not be good. I'd encourage some basic research for your own benefit so you can see how XMPP is way easier to setup and maintain, far more efficient, and more capable than the oddly more commonly used Matrix/Element. In fact, between the organization issues of the last couple years, everyone finally getting fed up with Matrix being brittle, unmaintainable, and extremely inefficient to run on a server, I would expect Matrix support channels to drop off very rapidly over the next few years.
> It seems because you haven't seen people already adopt it, you believe it must not be good.
On the contrary, I have been hearing about it for so long, I believe there must be something there.
But maybe there is something fundamental in the fact that because it is actually interoperable, it's a lot harder for it to get traction. If a client gets a lot of traction, it probably quickly gets tempted to leave the interop world and do whatever they want (and lock the users in). In other words, XMPP sounds like a success story of diversity, but the cost of that is that normies don't even know what it is. Similar to Linux in a way: if someone gets interested in Linux, the next thing they see is a gazillion different distros and people arguing about them (disclaimer: I have been a Linux user for 15 years).
Matrix is different in the sense that it does not look like a success in terms of diversity. Matrix is pretty much Element. And Matrix seems to be about converting everybody to Matrix: I have seen bridges to IRC that made the IRC experience so bad that people would move to Matrix. Not because Matrix was necessarily better, but because Matrix was killing the IRC experience.
In a way, I find it interesting that those "interoperable protocols" (both Matrix and XMPP) are all for diversity, as long as it is their protocol. XMPP wrote a blog post about the EU Digital Markets Act, saying something along the lines of "the DMA is a good idea, the only thing that they miss is that they should force everybody to use our protocol, XMPP". Matrix has a similar stance: "we don't consider it interoperability if we can't make it work with our protocol, no matter how much we destroy the experience on the other platform". Because the end goal is not really interoperability: it's interoperability under their conditions.
> when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated
Sorry to remind you, but this never happened. AIM and ICQ eventually interoperate because they were owned by the same company at that point. There was never XMPP federation in the mix here.
Yea, it was really only ever "libpurple let you easily use them all in one app nearly transparently, and many people did". Many did use XMPP under the hood, but afaik almost literally none federated.
Matrix is seemingly trying to leverage that memory, but "there's a bridge bot somewhere that you can run somehow, with extremely widely varying quality / integration smoothness" is rather different.
Pidgin is a universal client that supports many protocols/networks including IRC, XMPP, and has additional third party plugins from stuff like Discord and Slack.
I don't disagree, but whether you're even aware of the XEPs and how it's presented to the user, is a critical factor in viewing it as "confusing".
Gaim for example only even tells you about XEPs if you dig into the server settings, and then it shows a very good job of listing all XEPs from either the server or client and noting which are supported by each in a table if you're far enough down the rabbithole that this info is useful. But for a regular user they just log in and it Just Works (tm).
Yes I agree, apps should never mentioned XEPs. Most devs have no reason to even know about them, why would a user case? Some apps are built by protocol nerds and they like seeing the list. Maybe very hidden is ok but in general not something any user cares about.
How would devs not have to know about them? Say I want to write an XMPP-enabled app, how do I do it? Are there XMPP libraries that already implement all the required need protocols?
Ironically, Signal actually ranks a -1 for privacy in this use.
Presumably you're already using Signal and getting mainstream contacts to start using it too. You probably have a basic profile that at least includes your real name, and might also have your picture. Maybe you're even one of the 7 people in the world that use the Stories feature in it. Well good news, now all of that is also unconditionally available to anyone in any group you ever join, including any future changes you ever make to that info, unrevocably forever into the future.
Signal has a fun dark pattern where it unrevocably grants permissions for anyone you allow to contact you to see everything in your profile for the rest of time. It has only a single trust level with contacts effectively: full trust.
This is unacceptable in any tool you use for online community, unless you exclusively use it for online community and can decline to provide any info in this full-trust level. Unfortunately Signal also makes very sure you can't have a second account, by tying your account to a phone number, and only allowing one Signal instance per mobile device.
Is Signal good? Yes, but only exclusively for communication with people you already trust.
Keep an eye on Whitenoise. It's basically taken the technology behind Signal and placed it atop Nostr, so rather than signing up with a phone number, you do it with an npub (pubkey). Still in very early days so the features aren't all there yet, and battery use could be better, but they've got the basics of it working already.
SimpleX is another option.
These don't have discoverability for lay people users just joining though, which is actually a huge network effect positive for Signal in the family and friends use cases.
However it avoids the issues with the public group chat privacy. It ends up coming down to client and protocol features for those. SimpleX has a more extreme privacy threat model than Whitenoise so user contacts tend to be throw away (for good or bad), which generally doesn't work for public communities.
The real kicker is that almost nothing has the community automation tools and administration of Discord which is the really hard lift.
I have lots of Signal contacts I cannot phone, since the phone number is never shared by default. Not even the signal contact is shareable. It is way too privacy focused to work easily.
i.e. I cannot even match two people I have in contacts unless one of them sends me their hidden username. Then they can talk to one another.
And people in my contacts don't use their full name. In groups, they often share the first name, making it confusing as hell. And many use an arbitrary nickname, most often the abbreviated first name I think but sometimes truly random stuff, and might even change that yearly with no mapping in my history to tell me who they were.
I, and all of my contacts, have the default setting for this which makes me discoverable on Signal by phone number look up, but I have phone number sharing disabled. That's the default settings.
I've had no issues at all with discovery.
Signal has had the ability to share a username instead of phone number for a while. You definitely want to pair that with not sharing your phone number with Signal contacts (the related option released at the same time).
You can have multiple instances of signal on a mobile device, and you can use VoiP or eSIMs to register. Signal with an online persona revealing no identifying information, registered to a cash purchased eSIM on an ungoogled android is as good as your getting. Why do you think so many jurisdictions are trying to ban both GrapheneOS and Signal.
To be clear, your linked map shows that it is not a blanket "in europe". Around 20 European countries don't need an ID to get a SIM card and 30 do.
For those learning about political nuance against the backdrop of current propaganda, it is worth noting that the UK and Ireland do not require registration and that the populous are significantly politically opposed to it; and then Russia requires registration and has one of the most linked up registrations.
And what happens when the next guy buys that same number and registers on Signal?
Phone numbers are recurring costs. And to keep a truly private one you must keep paying without ever disclosing personal info and that is really hard. Signal is a privacy nightmare for long term use.
There is a week long registration lock protected by a PIN. Your contact list is protected by that PIN as well. They cannot access your chats. All your contacts will get a notification that the contact has changed when they go to talk to your phone number or get a message from your number.
This is good and means no one can impersonate you using your phone number, but doesn't solve the recurring costs issue, you still need to buy a new number when someone registers yours, and every financial transaction puts you at more privacy risk. And is terrible UX, imagine having to add your contacts new numbers every other week.
People generally already have phone numbers. In the markets Signal is targeting its rare for people to not already have a phone number. It would be quite strange for someone to be paying for a phone number just to use Signal, and if you don't already have one then yes I'd suggest Signal isn't the choice for you.
Not only that, but its a unique identifier people generally have already had and generally have already shared and historically been OK with sharing with people they want to talk to. That's a part of the reason why Signal originally chose that way of finding contacts, people were already connected in that way. It makes on boarding people massively easier and greatly reduces the friction of people actually using it. A messaging platform is pretty useless if I can't easily find my friends on it.
> And is terrible UX, imagine having to add your contacts new numbers every other week
Practically nobody is getting a new phone number every other week. And once again, if you are the kind of person getting a new phone number every other week, I'd agree Signal probably isn't the platform for you.
If you don't have a phone number or your number changes all the time, I agree Signal isn't the choice for you. If you already have a phone number, are OK with what having a phone number means in terms of privacy, and that phone number is pretty stable, then Signal isn't a bad choice to use to message on.
It does mean theoretically some large organization (like a government with a warrant) can potentially see "John Doe has this phone number, this phone number is related to Signal, therefore John Doe possibly uses Signal", but personally I'm not too worried about that tiny bit of information leakage. Besides, with enough effort one could probably ID that looking at internet traffic patterns unless you're really that paranoid about controlling your network routing. Especially when that means I'm able to actually convince family to use the platform, as they're used to just looking up people by phone numbers and don't want to have to deal with managing yet another unique identifier on yet another platform. If they had to register another account and manage yet another identity, they wouldn't use it, and thus I'd be stuck just talking SMS with them which results in worse privacy outcomes for our conversations.
Getting and maintaining an active phone number privately is indeed quite hard, partially by governmental design.
Signal only requires occasional/rare proof of control of the registered phone number. It also has very little visible data the provider can access on your account, even if they had a reason to assist in breaking your privacy by look it up from the phone number. Without Signal foundation direct support, the phone number linkage to your Signal account is completely opt in by you only.
So in terms of privacy, Signal is actually very good about the phone number and leaves it mostly to you how public you want to be about it.
They're primarily using it as a finite controlled resource to limit how easy it is for people to spin up arbitrary new accounts. Other projects might use some cryptocurrency junk that effectively equates to paying for accounts, but Signal uses what you probably already have.
Which is very backwards/nannystateish, same nonsense in AU. Thankfully anyone can buy one anonymously in the US and just use that even if it's more expensive.
You can do all of that but you shouldn't have to when using a privacy-focused messenger, and most people won't so they'll be exposed and suffer the consequences if they use Signal expecting a certain level of privacy (and pseudo-anonymity).
It's a terrible anti-feature and the only reason they're not being punished for it is because there aren't many alternatives to pick from.
You could have a second actuve eSIM if you have a phone that supports more than one (no phones support more than 2 active simultaneously). Though technically the phone number only needs to be accessible for the initial account setup so I guess you could have a burner phone you switch out eSIMs on.
Each Signal application only supports a single account though. So you can have one, and if you have a work profile you're not otherwise using you could have a second account in that instance.With the new Private Spaces you could potentially have a third as well.
So you _may_ be able to have up to 3 simultaneous Signal accounts on the same device.
I'm using my work profile and Private Space for things I can't share a Signal install with though. And I dont want to buy and maintain an extra phone number from a telco just to have another Signal profile.
Of course it's revealing information. If I know that two users that are identified by their phone numbers are talking to each other every day, this is a clear connection you can exploit. Metadata is only useless if you have no imagination.
That's privacy for someone who cares deeply and will get it somehow no matter what, not default zero-effort privacy for the ignorant. (Which WhatsApp does pretty well for example.)
I don't know, I'm not familiar with Signal. But features such as described above with worse privacy than the basic chatting functionality detract from it, it's not just that it would be a bonus if it were better, because that's exactly how effort comes in, having to know about it, and the typical layman user just blindly uses it.
Take Telegram for example, where only explicitly 'secret' chats are e2ee, you have to go out of your way, it's not the easy path.
Signal has profiles nowadays that can be used to connect with people without sharing phone numbers. The latter are only used for signup and discarded immediately after.
Yes. The phone number is just for activation, once activated, you can swap the SIM and carry on. Or have the SIM that receives the activation text in another phone, or be virtual, or whatever.
Millennials and older generations witnessed this happening bit by bit, some of us tried to fight it, but ultimately it’s everywhere now, and apparently it’s been so ubiquitous for so long that people aren’t even aware of it anymore.
1) I do not believe for a second that Meta would actually implement something that would remove their own ability to read those messages.
2) We do not have any proof that their claimed e2e chat service is actually compromised.
The matter of fact tone of the parent made me think there was some actual proof or at least something more than speculation. That's why I asked for a source.
If meta can read those messages, then they’re most definitely not e2e encrypted.
Given the historical record, you would be a fool to assume that any service run by a public company isn’t fully tapped by US intelligence agencies. They’ve been tapping anything and everything they can get their hands on, why stop at whatsapp?
Let me flip it around: what proof do you actually have that it is e2e encrypted? Zuckerberg pinky promised?
Anyone can sue anyone for anything. I have no doubt the US government has access to whatever data it wants from all businesses, but a lawsuit is not evidence of anything.
And apparently requires explicit WhatsApp user opt-in to be available. Meta is of course going to maliciously comply as best they can, so they've made sure interoperability is off by default and requires a specific opt in.
This does cause some interesting tension in the immutability though. /etc in particular is really a mix of things that a sysadmin should really only be setting, and things a regular user may set indirectly. This usage has grown organically over time with the tools involved in the implementation, so it's not at all consistent which are which. The immutable system solutions recognize this by usually handling the whole /etc folder the same way package managers handle package installs that include /etc file: by doing a 3-way merge between the old provided files, the new provided files, and the current existing files to see if the existing are unchanged from the old provided and can just be directly replaced by the new provided or if a merge conflict needs resolving. Additionally, a separate copy of /etc is maintained associated with each available bootable system version so when you roll back you get the old /etc files you had before. Though this does introduce a system-unique variation since you now have new /etc being affected by the state of /etc when it was forked.
If you want all your home folder and system config to be identical, nix or guix really are your primary way to go, that extra lockdown of the user and system config is exactly what most people don't want for usability reasons.
I personally use nix home-manager on top of Aurora DX from Universal Blue. I have my nix home-manager config setup to manage only the things I want to be locked down in my home config, and to provide some extra tools that are easier to manage/supply via Nix than a system package manager (where I would need to do a whole system update to get the new version). My IDE for example is installed on a specific version via Nix, but I don't have Nix manage the settings of it so I can separately tweak as needed without need a home-manager rebuild.
EDIT: typo
reply