Clearly, something is missing here. Why not a permission system like browsers do? A little popup that asks "X is requesting access to your full screen" rather than this "convenience VS security" black and white view most people seem to take a stance at?
Discord capturing the screen is a valid use case, but it should be approved by the DE and it should be possible to block this request.
Currently the mainstream DEs just approve the request by default but in the future I can see a permissions dialog asking the user if they want to allow access to screen recording, and maybe a small icon in the top bar to show when recordings are happening.
This idea that screenshots require special OS-level privileges has been tested and, in practice, does not work. Literally nobody wants compositor-specific screenshot applications. It should have been addressed in the Wayland standards in the early drafts.
Fair enough unrestricted access to any pixel is a security problem. But banning all access to pixels other programs control was an unworkable position that, in hindsight, didn't work. Telling people that the process that merges all the pixels together needs special OS-level support for reporting on what the merged output look like is just not sane. Something went wrong in the design process.
IMHO the right answer might be a GUI toolkit (out of process) that has an API for system resources. Permission would be either granted by the user (a file dialog already indicates what files an app should have access to) or set at the application level at install time. The failure to develop solutions like this is why browsers have taken it on by themselves, because they are constantly running untrusted code.
https://gitlab.freedesktop.org/wayland/wayland-protocols
They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful.
You can see the docs in pretty form here: https://wayland.app/protocols/
Only took 15 years. Pay special attention to the name of Drew DeVault who has been one of the major heros in the story. The Wayland devs apart from Drew do deserve serious kudos, moving away from X was never going to be easy. But copying pixels into a shared buffer as some sort of challenge is just hard to overlook.
Dude please. Wayland has been 100 percent usable FOR ME for years. Plain Wayland is not "crippled" for MY use case. It may be crippled for YOUR use case, and that's a legitimate concern, but don't broad brush Wayland as not usable and crippled in general. For many of us it's already where it needs to be. That said, I do hope those remaining things get sorted out soon.
The de-facto Wayland standard is not going to be the core protocol, in the same way that the core X protocol is woefully insufficient [0] for actually running a modern linux system. It needs extensions. The core protocol just isn't featureful enough - as has been clearly demonstrated by a decade lost in the woods not supporting basic desktop functionality. If a design goal was to delay adoption by 10-15 years while they think about things then I suppose it could be considered a success. Other systems have managed to move much faster than that without doing much harm.
The sticking point is that at least the core X protocol didn't need a decade of R&D for a screenshot extension [1]. I suppose people could claim with a straight face that screenshots and streaming are unforeseen use cases, but they would be excellent poker players. It was a design mistake not to explicitly address that up front. An honest one, made by very competent people, but nevertheless a mis-step.
[0] https://wiki.gnome.org/GraphicsRequirements
[1] I'll admit this is before my time - maybe it did? But the X protocol is a hot mess and Wayland is inching towards the point where it's release is closer to the birth of X windows than the present day.