Quoth the wiki 'PipeWire is a rather new multimedia framework by GNOME'.

There will be people who don't want to use GNOME frameworks and don't want to use the GNOME window manager.

Wayland is enforcing a policy ('don't access other devices graphics output') where it should be providing capability ('an applications graphics output is private by default but that can be configured'). However it looks like the design of Wayland purposefully omitted that sort of configuration from the protocol. So instead of having a security model that is sufficiently complicated to allow screen recording, the security model is 'No'.

To get a framework independent solution all the compositors would need to implement an identical API for accessing graphics output. That needs to be coordinated in the same fashion as the Wayland spec. As the spec stands, it is just asking for every framework, compositor or application to go implement its own different solution.

The Wayland designers may even have tried to avoid explicitly creating a security model, but in practice it comes with an implicit security model that is inflexible, unconfigurable and difficult to coordinate around.

From what I gather, Pipewire isn't part of Gnome, i.e. it's generic and can be used with any DE.

For example, all compositors are using libinput, which replaces legacy ways of X handling input. It's not mandated by the protocol either. So I don't see why they can't use Pipewire for audio and video needs.

If anyone wants to make a better alternative to standardize on - they are free to propose it.

But libinput is a freedesktop.org project, ie, supported by the same people who are working on Wayland. It was specifically built to support Wayland.

Pipewire looks like some audio-visual framework for GNOME and GTK apps and while it might be fantastic it is both new and not very comprehensibly advertised. And it will probably be very complicated and involve some rather interesting design issues compared to building something in when the Wayland protocol was created.

We're coming out of a world where the standard used to be "run graphics drivers in userspace!" so any weird compromise is workable (including an audio framework deciding on graphics security policy). But ultimately the idea that a GNOME-sponsored effort is going to be what sorts out the security model for desktop apps is weird. I can't find anything to suggest that Pipewire is intended to be the definitive way to do screen recording, it looks to me like that might be a happy side effect. It wouldn't be surprising if it turns into two or three competing ideas.

You're mistaken with pipewire, it's a daemon intending to replace pulseaudio at some point, it's not a gnome component. Screen recording is also available in wlroot based window managers.

The wayland environment is maturing quite fast now.

Some details here: https://tanukaskinen.wordpress.com/2018/11/12/pipewire-hackf...

    So far video applications on Linux have accessed the
    hardware directly, meaning that two applications can’t
    access e.g. a webcam simultaneously. Solving that
    problem, and screen sharing with Wayland, were to my
    understanding the main motivations for creating a video
    daemon.

So screen sharing on Wayland (that covers capture use case) was one of the main motivations behind it.

If both Gnome and KDE (the most widely used DEs) are behind it, I'd say it's already a major consensus on where things are going.

Also, it looks like even wlroots has some plans to support it: https://github.com/emersion/xdg-desktop-portal-wlr

And if anyone wants to propose a better alternative, like you said, they can do it.