ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Poly[m] has quit [Remote host closed the connection]
zamundaaa[m] has quit [Remote host closed the connection]
JosExpsito[m] has quit [Remote host closed the connection]
doras has quit [Remote host closed the connection]
hasebastian[m] has quit [Write error: connection closed]
FellFromTheSky[m] has quit [Write error: connection closed]
jasyuiop[m] has quit [Write error: connection closed]
Joanna[m] has quit [Write error: connection closed]
cb5r[m] has quit [Write error: connection closed]
japchae[m] has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
FbioPacheco[m] has quit [Write error: connection closed]
emilio[m] has quit [Write error: connection closed]
danburd[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
inkbottle[m] has quit [Write error: connection closed]
unix-supremacist[m] has quit [Write error: connection closed]
tzx[m] has quit [Write error: connection closed]
i509VCB has quit [Write error: connection closed]
Max[m]123 has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
teh1[m] has quit [Remote host closed the connection]
marcusbritanicus[m] has quit [Remote host closed the connection]
frytaped has quit [Write error: connection closed]
ozwald1[m] has quit [Remote host closed the connection]
unix has quit [Write error: connection closed]
ki[m] has quit [Write error: connection closed]
DemiMarie has quit [Write error: connection closed]
vchernin[m] has quit [Write error: connection closed]
deknos82[m] has quit [Write error: connection closed]
Florian[m]1 has quit [Write error: connection closed]
davidre has quit [Write error: connection closed]
rails[m] has quit [Write error: connection closed]
Kelseyjgilbert[m] has quit [Write error: connection closed]
AndrewAylett[m] has quit [Write error: connection closed]
j-james[m] has quit [Write error: connection closed]
hex[m]1 has quit [Write error: connection closed]
enick_187 has quit [Write error: connection closed]
drakulix[m] has quit [Write error: connection closed]
[old]freshgumbubbles[m] has quit [Write error: connection closed]
RomanGilg[m] has quit [Write error: connection closed]
DrNick has quit [Write error: connection closed]
zaibon[m] has quit [Write error: connection closed]
Ryhon[m] has quit [Write error: connection closed]
jryans has quit [Write error: connection closed]
Naruto[m] has quit [Write error: connection closed]
furyishere[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
enick_929 has quit [Write error: connection closed]
arichardson[m] has quit [Write error: connection closed]
bluepenquin has quit [Write error: connection closed]
cousinofthor[m] has quit [Write error: connection closed]
niecoinny[m] has quit [Write error: connection closed]
edrex[m] has quit [Write error: connection closed]
junglerobba[m] has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
jmariondev[m] has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
windowsxp[m] has quit [Write error: connection closed]
varlad[m] has quit [Write error: connection closed]
ammen99[m] has quit [Write error: connection closed]
botiapa[m] has quit [Write error: connection closed]
q234rty[envs][m] has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
GrahamPerrin[m] has quit [Write error: connection closed]
ujineli[m] has quit [Write error: connection closed]
q234rty[m][m] has quit [Write error: connection closed]
toggleton[m] has quit [Write error: connection closed]
diamondburned[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
BilalElmoussaoui[m] has quit [Write error: connection closed]
pitsch[m] has quit [Write error: connection closed]
nazarewk[m] has quit [Write error: connection closed]
apol[m] has quit [Write error: connection closed]
bdaase[m] has quit [Write error: connection closed]
ongy[m] has quit [Write error: connection closed]
ehfd[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
dos1 has quit [Max SendQ exceeded]
tleydxdy has quit [Write error: connection closed]
Levans has quit [Write error: connection closed]
Max[m]121 has quit [Write error: connection closed]
d_ed[m] has quit [Write error: connection closed]
scriptingdad[m] has quit [Write error: connection closed]
rubo_[m] has quit [Write error: connection closed]
ambasta[m] has quit [Write error: connection closed]
ttancos[m] has quit [Write error: connection closed]
Shimmy[m] has quit [Write error: connection closed]
smasher_tati[m] has quit [Write error: connection closed]
dos11 has joined #wayland
jgrulich has joined #wayland
tzimmermann has joined #wayland
gusnan has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
ahmadraniri[m] has joined #wayland
dcz_ has joined #wayland
rasterman has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
floof58 is now known as Guest3035
floof58 has joined #wayland
<pq>
emersion, too late, you'll get to review the replacement. :-)
Guest3035 has quit [Ping timeout: 480 seconds]
<pq>
also, how many years after that until c_std=c11 would actually expose asprintf?
<emersion>
the POSIX standard is unrelated to the C standard
<pq>
ok, the same question without c_std
Dami_Lu has quit [Remote host closed the connection]
<emersion>
the same time as you'd wait getting a new wayland release
Major_Biscuit has joined #wayland
<emersion>
glibc will add support for the new _POSIX_C_SOURCE, then it's just a matter of waiting for it to propagate
Dami_Lu has joined #wayland
<pq>
why would it be that easy? Does it not require the change to be made in every relevant libc implementation first, then wait for those to propagate to distributions, then wait for older distributions to hit EOL?
MajorBiscuit has joined #wayland
<pq>
do those other libc's even want to follow the latest POSIX?
<emersion>
these don't sound like serious questions, so i'll go back to more productive things
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
<pq>
sure
<pq>
I don't know why mentioned asprintf is coming, it's useless to us anyway
<emersion>
i thought you might be intersted in knowing, but apparently not
<emersion>
interested*
<pq>
it'll be a few years before it's actually available, and I don't want to wait that long.
<pq>
and once it is available, we've been using our replacement for several years, so I'm not sure anyone would even notice to replace the replacement with a slightly shorter wrapper.
<emersion>
btw, i am not sure re-implementing it makes sense
<pq>
already done
<pq>
you can argue in the review then
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
Dami_Lu has quit []
<dottedmag>
Discussions like that remind me why I don't want to touch C anymore
<emersion>
people who don't like C should just stop forcing themselves to use it
<pq>
I did think about doing libdisplay-info in Rust and offer a C ABI, but figured that no-one else would be on board, either in development or usage.
i509VCB has joined #wayland
<i509VCB>
It would be neat but I do not want to deal with all the pains of sharing strings to C
<i509VCB>
libdisplay-info probably has some dynamicish data as well
<dottedmag>
Done! Not really, there are lots of C-only interfaces in Linux graphics land that are hard to substitute: libinput, Mesa, fontconfig. Also libudev, because its storage format is not stable.
<dottedmag>
And Linux dlopen() is in libc
<i509VCB>
Someone I know is trying to bind the alsa midi api in Rust and I've heard it's a union nightmare
<dottedmag>
At least Wayland is specified as protocol, not as C API. That's a relief.
<i509VCB>
Well Wayland is very c-like still
<i509VCB>
So even the pure rust implementation of wayland-rs is a little more complicated than just decoding messages off the wire
<i509VCB>
And because EGL and Vulkan exist we still need to bind libwayland anyways
<i509VCB>
(I do not want to reimplement WSI by hand pretty much)
<i509VCB>
There was a proposal a while back ago for a more ffi friendly libwayland library that would be a layer under something like the current libwayland and implementations in other languages but that hasn't really materialized
<i509VCB>
But you'd still need to make new extensions in Vulkan and EGL to use the new library's types
genpaku has quit [Remote host closed the connection]
genpaku has joined #wayland
<i509VCB>
Long story short if we didn't need to deal with libwayland the wayland-rs api would look a lot different
<pq>
i509VCB, what about the reverse? Developing a libwayland natively in Rust and then offering a C ABI compatible with the original libwayland?
<pq>
when a system migrates to the Rust version, it must delete the original version completely
<i509VCB>
It's probably possible to do the reverse
<i509VCB>
The client side is probably where this would be needed as zwp-linux-dmabuf version 4 effectively removed the need to use EGL_WL_bind_display
<dottedmag>
i509VCB: Is the pain mostly on client-side of wayland-rs? Is there anything that pulls in libwayland on server side?
<i509VCB>
It can be a pain on the server, but there is enough done via public protocols that the server could be 100% Rust
<i509VCB>
The client is most of the pain by virtue of egl and vulkan
<pq>
and if you wanted to use some non-native-Rust toolkit
<jadahl>
emersion: re security context, not a fan of how trivial it becomes to start pretending to be sandboxed, but I guess that's not a fight one can win. would help if the protocol at least adds wording that it must be possible to e.g. verify validity using sandbox specific ways, and e.g. *require* sandobx instance
RAOF has joined #wayland
<RAOF>
If you need WL_bind_display in the server it's still annoying (and the server library is worse than the client lib, as there are a bunch of exposed intrusive linked lists)
<i509VCB>
I imagine expose libwayland via rust rewrite would probably uncover a lot of implementation details of libwayland
<dottedmag>
Right. And server-side rendering doesn't care, it needs to access GPU it works via DRM.
<dottedmag>
*if it needs
<emersion>
jadahl: but that wouldn';t really help…
<jadahl>
what wouldn't help?
<emersion>
it's not like flatpak has a daemon you can check an instance ID with
<jadahl>
it has "conventions" though e.g. looking at the directory containing the ID
<i509VCB>
Yeah the server side rendering has all the graphics api stuff it needs for the gpu
<emersion>
jadahl: yeah and it's trivial to fake
manuel1985 has joined #wayland
<jadahl>
at least in theory, with selinux magic, it can be made harder to fake
<pq>
RAOF, WL_bind_display would be needed only with very old or proprietary EGL implementations? Or are there relevant non-dmabuf OSs too?
<i509VCB>
I may try what pq suggested in the future but that's going to be way in the future
<i509VCB>
I'll probably be more likely to riir libxkbcommon before libwayland
<jadahl>
emersion: another concern, that I suppose only can be fixed by "wording" is to not allow semi-nested security contexts, e.g. it should be an error to try to do a security context if an old flatpak was used, or it should be disallowed if used inside a snap, if snap won't get support for it
<emersion>
i don't understand how it's possible to implement this
gschwind has joined #wayland
<pq>
i509VCB, I can totally understand that.
<emersion>
i've made many compromises now that it's tempting to just revert to what i want and ship it as ext-
<RAOF>
pq: proprietary EGL, yeah.
<RAOF>
Not everyone gets to require modern mesa as the only supported platform 😉
<gschwind>
Hello, in practice when frame callback is fired, is it just after the last commit is applyed and visible to the user ?
<pq>
gschwind, it's more vague than that.
<i509VCB>
Or modernish Nvidia cards
<pq>
gschwind, as the spec says, it is a good time to start to draw again.
DonRichie has quit [Ping timeout: 480 seconds]
<gschwind>
pq, this is why I ask in practice ^^
Dami_Lu has joined #wayland
<pq>
gschwind, it's a bad idea to rely on the practises of one compositor, because another may differ.
<gschwind>
pq, but I can live with the blur of the spec :)
<pq>
gschwind, it does not guarantee visibility, but it does guarantee that the client cannot make the previous update be dropped anymore.
<RAOF>
What do you want to do with more information than “now is a good time to submit a new frame”?
<pq>
gschwind, if you need visibility (as far as not knowing which parts of the surface were shown), use presentation-time extension.
<gschwind>
For now nothing other than curiosity, but for implementing compositor it may be a good hint :)
<pq>
I think wl_surface.frame says a lot about how a compositor must behave.
<pq>
what it specifically does *not* say is whether the frame callback is emitted before or after e.g. the KMS page flip completion that made the that update visible.
<pq>
and this is where compositors also do differ, AFAIU
<gschwind>
pq, the spec is also vague
<pq>
gschwind, deliberately
<i509VCB>
I'd love to be able to write a test for every sentence in the protocol, but that would be a little too strict then
<gschwind>
ok so, their is no common practice amoung compositors
<pq>
the frame callback is for throttling frame rate, nothing more
<gschwind>
thanks for the highlight :)
<jadahl>
emersion: e.g. to implement that in a compositor that already supports e.g. snap, to not open up a sandbox hole for snap applications, assuming they don't use the security context, is to not allow security contexts created from something that has the "old" snap auth mechanism
<pq>
e.g. Weston sends frame callbacks to maximize the client's available time to draw the next frame without missing the deadline, while other compositors might e.g. adjust the callback sending to minimize latency
<emersion>
jadahl: the sandbox protocol can only *restrict* what clients can do
<i509VCB>
At least the Wayland core protocols and xdg shell are a lot shorter specs than something like webgpu
DonRichie has joined #wayland
DemiMarie has joined #wayland
ambasta[m] has joined #wayland
ammen99[m] has joined #wayland
AndrewAylett[m] has joined #wayland
anomalous_creator[m] has joined #wayland
apol[m] has joined #wayland
arichardson[m] has joined #wayland
bdaase[m] has joined #wayland
BilalElmoussaoui[m] has joined #wayland
bluepqnuin has joined #wayland
botiapa[m] has joined #wayland
Naruto[m] has joined #wayland
cb5r[m] has joined #wayland
cmeissl[m] has joined #wayland
cousinofthor[m] has joined #wayland
d_ed[m] has joined #wayland
danburd[m] has joined #wayland
davidre has joined #wayland
Nico has joined #wayland
deknos82[m] has joined #wayland
DemiMarieObenour[m] has joined #wayland
diamondburned[m] has joined #wayland
Guest3020 has joined #wayland
doras has joined #wayland
drakulix[m] has joined #wayland
edrex[m] has joined #wayland
ehfd[m] has joined #wayland
emilio[m] has joined #wayland
FbioPacheco[m] has joined #wayland
GeorgesStavracasfeaneron[m] has joined #wayland
FellFromTheSky[m] has joined #wayland
Joanna[m] has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
frytaped[m] has joined #wayland
furyishere[m] has joined #wayland
gnustomp[m] has joined #wayland
frytaped has joined #wayland
GrahamPerrin[m] has joined #wayland
halfline[m] has joined #wayland
hasebastian[m] has joined #wayland
hch12907 has joined #wayland
Florian[m]1 has joined #wayland
heftig has joined #wayland
Guest3052 has joined #wayland
hex[m]1 has joined #wayland
inkbottle[m] has joined #wayland
j-james[m] has joined #wayland
japchae[m] has joined #wayland
jasyuiop[m] has joined #wayland
Kelseyjgilbert[m] has joined #wayland
jmariondev[m] has joined #wayland
junglerobba[m] has joined #wayland
JosExpsito[m] has joined #wayland
jryans has joined #wayland
Levans has joined #wayland
marcusbritanicus[m] has joined #wayland
MaxOOO-backon14thOct[m] has joined #wayland
Mershl[m] has joined #wayland
Max[m]123 has joined #wayland
nazarewk[m] has joined #wayland
niecoinny[m] has joined #wayland
nielsdg has joined #wayland
ongy[m] has joined #wayland
DemiMarie is now known as Guest3060
teh1[m] has joined #wayland
ozwald1[m] has joined #wayland
pac85[m] has joined #wayland
pitsch[m] has joined #wayland
Poly[m] has joined #wayland
psydroid[m] has joined #wayland
q234rty[envs][m] has joined #wayland
q234rty[m][m] has joined #wayland
rails[m] has joined #wayland
robertmader[m] has joined #wayland
RomanGilg[m] has joined #wayland
rubo_[m] has joined #wayland
Ryhon[m] has joined #wayland
scriptingdad[m] has joined #wayland
smasher_tati[m] has joined #wayland
Sumera[m] has joined #wayland
Shimmy[m] has joined #wayland
underpantsgnome[m] has joined #wayland
tleydxdy has joined #wayland
toggleton[m] has joined #wayland
ttancos[m] has joined #wayland
tzx[m] has joined #wayland
ki[m] has joined #wayland
ujineli[m] has joined #wayland
unix has joined #wayland
unix-supremacist[m] has joined #wayland
varlad[m] has joined #wayland
vchernin[m] has joined #wayland
MatrixTravelerbot[m]1 has joined #wayland
windowsxp[m] has joined #wayland
xerpi[m] has joined #wayland
YaLTeR[m] has joined #wayland
yshui` has joined #wayland
zaibon[m] has joined #wayland
zamundaaa[m] has joined #wayland
<jadahl>
emersion: lets assume snap won't use 'security context', at least at first. to not open up a sanbox hole for all snap applications, I need to limit 'security context' so that it isn't exposed to snap applications. the same applies if I have an old /usr/bin/flatpak; i should not allow security contexts inside those flatpak sandboxes despite they from "security context"'s own perspective are not sandboxed
fahien has joined #wayland
<jadahl>
in other words, it's not safe to stop checking the /proc/<pid> files
fahien has quit [Quit: fahien]
<emersion>
jadahl: my compositor won't have any sandbox mechanism specific logic
<i509VCB>
the security context protocol is intended for sandboxes in general? Or is it to grant privileged protocols without socket hackery?
<RAOF>
(incidentally, if you want someone who might be implementing snap sandboxing to comment, point me to the PR and I'll check in next week)
<jadahl>
i509VCB: it's about opening per sandbox instance sockets, and claiming that socket has an app id associated with it
<jadahl>
the culprit is that every wayland connection that doesn't go via the security contexts "sub socket" is assumed to be non-sandboxed and allowed to claim anything it launches to be sandboxed
<qyliss>
jadahl: can you explain more about the sandbox-only features you'd like to use? You said on the MR "sandbox related integration with the permission store" — could you expand on that?
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
manuel1985 has joined #wayland
Brainium has joined #wayland
kts has joined #wayland
<jadahl>
qyliss: I mean if you only want actually sandboxed apps in the permission store to remember whether something should be allowed or not
<swick>
emersion: jadahl has a good point though; the security-context can't be trusted until all sandboxing engines use the protocol
<emersion>
there will always be sandboxing engines not using the protocol
<emersion>
the protocol can't be trusted, but it's as much of an issue as unsandboxed Wayland clients punching security holes
<emersion>
i will use the protocol to *remove* features which are usually exposed
<emersion>
mutter will know it can trust the protocol with the same mechanism as its current racy checks
<swick>
one could argue those features should not be exposed in the first place and are added for non-sandboxed clients
<emersion>
swick: what do you mean, isn't that the same?
<swick>
yeah, that's my point
<swick>
except as long as not all sandboxing engines support the protocol some of the sandboxed clients are handled like non-sandboxed clients
<swick>
anyway, I don't see a way to fix this
<emersion>
ie, with the same racy checks as before for mutter
<swick>
well, mutter just never exposes any questionable protocols
<emersion>
it exposes things like global shortcut inhibitor
<swick>
mh, true
<swick>
it also tries to match wl clients to apps for other reasons and that becomes more robust, even if not for all sandboxed clients
<swick>
iow, the situation becomes better and will become even better over time
<emersion>
yeah…
<jadahl>
security-context as is can most likely only be a complement to verify the race didn't happen but for anything more it decreases security
<swick>
I don't see how it decreases security
<jadahl>
it immediately opens up security holes if the sandbox engine we checked for before don't use it
jgrulich has quit [Ping timeout: 480 seconds]
<jadahl>
so e.g. new mutter old flatpak, the sandboxed apps in flatpak can pretend to be something else
<jadahl>
it can be avoided by still checking using the old method
<swick>
they already can. it doesn't decrease sucurity, it only decreases the effort it takes to exploit.
<swick>
we could also just not implement it in mutter for now and wait until it propagates to flatpak, snap and wlroots
<emersion>
you can check that the client binding to the security-context is flatpak using the racy method
<emersion>
then you can disable all racy checks for the child clients
<jadahl>
you mean they can by racing the pid? that has only be theorized, while with security-context it's just some trivial code
<emersion>
only be theorized""
<emersion>
i have a PoC
<jadahl>
that escapes the flatpak sandbox?
<swick>
the exploit is about failed authentication
<jadahl>
anyhow, checking both the old and security context way improves things, no doubt about that
<jadahl>
but security context alone opens up a new exploit that wasn't possible before
<jadahl>
(until all sandbox engines are fixed)
<qyliss>
only if you previously had a sandbox implementation, that exposed privileges to sandboxed clients that regular ones didn't have, and are running untrusted clients
<swick>
new exploit which achieves the same authentication failure
<swick>
it also closes the old exploit and gives us a path to fix the new exploit
<jadahl>
swick: the new exploit is that the sandboxed app can open up a new security context and trick the compositor to believe a client in spawns to be something it's not
<swick>
right, that's an authentication failure
fahien has joined #wayland
<qyliss>
Could you have a second Wayland socket that was only made available to trusted sandbox implementations, and only allow security-context on that socket?
<emersion>
that isn't possible, if sandbox impls can access it, unsandboxes clients can too
<emersion>
unsandboxed*
<swick>
I don't think we'll ever be able to do better than that tbh jadahl
<emersion>
jadahl: what do you suggest exactly?
<swick>
the issue is that there is no common sandboxing implementation
<qyliss>
emersion: AIUI this is already predicated on "selinux magic" for security
<swick>
even if you don't have the PID race, authentication depends on how the sandbox is implemented: for snap there is some LSM label, for flatpak a file in the mount namespace, etc
<swick>
as long as we don't have some common "thing" it just won't be possible
fahien has quit []
rasterman has quit [Quit: Gettin' stinky!]
<jadahl>
swick: only if we had kernel api to get info about a process race free
<emersion>
if you feel this is the way forward, i'm fine with that, and i'll continue to push this ext for wlroots only
<emersion>
as ext-
<jadahl>
emersion: thats the thing, I don't have better suggestion than compositors should be aware and that it can help to verify the validity using the instance number or something
<emersion>
okay, i'm fine with adding warnings
<emersion>
but not fine with requiring and recommending that compositors shoudl check
<emersion>
as my use-case is incompatible with that
<jadahl>
would be good to define the sandbox engines too, so that e.g. 'flatpak' must come with a 'instance id' for example
<emersion>
i don't see a need to add this to the spec
<emersion>
flatpak is an implementation, there's only one
<swick>
we could require the triple always
<jadahl>
not a fan of free form undefined strings in specs really
<swick>
generally I agree, but in this case I don't
<jadahl>
then require the instance id always
<emersion>
an instance ID might be annoying to generate for some sandbox engines
<emersion>
you're free to require it in your compositor
<swick>
if the sandboxing engine doesn't have the concept of instances, it can just choose any
<emersion>
and make them collide when multiple insatnces are started?
<swick>
sure
<emersion>
so we can't spec instance_id to be unique
<emersion>
tbh i don't see how this would improve things
<swick>
well, what would unique mean anyway? an instance can open multiple wl connections anyway
kts has quit [Ping timeout: 480 seconds]
<emersion>
(sandbox, instance_id) must be unique
<swick>
I don't think it should. it's perfectly valid for an application instance to open multiple wayland connections.
<emersion>
i don't understand how that's related?
<emersion>
unique for the whole compositor
<jadahl>
emersion: making requirements unpredictable means the protocol is unpredictable and that's not good
<swick>
emersion: then I don't understand what you're trying to get at
<emersion>
i will have a small executable which just sets nothing in metadata apart from the sandbox engine
<emersion>
and runs the client inside
<jadahl>
make the instance id some unique nonsense string then, e.g. sandbox_engine + current_time + pid
<jadahl>
it'll be as unverifiable as if you didn't pass anything
<emersion>
well if we allow clients to use dup instance IDs then i'll just do that instead
<jadahl>
what should be predictable, anyhow, is that some sandbox engines will always/requires an instance id, and it can be assumed to be bogus if it isn't
<jadahl>
(or just always require it)
<emersion>
that's for your compositor to have this policy if it wants to
<emersion>
mine won't
<emersion>
please don't encode mutter policies in the protocol
<jadahl>
it's not mutter policy, it's what to know will be passed from e.g. flatpak
<emersion>
this is like saying in xdg-shell "btw gnome-calculator will always open a 200x200 window"
<jadahl>
i don't understand how that is remotely similar
<emersion>
encoding specific client impl behavior in a protocol
<jadahl>
emersion: that's not a useful comparison then. what I'm saying is that for for example flatpak, the only reason not to pass an instance id is either if you're only pretending to be flatpak, or if you're buggy, and that it should be specified in some way that doesn't result in surprises
<emersion>
specified, as in, in the protocol?
<emersion>
because that's what i understand by "specificed"
<emersion>
specified*
<jadahl>
sure. maybe we should outsource the specification to the sandbox engine in question, i dunno
<emersion>
right, so maybe flatpak docs would be good place for that
<emersion>
or just a .md in w-p
<jadahl>
a .md with per engine gotchas and meaning of the instance id field perhaps
<emersion>
that makes sense to me
<jadahl>
then we can just "link" to the .md in the spec