> It's at most a basic "anti-annoyance" feature, I'm not sure what security you gain from preventing everyone from messaging you.
This could be a long conversation. The short version is there are plenty of articles online by marginalized groups talking about the consequences of having no ability to block arbitrary groups from harassing them online. If someone is calling that "just an annoyance" they've likely never been the target of an extended public harassment campaign.
A slightly longer answer is that the consequences to privacy and security are in a practical sense -- in the sense that someone coming into my house is a violation of my security and privacy. Privacy is not just about hiding information, it's also about why we hide information. It's about the ability to be private; to not be forced to constantly listen to a bunch of people shout at you. Similarly, security exists for a reason, we have security in our homes in the sense that people can't just walk into them and start yelling at us and harassing us. And DMs should be thought of as analogous.
Your DMs are not secure if you have no way to turn them off or restrict them.
> The ability to block users was always there and it still there for free.
If you recognize that is important to privacy and security to be able to block individual users, it's not too hard to recognize that the requirement to individually block users leaves a huge gaping hole in security for a network that supports open registrations.
I use disposable email addresses rather than just blocking individual spammers in my email client. The reason is because there are a near-infinite number of spammers and blocking them one-by-one is ineffective. Being able to turn off a leaked email address is much more valuable to me. It's something that actually cuts down on spam.
And the same is true on social media -- being able to go private and turn off messages or restrict messages to certain subgroups is critically important for people who are stuck in the middle of public harassment campaigns.
----
Regardless, the lack of a feature that is pretty much standardized across most other platforms, and that is pretty widely recognized as a safety feature -- it doesn't make me feel better about Telegram's willingness to gate these kinds of features behind paywalls.
You're saying that the ability to block users is free, but there is no bright line between blocking users and setting general messaging restrictions. That is the same category of safety feature. There's no reason to believe that Telegram wouldn't make blocking users into a paid feature in the future, especially since it has demonstrated that blocking/moderation/lockdown features are something it is willing to monetize.
Because it's Facebook, I can't say that they aren't planning that.
But if anyone else mentioned this tech, I would assume it was benign. Subresource Integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) is primarily aimed at servers proving to clients that their code is unaltered, not the other way around. I haven't personally tried it before, but I can't imagine why extensions wouldn't be able to override integrity strings or remove them from script elements.
For WhatsApp I'm not sure I see the point necessarily, but it's an understandable goal for Open Source and offline webapps or for apps that use 3rd-party CDNs. The main problem for personally hosted code is that the integrity string is also getting served from the server, so there's no reason it can't also be altered if the server that gives the HTML is compromised.
In theory with some tweaking and a way to pin integrity strings in a user-controlled way (which an extension could do I suppose) it could be a step towards allowing users to know when a PWA is being updated, which would be helpful for some security models. In its current state it's fairly niche and I'm not sure how useful the standard is outside of securing CDN requests.
Although why that would matter to WhatsApp, :shrug: It does feel weird that Facebook would be leading that push.
> And before that you just weren't able to restrict that at all
This is a really basic security feature though that every single platform should support. If Telegram didn't support messaging restrictions before, that doesn't mean they're not currently gating a basic privacy/safety feature behind a paywall. It just means they should be embarrassed that they used to be doing something even worse, ie not even offering a basic privacy/safety feature at all.
Correct that this would not technically count as removing a feature, but I feel like that's possibly a distinction without a difference. I'm not coming out of reading this explanation feeling more charitable about Telegram's security or willingness to gate off security features. It's a bad look for a company to put basic blocklists behind a paywall, that is not a company I trust not to start degrading security for free users.
It's not just that it makes the web less powerful, it also makes it less private and less user-controllable. There is no effective way to build an offline webapp that handles important data, if you're building a website that handles actually important data -- that data is getting synced to an online account.
As a result there are a number of web-apps that could be entirely account-free and offline that aren't. It also makes it a lot harder for users to move and transform data, although maybe that's less of a consideration nowadays since mobile has kind of standardized data silos even for native apps that would have previously had portable databases or worked directly with files.
Not saying you should want it, I completely understand and am completely sympathetic to anyone who says "the benefits don't outweigh the risks." That is a fine position for someone to take. That being said, this isn't just about trying to make the web more powerful, it's also in a lot of ways about fixing long-time deficiencies in the web that have made it less private and that forcibly shift the majority of even well-intentioned web software into a user-hostile SaaS model. When every webapp is a SaaS business with web accounts, that decreases hobby development in favor of corporate development and encourages users to spread their data in (imo) irresponsible ways.
This is what people like me have been getting at for ages when we talk about decoupling interfaces from application logic. It's also incidentally a really strong argument for decoupling state presentation from visual presentation. I should be able to build a mobile interface for Audacity without rebuilding Audacity both because the audio processing logic should be separate from the interface and because the interface should be separate from the visuals -- I should be able to consume Audacity's interface as an XML tree and pipe it into a separate renderer.
Because if that was the case it wouldn't be that hard to make Audacity mobile friendly (or at least more mobile friendly than it currently is).
As a bonus, if your interface is consumable as an XML tree without rendering anything, it's very likely going to be much easier to make the interface accessible. From what I can see in the documentation, Audacity as a native app on desktop doesn't work with screen readers on Linux.
This is not necessarily anyone's fault beyond GUI toolkit designers, it's not particular to Audacity, but it's a paradigm shift. Some visual controls wouldn't work well on mobile, but for most apps including Audacity there's really no reason (other than lack of existing infrastructure and toolkit support) why people shouldn't be able to just swap out those visual controls with ones that do work on mobile and use Audacity normally otherwise.
Persistent read/write access to user-defined folders rather than only to private origins.
You know how everyone complains about Flatpak sandboxing until they learn about portals and Bubblewrap because the programs are isolated from the rest of their disk? The web is like that, except without portals and Bubblewrap. You can save stuff and drag files in, but you can't really integrate a webapp with a user's local filesystem -- and it's very hard to keep all of a webapp's data in a user-inspectable format that's easy to transform, open up with native apps, or transfer across browsers or websites.
Now, the problem is that persistent read/write access to user-defined folders is wildly dangerous. And Google's proposal is... not the worst thing in the world? But it's suboptimal and it's a missed opportunity to build something far better, and I kind of understand why Mozilla considers it harmful.
Getting this wrong would have permanent implications for the web. Mozilla is absolutely right to be cautious. However, it's also really holding the web back and in particular holding back PWAs because the only really reliable way as a developer to store data via the web is to sync it to an online account. As a result offline webapps are very limited; you never really trust the storage.
It's an extremely dangerous feature that we really need, but it's not clear who should champion it and I don't really trust Google to be heavily involved in the spec process, let alone to be the people writing the first draft. I don't think Google is good at building nuanced web specs even when there's no conflict of interest at all (see the web audio API, HTML templates, etc...). A lot of Google specs end up being very weird and they end up having strange quirks and very strange limitations that don't need to exist? They're very often kind of orthogonal to what the community needs. I don't know if the problem is that Google doesn't think enough about the spec or that they think too much and over-complicate things, but for low-level important features I prefer other browser-makers to lead the way.
What would be best is if a team with more earned trust picked up the spec and went over it again trying to better address the dangers and trying to make something that better addressed everyone's needs in a cleaner way, but there are not a ton of stakeholders on the web that I trust to do that. As it stands the proposal is... ok-ish? But needs a lot more discussion and could be better. I don't blame anyone for being hesitant about it; the potential for abuse is so unbelievably high.
But... it is a serious limitation that I can't ask for persistent read/write access to a folder from an offline webapp.
It is a general comment about Linux. Arch Linux is a major distro, if people using Arch can't run Linux software using existing packaging systems, the packaging systems are broken.
If the natural result of existing packaging systems is that software only works on distros like Ubuntu and Fedora, then that is very much a general Linux problem.
I suspect GoG tests mostly on Debian-based systems, probably Ubuntu and it's variants. On Arch, things get weird (at least in my experience, maybe other people have had better luck).
It's frustrating because Arch is generally more stable for me than Debian, but you can kind of see the niche status of the OS play out whenever you're working with a package that wasn't packaged by the Arch team. When developers have to maintain packages for multiple distros, my experience has been that usually the popular ones get serviced first and the niche ones get serviced last.
I would love to as well, if the Linux versions would boot up and run on Steam Deck. Even when I was gaming on my desktop, which is pure Arch, I remember regularly needing to edit Linux games or recompile dependencies to get them to work.
Flibitijibibo has some good commentary on when to dynamically/statically link libraries, leaning towards statically linking dependencies when possible to avoid relying on the OS too much. Coincidentally, Flibitijibibo's Linux ports are some of the few where I can just download them and be confident that they're likely going to work out of the box with zero troubleshooting.
> The major distros and BSD have shown, that yes, that scales fairly well in fact given the number of apps provided through distros official repos.
I mean... citation needed :) I run Arch and I am not dismissing at all the frankly incredible work that the Arch maintainers do bundling software and making it available. It is a miracle that it works as well as it does, to the point where my Arch systems are often more stable than non-rolling-release distros I occasionally run. Fantastic work by the maintainers.
But it's not a solved problem and I can only imagine how much effort and work is getting burned to keep it running as smoothly as it does. Step outside of the official Arch repos into AUR or (heaven forbid) into completely separate ecosystems and all of those problems come back. And I don't want to ignore the software outside of the repos, I didn't start using Linux so that I would be beholden to some kind of "official" distro app store.
There are tons of Open Source applications with no legal barriers in place that are not getting packaged in official repositories for no other reason than that they're niche and there is a lot of software to package and not enough people to do package it all.
And of course any non-OS games are also going to run into these problems. That's a problem that distro maintainers can't solve, it doesn't matter how much work they put into it, they can't repackage source-available or closed source software. "People shouldn't ship that" -> but they do :) So ideally we'd be able to handle that without descending into dependency hell.
> No, the main reason is that the linux versions do not exist for the most part
I'm not talking about games where the Linux versions don't exist, I'm explaining why I'm currently running the Windows version of Inscryption on my Deck even though it has a native Linux port. Do I want to be doing that? No, of course not. But the Linux version doesn't boot, most likely because there's some dependency chain missing or an environment variable is wrong, or... I don't know, I don't want to crawl through forums and debug that myself, I want to play the game.
And I'm not alone in that, it is common advice on Linux to use Proton instead of Linux native versions. And that stinks, it's bad for the ecosystem and it's bad for users and it's bad for games. But the Linux versions have so many more problems because they make assumptions about the underlying system that turn out not to be true. Of course Windows builds also have those problems, but the difference is that they run in a containerized environment that gives them the system they expect.
> But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro
Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well developers are able to hold it all together, but my experience is that Linux systems are fragile the moment anyone stops actively managing the dependencies and putting in the work to compile everything to match.
> that is not packaged by the distro maintainers
It is not feasible or scalable for Linux for every single app (even every Open Source app) to be distributed and managed by the distro maintainers. And this is what I'm getting at with dependency isolation -- the vast majority of crashes and bugs I see on Linux (and I mean by a massive margin) are all due to dependency mismatches and shared dependencies. A lot of Linux software is generally stable if the system looks like what it's expecting the system to look like. But if you're not going through an official repository where a bunch of volunteers are putting in the work to make it consistent, then it very often doesn't look like what developers expect.
This is why people run games through Wine instead of using the Linux versions -- it's not because it's impossible to build good native versions, it's because if they don't use the Linux version they can use Bottles. That's the biggest reason; it's about the dependency isolation.
I guess millage may vary, the only thing I can say is that there are multiple instances (particularly GoG which the article seems to praise) that literally never work on some of my systems.
The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging crashes every time I try to install a piece of software. I'll happily take the added complexity of needing to boot a shell into the sandbox if it means I get to debug 50% fewer problems (and in practice Flatpak tends to reduce my number of issues by way more than 50%).
The average user is never going to open a debugger, minimizing the number of crashes is more important for that user than making the crashes easier to debug.
This debate will never die, but while people have been complaining about it, Flatpak has quietly just become a better way to package software for end users. My criteria is that I'm a user, I don't care about what's elegant to developers -- and I have fewer problems with Flatpak than I have with non-Flatpak software. The vast majority of Flatpak problems I do have as a user come down to sandboxing permissions that I actually quite appreciate. The (very) few architectural problems are problems I would have had with other bundling systems too.
"Developers are lazy" -> No, no user ever wants to debug dependency issues, and developers can't get rid of dependency issues. This feels like a repeat of the Rust debates where C developers kept complaining that good developers just don't have memory errors. Okay whatever you're very talented, congratulations; but most software isn't written by people who can reliably support multiple distros and lowering the skill requirements to maintain software is good actually because I use hobby projects all the time. Even outside of hobby communities, GoG's Linux installer is so borked that half of the time it's easier to install the Windows versions of the games and run them through Wine (because then you can use Bottles which provides dependency isolation). And I am completely convinced that dependency management is the problem -- Flatpak apps don't have these issues, at least not nearly as many.
I'm not saying everything should be a Flatpak, but certainly at the very least most Linux games should be, anything that's graphical that isn't being distributed through an official package manager is a good candidate to at least consider Flatpak. I'm always grateful when I can install a graphical app through Flatpak instead of AUR.
Is it the future? Flatpak critics spend a lot of time bashing Flatpak and very little time proposing equivalent fixes or acknowledging why Flatpak exists in the first place. If those issues were solved and the solutions popularized on mainline distros, maybe Flatpak wouldn't be the future. But I'm not holding my breath. This article proposes GoG's system as an alternative and says the existing problems are minor and easy to solve. 2 years later, I have literally never gotten a GoG native Linux installer to run without problems on the Steam deck.
I'm not even saying it has to Flatpak, but whatever system you want to propose (Snap, AppImage, whatever) very clearly dependency isolation is better for end users and results in fewer bugs. "It takes up too much space" just isn't a real critique when the alternative being proposed almost universally fails to run on my hardware.
> we're working on making it so you can log into Quest with an account other than your personal Facebook account
I mean... Quest had this ability before. And Facebook took it away. And now they want us to clap for them when they say they're kind of bringing it back, at some point in the future, in some kind of limited capacity for work accounts?
Call me skeptical.
I'm not really aware of any platform (including Quest) where I would say that Facebook is doing a good job of supporting consumer choice, and I've read plenty of leaked internal communications from the company that suggests they're internally pretty hostile to the idea (Mark included).
Maybe they've turned over a new leaf, but if Mark wants us to all give him the benefit of the doubt that a metaverse is going to be different, he could start by showing this commitment with... any of their current products, really.
There's a lot of talk here about how Facebook is going to be moving into the bold new world of user agency and privacy and choice, and not much acknowledgement that Facebook is responsible for making these platforms what they are today. I don't like Mark's subtle insinuation that Facebook is doing something new or bold by getting rid of restrictions on Oculus that he created. Especially when he hasn't actually fixed the problem, he's just vaguely assured people that the problem might get fixed a year from now, maybe.
He wants credit for swinging in a new direction, and he hasn't actually swung in that direction. Well, prove it, Mark. Prove it with your existing products before you start bragging about how good your next product will be.
At the point where NFTs become a "many copies" model, are they NFTs anymore? It seems like "non-fungible" and "copy" are in contradiction.
More importantly, do we actually want to try and cement a system of perpetual ownership or revenue in an abundant digital world? Doesn't this go directly against our goal of encouraging creators to keep creating?
I think that one of the downside of current content models based on IP and access rights are that many companies (from Disney to Nintendo) have discovered that they can augment their revenue streams basically in perpetuity by locking down decades-old pieces of content, preventing other people from building on that content or sharing it, and then endlessly reselling and recycling it. Because they have the ability to restrict even normal people from building on their work in even non-commercial settings, they have no real competition or incentive to keep iterating on their work or to be responsible stewards of their IP. This is not the outcome that we wanted from IP law, and I feel very hesitant to try and cement it into a technology.
> from transfer of ownership
I think an important concept to get about the Internet is that content ownership isn't scarce. We have moved into a world where I can give something to you without losing it myself. There is no "transfer" of ownership at all, in the digital world there is duplication of ownership. This is a giant shift from how the real world usually works; and with our laws/businesses, we have made a deliberate choice online to ignore that paradigm shift and instead try our absolute hardest to make sure that "ownership" continues to be an exclusive right that can be transferred.
It's understandable why we've gone down this route, but it is nevertheless a complete denial of what an interconnected digital medium is and what it's capable of. I hope that as we move forward and continue to iterate on the Internet that we gradually get closer to embracing the Internet's strengths rather than hobbling them.
Ignoring all of the other criticisms of NFTs for a second, the underlying goal of NFTs as a technology is to undo the existence of digital files. It's to undo the invention of copyable data and to step backwards out of the Internet back into an older world where when you handed someone a CD you no longer had the CD. I think that even if all of the other problems with NFTs were fixed, that's still just not a goal that's worth pursuing.
You're correct to criticize advertising, but I also want to push back a little bit on the "utopia" of paywalls as a funding method for the web.
There's a difference between paying for content creation and paying for content itself. Content creators and their time are actually scarce resources, even online. Content itself is not a scarce resource; once something is created it becomes abundant. So both IP laws/paywalls and advertising are attempts to monetize and artificially restrict/control some other abundant and/or uncommoditized resource instead of engaging with the actual scarce resource/activity that we care about incentivizing.
As such, both advertising and IP-enforced pay-for-access models have negative externalities that arise from them being indirect monetization models. With advertising, we deal with negative externalities such as privacy violations and clickbait. With pay-for-access models, we get externalities like DRM, SaaS, endless content recycling, and a general lockdown of culture itself.
With both payment schemes, we are ignoring the actually scarce resource that is actually in real demand by the market: creators and time. But instead of trying to come up with schemes to monetize that and instead of trying to imagine what a market based on creative/useful output would look like, we've instead become obsessed with making other resources artificially scarce or artificially commoditized. We fight against technology and human nature itself instead of thinking about how we can fund the real scarce resources that still remain.
This could be a longer conversation; there are multiple theories about how to pay for creation, and a lot of debate about what models are sustainable there. Too long of a conversation to get into right here. But the really short version of this conversation is that you are very correct to look at advertising as an imprecise, indirect way of measuring value, and you are correct to point out it has a lot of negative externalities. But you're making an assumption that pay-for-access models haven't had their own negative externalities, and I don't think that assumption holds up. I think we've seen a lot of suppression of innovation and general culture because of our current funding model for IP. Of course a theoretical Internet where people paid for content access would have turned out different; but would it have been better? I don't think that's a safe assumption at all.
At its worst the current pay-for-access model sometimes decreases the creation/availability of content because it incentivizes recycling and restriction of existing content, and restricts other creators from building on top of and preserving existing content -- essentially denying a universal human instinct that has been around for almost as long as humans have existed.
There isn't an easy answer about how we should remake a content economy in a world without digital scarcity (ask Open Source devs how hard this is), but recreating digital scarcity and pretending that we're still in the old system probably isn't the right way to move forward. We should try to consider how people can more directly pay for the resources that are actually scarce: not content itself or the bits on your computer, but instead content creation and maintenance and the people who are able to make the things we care about.
The more directly we monetize resources that are actually scarce and the less that we rely on indirect models of monetization, the fewer surprising/negative externalities we'll see in the long run.
> enforcing digital scarcity in a federated metaverse
I don't know, I feel this sentiment betrays a industry-wide common lack of imagination. We start building digital realities, and our first thought is to try and make them more crappy like the regular one?
Nobody really likes scarcity other than speculators and collectors. We shouldn't be trying to invent more of it, we shouldn't be trying to get rid of the advantages of digital abundance. We should instead be trying to manage and mitigate the limited forms of scarcity that still exist in digital systems -- a long term goal of the Internet should be the complete elimination of most non-physical scarcity. Every time we can make a new asset or utility stop being scarce, that's a step in the right direction.
It's a failure of creativity, vision, and (frankly) courage, that so many people in the tech industry are incapable/unwilling to imagine worlds that aren't artificially hobbled and restricted so that they mimic existing systems.
We build these incredible, world-changing technologies, and then instead of rethinking ownership or creator incentives we just waste a bunch of energy and time building little pretend speculative "art markets" and stressing out over whether somebody might copy and paste a file between two computers or share it online.
The core idea of having a universal layer on top of reality that is owned by any company, at all, is utterly repulsive to me. I'm not sure I have the words to describe it.
The type of world Facebook is describing is always -- 100% of the time -- a dystopia if it is a privatized, corporate-controlled AR/VR layer where ordinary people need permission and contracts to interact with each-other. Anything any single company or coordinated group of FAANG companies make will be awful when scaled up to the level Mark is talking about. There's no promise they can make to me, there's no strategy they can pursue to ease my worries. Purely by virtue of a single company (or a group of FAANG companies) being in charge of it, it's already garbage.
Having said that, of all of the companies to try and assert control over a "metaverse", Facebook is probably amongst the least suited and most dangerous companies to do so. If they can't even run the Oculus platform competently, how can they possibly claim they're competent enough to run a giant industry-wide platform on top of Oculus?
----
> The metaverse will be a collective project that goes beyond a single company. It will be created by people all over the world, and open to everyone.
And this stuff is just complete nonsense. No platform that Facebook has ever been involved with has ever even remotely come close to being "collective" or "open" to everyone worldwide, and it's just wildly insulting to pretend that anything about that is going to change now.
Facebook can't even launch this announcement article without making a bunch of XHR requests and falling over if Javascript isn't enabled. So sure, let's all close our eyes and pretend that they're magically capable of building an accessible, open VR platform that respects user privacy/agency. What has Facebook ever done in its entire history as a company that would make us believe that they are in any way trustworthy or qualified enough to try and build a consumer platform/medium of this scale?
> The morality ascribed to old business models probably won't disappear until the people who grew up in earlier times die. (I am reminded of John Philip Sousa railing against sound recordings in a 1906 Congressional hearing).
To expand on the morality point here:
In most areas, we recognize that we need to be careful limiting innovation for the sake of existing markets. For example, we're not trying to ban electric vehicles just because it makes it harder for gas companies to make a profit. The existence of DVDs and CDs lessening profits of movie theaters and concert halls is not a good argument to make the technology illegal. We didn't ban typewriters because they put the illuminated manuscript writers out of business. We do regularly get the government to interfere in some cases where a regulation or restriction clearly helps the market, but we try to be kind of careful about how we do it, and we view it through that lens: as an artificial restriction that is justified because of its social benefit.
However, with copyright it's really difficult to make people even understand that the market and human rights are being restricted in the first place -- it has that moral quality for a lot of people. Part of it is the name: "copyright" implies a right, but it is not a natural right. There is no inherent property/personal right to an idea, there's no way to derive a natural property right that is a restriction over what other people are allowed to talk about or build. It is an extremely modern idea to believe that inventing an idea implies that you own the idea itself, or that inventing a story means that the story can't be morally retold without your permission. So copyright isn't a "right" in the traditional sense, it is a government restriction on an innovation (easy copying), that helps prevent that innovation from disrupting the existing market too much or putting people out of business.
That's not to say copyright is bad or that we should just drop it tomorrow, but we should be looking at it through this lens; copyright is a subversion of natural market forces and a restriction on the natural human right to communicate, copy, and build on information they see in the world. Copying is a fundamental part of culture and a fundamental part of what it means to be human.
As such, we should be highly skeptical of copyright expansion, and we should be constantly evaluating whether or not the market really needs copyright restrictions at their current level. We should be actively looking to evolve the market so we can weaken copyright, because copyright is an artificial restriction on natural human activity, and an artificial restriction on the free market itself.
When people talk about expanding copyright, the burden is on them to justify why it's worthwhile to restrict human rights. Just saying that some businesses will fail isn't good enough, copyright is an extreme measure we're collectively embracing so that we can prevent the collapse of the entire creative market. Unless we're talking on that scale, we probably should be weakening copyright over time, even if it means a few businesses fail or have to pivot. In general, it's OK for the market to evolve and for some old profit-generating ventures to become unprofitable. And many will evolve and transform into other markets -- we don't have illuminated manuscripts now, but we do have mass-produced beautifully illustrated books, so in general the printing press seems to have been a pretty good trade and enabled more markets than it destroyed.
> So developers should bend to abusive business partners with a big track record off being assholes just because they are currently (!) the biggest player?
That's not at all what GP is saying. They're saying that X handles their use case, and Wayland doesn't, and that most end users won't care about who's fault that is.
A lot of the criticism of Wayland comes from uninformed jerks who want to trash the protocol over stuff that isn't a real problem, but there is also a bit of reflexive lashing out that comes from Wayland advocates. GP is just saying they can't switch to Wayland until the ecosystem around it matures. That's not an attack, you don't have to take it personally.
> you will need to buy a GPU from a different vendor than NVIDIA
I run a 4K monitor on my desktop with an ~6 year old NVidia graphics card. I run modern software on that machine, I watch movies, I run games, I do 4K art, I even boot into Blender occasionally. I'm not seeing significant slowdown or framerate problems as long as I use NVidia's proprietary drivers in X. But on Nouveau, it's unusable. Who's fault is that? Probably NVidia's! But it doesn't matter, my computer currently works well, I have no plans to upgrade in the immediate future, and this was put together during a period where NVidia was very clearly the sensible choice for anyone who cared about Linux graphics performance.
It's reasonable for people to use older hardware, and it's reasonable for them to want that hardware to work well. We're not talking about people running 32 bit OSes or something, not everybody upgrades their graphics card every 2 years, and it's not really feasible for the surrounding Wayland ecosystem to only target the people who do.
I don't have a proposal for that, I'm not saying anybody has to do anything. I'm actively rooting for Wayland, I do think it is the future. But I'm also describing why I don't run Wayland on my Arch setup and why I don't recommend it to people who ask me about getting into the more technical side of Linux. If someone wants to take even that as some kind of anti-Wayland screed instead of as a completely neutral, factual representation of the current state of the world and the Wayland ecosystem, then that's their problem, not mine.
There's this thing I'm seeing where anyone bringing up these issues just gets asked, "well, what's your suggestion? You want to force developers to do X?" I'm not suggesting anything! I'm describing why I don't use Wayland on my desktop. That's it, that's the only thing I'm doing. I don't know how to solve the problem, but the problem exists, even if it's not your fault.
This could be a long conversation. The short version is there are plenty of articles online by marginalized groups talking about the consequences of having no ability to block arbitrary groups from harassing them online. If someone is calling that "just an annoyance" they've likely never been the target of an extended public harassment campaign.
A slightly longer answer is that the consequences to privacy and security are in a practical sense -- in the sense that someone coming into my house is a violation of my security and privacy. Privacy is not just about hiding information, it's also about why we hide information. It's about the ability to be private; to not be forced to constantly listen to a bunch of people shout at you. Similarly, security exists for a reason, we have security in our homes in the sense that people can't just walk into them and start yelling at us and harassing us. And DMs should be thought of as analogous.
Your DMs are not secure if you have no way to turn them off or restrict them.
> The ability to block users was always there and it still there for free.
If you recognize that is important to privacy and security to be able to block individual users, it's not too hard to recognize that the requirement to individually block users leaves a huge gaping hole in security for a network that supports open registrations.
I use disposable email addresses rather than just blocking individual spammers in my email client. The reason is because there are a near-infinite number of spammers and blocking them one-by-one is ineffective. Being able to turn off a leaked email address is much more valuable to me. It's something that actually cuts down on spam.
And the same is true on social media -- being able to go private and turn off messages or restrict messages to certain subgroups is critically important for people who are stuck in the middle of public harassment campaigns.
----
Regardless, the lack of a feature that is pretty much standardized across most other platforms, and that is pretty widely recognized as a safety feature -- it doesn't make me feel better about Telegram's willingness to gate these kinds of features behind paywalls.
You're saying that the ability to block users is free, but there is no bright line between blocking users and setting general messaging restrictions. That is the same category of safety feature. There's no reason to believe that Telegram wouldn't make blocking users into a paid feature in the future, especially since it has demonstrated that blocking/moderation/lockdown features are something it is willing to monetize.