I think once you factor in the relay, the answer is clearly no, unless you are running a splinter network. Which makes this article feel a bit disingenuous to me.
i get it. i did try to carve that out as a caveat right at the top and make it clear that this was only addressing one of the two main cost critiques of atproto. it honestly took a lot of work for me to get it here, and the scope of this post was already a challenge for me to try to make cohesive.
that said i won’t argue but will push back on “clearly”, at least it’s not as obvious to me as it seems to be to you.
Christine’s post is fantastic! It’s linked from my post too, it’s great! I’ll add that it’s worth checking out her work on the Spritely Institute for really cool possible decentralized futures.
This is false, completely false, but repeated over and over and over and over and over and over and over again, then upvoted over and over and over again.
It can be fixed, and the Wayland developers said it can be fixed, they just didn’t want to.
And that’s a good enough reason. As far as I know, none of us are paying them for their work. Since we benefit from what they (or their employers) are freely giving, we have no right to complain.
I’m not an X11 partisan, it seems plausible enough that Wayland is a good idea, but you’re just begging the question that we’re benefiting from what they’re freely giving.
We’re using what they’re freely given, but it’s not guaranteed that we’re benefiting.
With the risk of engaging with someone who’s words read as an emotional defence…
What do you suppose the benefits of sticking with X.ORG were?
I know of no person who could reasonably debug it- even as a user, and the code itself had become incredibly complex over time, accumulating a vast array of workarounds.
The design (I’m told) was gloriously inefficient but hacked over time to be performant - often violating the principles in which it existed in the first place.
It also forced single-threaded compositing due to the client-server architecture…
Fixing these issues in X11 would have been incredibly disruptive, and they chose to do the python3 thing of a clean break, which must have been refreshing.
The “Hate” seems to be categorisable in a few ways:
“My global hotkeys don’t work” - which, is something your window manager should have had a say in, not any random program.
“Screensharing is broken” - which, hasn’t been an issue in 7 years, with the xdg-portal system.
“My program does not support wayland”; which is odd, because every UI toolkit supports it, exception: Java’s old SWIG, but even that supports it for 3 years now, waiting for projects to get on board.
“It has bugs”; like all software, it matures over time. It has made tremendous strides in recent years and is very mature today.
“X11 wasn’t broke”; but it was broke, the authors said as such based on what I said above.
“Wayland is a black box”; this, is probably the only truly fair criticism of all the online vitriol that I see. It works more often out of the box without any tweaking or hacks by distro makers, but, when it doesn’t work, it’s completely opaque. I levy this same criticism against systemd.
Do you have something else to add to this list, or do you think I’ve mischaracterised anything?
What do you suppose the benefits of sticking with X.ORG were?
It just works for tons of people. X runs the software I want it to run, and it does it today. Wayland does not.
I think I could make it work with probably hundreds of hours of effort but…. why? I have better things to do than run on the code treadmill.
I know of no person who could reasonably debug it
I’ve encountered one bug in X over the last decade. I make a repro script, git cloned the x server, built it, ran my reproduction in gdb, wrote a fix, and submitted it upstream in about 30 minutes of work. (Then subsystem maintainer Peter Hutterer rewrote it since my fix didn’t get to the root cause of the issue, my fix was to fail the operation when the pointer was null, his fix ensured the pointer never was null in the first place. So the total time was more than the 30 mins I spent, but even if my original patch was merged unmodified, it would have solved the issue from my perspective.)
After hearing all the alleged horror stories, I thought it’d be harder than it was! But it wasn’t that bad at all. Maybe other parts of the code are worse, I don’t know. But I also haven’t had a need to know, since it works for me (and also for a lot of other people).
Also important to realize that huge parts of the X ecosystem are outside the X server itself. The X server is, by design, hands off of a lot decisions, allowing independent innovation. You can have a major, meaningful contribution to the core user experience without ever touching the core server code, by working on inter-client protocols, window managers, input methods, toolkits, compositors, desktop panels, etc., etc., etc.
clean break, which must have been refreshing.
Every programmer likes the idea of a clean break. Experienced programmers usually know that the grass might be greener now if you rip out Chesterson’s fence, but it won’t stay that way for long.
With all the posturing you’d think someone would have stepped up to maintain it;
Like I said before, I had one issue with it recently, last year, and the bug report got a quick reply and it was fixed.
I don’t know what you expect from an open source maintainer, but replying promptly to issues, reviewing and merging merge requests, and fixing bugs is what I expect from them. And that’s what I got out of the upstream X team, so I can’t complain. Maybe I’m the lucky one, idk, but worst case, if it does ever actually get abandoned, yeah, compiling it was way easier than I thought it would be, so I guess I could probably do it myself. But as of this writing, there’s no need to.
I know of no person who could reasonably debug it- even as a user, and the code itself had become incredibly complex over time, accumulating a vast array of workarounds.
Yes, I remember looking at the code of xinit (that is supposed to be a small shell script just to start the X server) and it was… bad to say the least. I also had some experience implementing a protocol extension (Xrandr) in python-xlib and while I was surprised it worked first try with me just following the X11 documentation at the time, it was really convoluted to implement even including the fact that the code base of python-xlib already abstracted a lot for me.
I don’t know if I designed a replacement of X.org it would like Wayland, I think the least X.org needed was a full rewrite with lots of testing, but it wouldn’t happen considering even the most knowledge people in its codebase don’t touch parts of it because of fear. If anything, Wayland is good because there are people that have entusiasm hacking its code base and constantly improving it, something that couldn’t be said about X.org (that even before Wayland existed, had a pretty slow development).
I think a lot of the hate happens because “it has bugs” magnifies every other complaint.
The xdg-portal system certainly addresses things like screensharing on a protocol level. But pretty much every feature that depends on it – screen sharing, recording etc. – is various kinds of broken at an application level.
E.g. OBS, which I have to use like twice a year at most, currently plays a very annoying trick on me where it will record something in a Wayland session, but exactly once. In slightly different ways – under labwc the screen video input only shows up the first time, then it’s gone; on KDE it will produce a completely blank video.
I’m sure there’s something wrong with my system but a) I’ve done my five years of Gentoo back in 2005, I am not spending any time hunting bugs and misconfiguration until 2035 at the very least and b) that just works fine on X11.
If one’s goal is to hate Wayland, b) is juuuust the kind of excuse one needs.
I understand the frustration, but I was raised on X11 and these bugs sound extremely milquetoast compared to the graphical artifacting, non-starting and being impossible to debug, mesa incompatibility, proprietary extensions not driving the screen and the fucking “nvidia-xconfig” program that worked 20% of the time.
X11 is not flawless either, we got better at distro maintainers handling various hacks to make it function well enough- especially out of the box, but it remains one of the more brittle components of desktop linux by a pretty wide margin.
Oh, no, I’m not disagreeing, that was meant as a sort of “I think that’s why Wayland gets even more hate than its design warrants”, not as a “this is why I hate Wayland”. I mean, I use labwc, that occasional OBS recording is pretty much the only reason why I keep an X11 WM installed.
I’m old enough for my baseline in terms of quirks to be XFree86, nvidia-xconfig felt like graduating from ed to Notepad to me at some point :-D.
But then they’d be maintaining this new model and the rest of X.Org, which the maintainers could not do. It might not matter that it’s technically possible if it’s not feasible.
Wayland is the new model plus xwayland so that the useful parts of X11 keep working without them having to maintain all the old stuff.
But then they’d be maintaining this new model and the rest of X.Org, which the maintainers could not do.
Again, provably false - they are maintaining the rest of X.Org, first like you said, xwayland is a thing… that’s all the parts they said were obsolete and wanted to eliminate! But also from the same FAQ link:
Why duplicate all this work?
Wayland is not really duplicating much work. Where possible, Wayland reuses existing drivers and infrastructure. One of the reasons this project is feasible at all is that Wayland reuses the DRI drivers, the kernel side GEM scheduler and kernel mode setting. Wayland doesn’t have to compete with other projects for drivers and driver developers, it lives within the X.org, mesa and drm community and benefits from all the hardware enablement and driver development happening there.
A lot of the code is actually shared, and much of the rest needs very little work. So compared to what is actually happening today, not developing Wayland would have been less maintenance work, not more. All that stuff in the kernel, the DRI stuff, even the X server via xwayland, is maintained either way. Only difference is now they’ve spent 15 years (poorly) reinventing every wheel to barely regain usability parity because it turns out most the stuff they asserted was useless actually was useful and in demand.
I like to say Graphics are, at best, 1/3 of GUI. OK, let’s assume you achieved “every frame is perfect”. You still have a long way to go before you have a usable UI.
That’s like saying that we are maintaining both English and German language. Who are “they”? And X is very much in life support mode only - take a look at the commit logs.
XWayland is much smaller than the whole of X, it’s just the API surface necessary to keep existing apps working. That’s like saying that a proxy is a web browser..
Code sharing:
The DRM subsystem and GPU code is “shared”, as in it is properly modularized in Linux and both make use of it. If anything, Wayland compositors make much better use of the actual Linux kernel APIs, and are not huge monoliths with optional proprietary binary blobs. It’s pretty trivial to write a wayland compositor from scratch with no external libraries at all - where is the shared X code?
There’s also backends for other X servers (xnest), Macs (xquartz), Windows (xwin), and, of course, the big one for physical hardware (xfree86, which is much smaller than it used to be - over 100,000 lines of code were deleted from there around 2008 - git checkout a commit from 2007 and find … 380k lines according to a crude find | wc for .c files, git checkout master and find 130k lines by the same measure in that hw/xfree86 folder. Yeah, that’s still a lot of code, but much less than it was, because yes, some if it was simply deleted, but also a lot of it was moved - so nowadays both the X server and Wayland compositors can use it).
But outside of the hw folder, notice how much of the X server core code is shared among all these implementations, including pretty much every user-facing api and associated implementation bookkeeping in the X server.
XWayland not only is a whole X server, it is a build of the same X.org code.
“Maintaining” can mean different things. The X server is “maintained” in the sense that it’s kept working for the benefit of XWayland, but practically nobody is adding new features any more. Not having to maintain the “bare metal” backend also removes a lot of the workload in practice.
This is a much simpler and less work than continuing to try to add features to keep the X protocol up to date with the expectations of a modern desktop.
In other words, yes, the X server is maintained, in the sense that it’s in maintenance mode, but there’s very little active development outside of XWayland-specific stuff.
If you look at the Git tags on that repo, you’ll see that XWayland is also on a completely different release cadence now, with a different version number and more frequent releases. So even though it’s the same repo, it’s a different branch.
XWayland is not a mandatory part of the Wayland protocol, though. Of course they chose the easiest/most compatible way to implement the functionality, which will be to build on the real thing, but it’s a bit dishonest on your part to say that an optional part, meant to provide backwards compatibility, could be considered “shared code”.
I have to admit that I don’t know much about X.Org’s internals, but I think a lot of that stuff extracted to libraries and into the kernel is in addition to, not replacing, the old stuff.
For example X.Org still has to implement its own modesetting in addition to KMS. It has to support two font systems in addition to whatever the clients use. It has to support the old keyboard configuration system andlibxkbcommon. It has to support evdev and libinput. It has to implement a whole graphics API in addition to kernel DRM.
Wayland can drop all this old stuff and just use the new. Xwayland isn’t X.Org, I don’t think it has to implement any of this. It’s “just” a translation layer for the protocol.
not developing Wayland would have been less maintenance work, not more.
Please be careful about assuming what somebody else will find easy / less work. If the maintainers said they can’t support it anymore, I’m inclined to believe them. Sometimes cutting your losses is the easier option.
Only difference is now they’ve spent 15 years (poorly) reinventing every wheel to barely regain usability parity because it turns out most the stuff they asserted was useless actually was useful and in demand.
I think this is unfair to people working on Wayland. I know you don’t like it, but It’s an impressive project that works really well for many people.
I don’t think anybody was “asserting [features] are useless”, they just needed the right person to get involved. I’m assuming you mean things like screen sharing, remote forwarding, and colour management. People do this work voluntarily, it might not happen immediately if at all, and that’s fine.
XWayland does have to implement all the font/drawing/XRender/etc. stuff, since X11 clients need that to work. That’s part of its job as a “translation” layer.
(I should know, Xorg/XWayland does some unholy things with OpenGL in its GLAMOR graphics backend that no other app does, and it has tripped up our Apple Mesa driver multiple times!)
But the most important part is that XWayland doesn’t have to deal with the hardware side (including modesetting, but also multi screen, input device management, and more), which is where a lot of the complexity and maintenance workload of Xorg lies.
The core Wayland protocol is indeed just buffer exchange and update based on a core Linux subsystem. It’s so lean that it is used in car entertainment systems.
And HTTP 1.0 is another protocol, that can also be added to other programs. They are pretty trivial, obviously they can be incorporated into X. I can also attach an electric plug to my water plumping, but it wouldn’t make much sense either. Having two ways to do largely overlapping stuff, that will just overstep each other’s boundaries would be bad design.
Wayland has a ready-made answer to “every frame is perfect” – adding that to X would just make some parts of a frame perfect. Wayland also supports multiple displays that have different DPIs, which is simply not possible at all in X.
GPUs weren’t even a thing when X was designed - it had a good run, but let it rest now. I really don’t support reinventing the wheel unnecessarily, that seems all too common in IT, but there are legitimate points where we have to ask if we really are heading in the direction we want to go. It is the correct decision in case of X vs Wayland, as seen by the display protocols of literally every other OS, whose internals are pretty similar to it.
EDIT: I posted a video comparison in this comment because I’m tired of arguing in text about something that is obvious when you see it in real life. X11 and Wayland are not the same, and only Wayland can seamlessly handle mixed DPI.
We already went over this in another thread here in the past. X11 does not implement different DPIs for different monitors today, and it doesn’t work out of the box (where you say “janky”, what you really mean is “needs manual hacks and configuration and cannot handle hotplug properly”).
Even if you did add the metadata to the protocol (which is possible, but hasn’t been done), it’s only capable of sudden DPI switching when you move windows from one screen to another.
X11 cannot do seamless DPI transitions across monitors, or drawing a window on two monitors at once with the correct DPI on both, the way macOS and KDE Wayland can, because its multi-monitor model, which is based on a layout using physical device pixels, is incompatible with that. There’s no way to retroactively fix that without breaking core assumptions of the X11 protocol, which would break backwards compatibility. At that point you might as well use Wayland.
The links posted by @adam_d_ruppe are good, but I think the oldest post talking about it is oblomov’s blog post. He even had patches that implement mixed DPI for GTK on X11, but obviously the GTK folks would never merge something that would improve their X11 backend (mind you, they are still stuck on xlib).
It gets even funnier, because proper fractional mixed DPI scaling was possible in X11 long before Wayland got the fractional scaling protocol, so there was ironically a brief period not long ago where scaling was working better in XWayland than in native Wayland (that particular MR was a prime example of Wayland bikeshedding practice, being blocked for an obnoxious amount of time mostly because GTK didn’t even support fractional scaling itself, even quite some time after the protocol was added).
X11 cannot do seamless DPI transitions across monitors
Yes it can and it works ootb with any proper toolkit (read: not GTK) and renders at the native DPI of each monitor switching seemlessly inbetween. We don’t even have to lock ourselfes to Qt, even ancient toolkits like wxWidgets support it.
drawing a window on two monitors at once with the correct DPI on both
This doesn’t work, neither on Wayland nor X11 and not a single major toolkit supports this usecase and for good reason, the complexity needed would be insane and you can forget basically about any optimizations across the whole rendering stack.
Also the whole usecase is a literal edge case in its own rights, I don’t think many people are masochist enough to keep a window permanently on the edge of different-DPI monitors for a long time.
the way macOS and KDE Wayland can
It doesn’t work on KDE Wayland the way you think it does, you get the same sudden switch as soon as you move more than half over to the other monitor. If you don’t believe me, try setting one monitor to a scale factor that corresponds to a different physical size. Obviously you will not notice any sudden DPI changes if the scale factors end up as the same physical size, but that works in X11 too.
At this point the only difference is that X11 does not have native per-window atoms for DPI, so every toolkit adds their own variables, but that hardly makes any difference in practice. And to get a bit diabolical here, since Wayland is so keen on shoehorning every usecase they missed (i.e. everything going beyond a basic Kiosk usecase) through a sideband dbus API, wp-fractional-scale-v1 might as well have become a portal API that would have worked the same way on X11.
After a decade of “Wayland is the future” it is quite telling that all the Wayland arguments are still mostly based on misconceptions like this (or the equally common “the Wayland devs are the Xorg devs” - not realizing that all of the original Wayland devs have long jumped the burning ship), while basic features such as relative-window positioning or god forbid I mention network transparency are completely missing.
I’m tired of pointless arguing, so here’s a video. This is what happens on X11, with everything perfectly manually configured through environment variables (which took some experimentation because the behavior wrt the global scale is a mess and unintuitive):
In both tests the screen configuration, resolution, relative layout (roughly*), and scale factors are the same (1.5 left, 2.0 right).
These two videos are not the same.
I guess I should also point out the tearing on the left display and general jank in the X11 video, which are other classic symptoms of how badly X11 works for some systems. This is with the default modesetting driver, which is/was supposed to be the future of X11 backends and is the only one that is driver-independent and relies on the Linux KMS backend exclusively, but alas… it still doesn’t work well. Wayland doesn’t need hardware-specific compositor backends to work well.
Also, the reason why I used a KDialog window is that it only works as expected with fixed size windows. With resizeable windows, when you jump from low scale to high scale, the window expands to fit the (now larger) content, but when you jump back, it keeps the same size in pixels (too large relative to the content now), which is even more broken. That’s something that would need even more window manager integration to make work as intended on X11. This is all a consequence of the X11 design that uses physical pixels for all window management. Wayland has no issue since it deals in logical/scale-independent units only for this, which is why everything is seamless.
Also, note how the window decorations are stuck at 2.0 scale in X11, even more jank.
* X11 doesn’t support the concept of DPI-independent layout of displays with different DPI, so it’s impossible to literally achieve the same layout anyway. It just works completely differently.
Funnily enough on my system the KDE Wayland session behaves exactly like what you consider so broken in the X11 session.
There is a lot to unpack here, but let’s repeat the obvious since you completely ignored my comment and replied with basically a video version of “I had a hard time figuring out the variables, let’s stick with the most broken one and just dump it as a mistake of X11”: What’s happening in the Wayland session is most certainly not what you think it is, Qt (or any toolkit for that matter) is not capable of rendering at multiple DPIs at the same time in the same window. As I stated before, something like that would require ridiculous complexity in the entire render path. Imagine drawing an arc somewhere in a low-level library and you suddenly have to change all your math, because you cross a monitor boundary. Propagating that information alone is a huge effort and let’s not even start with more advanced details, like rotated windows.
The reason why you see no jump in the Wayland session is because you chose the scaling factor quite conveniently so that it is identical in physical size on both monitors (and that would work on X11 too). Instead of doubling down, it would have taken you 5 seconds to try out what I suggested, i.e. set one of the scale factors to one with a different physical size (maybe 1.0 left, 2.0 right) and you will observe that indeed also Wayland cannot magically render at different DPIs at the same time and yes you will observe those jumps.
Now obviously your scaling factors of 1.5 vs 2.0 should produce the same result on X11. I don’t know your exact configuration, so I can only reach to my magic crystal ball, but since you already said you had a hard time figuring out the variables, a configuration error is not far fetched: Maybe you are applying scaling somewhere twice, e.g. from leftover hacks with xrandr scaling or hardcoding font DPI, or kwin is interfering in a weird way (set PLASMA_USE_QT_SCALING to prevent that). But honestly, given that you start your reply with “Sigh” and proceed to ignore my entire comment, I don’t think you are really interested in finding out what was wrong to begin with. If you are though, feel free to elaborate.
In my case I have the reverse setup of yours, i.e. my larger monitor is 4k and my laptop is 1080p, so I apply the larger scale factor to my larger screen (I don’t even know my scaling factors, I got lucky in the EDID lotto and just use QT_USE_PHYSICAL_DPI). So yes this means also on Wayland I get the “jump” once a window is halfway over to the next monitor. The size explosions are not permanent as you say though, neither on Wayland nor on X11.
What’s happening in the Wayland session is most certainly not what you think it is, Qt (or any toolkit for that matter) is not capable of rendering at multiple DPIs at the same time in the same window.
She obviously doesn’t think that that is what’s happening. In the comment you yourself linked, she explains how it works:
KWin Wayland is different. It arranges monitors in a logical coordinate space that is DPI-independent. That means that when you move a window from a 200 scale monitor to a 150 scale monitor, it’s already being scaled down to 150 scale the instant it crosses into the second monitor, only on that monitor. This doesn’t require applications to cooperate in any way, and it even works for X11 applications with XWayland, and has worked that way for over two years. Windows never “jump” size or appear at the wrong DPI, partially or fully, on any monitor. It’s completely seamless, like macOS.
What you need application cooperation for is to then adjust the window buffer scale and re-render the UI to optimize for the monitor the window is (mostly) on. That’s more recent functionality, and only works for Wayland apps that implement the fractional scaling protocol, not X11 apps. For X11 apps on XWayland, KWin chooses the highest screen scale, and scales down on other screens. The only visual difference is that, for Wayland apps with support, the rendering remains fully 1:1 pixel perfect and sharp once a window is moved to a new screen. The sizing behavior doesn’t change.
With this correct understanding, we can see that the rest of your comment is incorrect:
The reason why you see no jump in the Wayland session is because you chose the scaling factor quite conveniently so that it is identical in physical size on both monitors (and that would work on X11 too). Instead of doubling down, it would have taken you 5 seconds to try out what I suggested, i.e. set one of the scale factors to one with a different physical size (maybe 1.0 left, 2.0 right) and you will observe that indeed also Wayland cannot magically render at different DPIs at the same time and yes you will observe those jumps.
I just tried using the wrong DPI and there was no jump (I’m on Sway). On on screen, the window I moved was much bigger, and on the other, it was much smaller. But it never changed in size. The only thing that changed was the DPI it was rendering it, while seamlessly occupying the exact same space on each monitor as it did so. This works because Wayland uses logical coordinates instead of physical pixels to indicate where windows are located or how big they are. So when a window is told to render at a different scale, it remains in the same logical position, at the same logical size.
There is a noticeable change, but it’s just the rendering scale adjustment kicking in causing the text on the monitor the window is being moved into to become pixel sharp, and the text in the old monitor getting a bit of a blur.
This changed a few years ago to allow per-display spaces (what Linux calls “workspaces”) - presumably they decided they didn’t want to deal with edge cases where a window is on an active space on one monitor and an inactive space on another. (Or what happens if you move a space containing half a window across monitors?)
You can get the old behavior back by turning off Settings > Desktop & Dock > Mission Control > Displays have separate spaces.
I’m tired of arguing in text about something that is completely obvious when you see it in real life.
Indeed - the fact that it does actually work, albeit with caveats, proves that it is, not, in fact, “simply not possible at all”.
We can discuss the pros and cons of various implementations for various use cases, there’s legitimate shortcomings in Qt and KWin, some of which are easy to fix* (e.g. the configuration ui, the hotplugging different configurations), some are not (the window shape straddling monitor boundaries), there’s some advantages so it too (possibly better performance and visual fidelity), but a prerequisite to a productive technical discussion is to do away with the blatant falsehoods that universally start these threads.
“You can do it, but….” is something reasonable people can discuss.
“It is simply not possible at all” is provably flat-out false.
I know these are easy to fix because they do work on my computer with my toolkit. But I prefer to work in verifiable primary sources that interested people can try for themselves - notice how most my comments here have supporting links - and Qt/KDE is mainstream enough that you can try it yourself, likely using programs you already have installed, so you don’t have to take my word for it.
I appreciate that you’ve now tried it yourself. I hope you’ll never again repeat the false information that it is impossible.
The use of quote marks here implies that the commenter you’re replying to used this exact term in their comment, but the only hit for searching the string is your comment.
I’m flagging this comment as unkind, because my reading of this and other comments by you in this thread is that you are arguing in bad faith.
The use of quote marks here implies that the commenter you’re replying to used this exact term in their comment, but the only hit for searching the string is your comment.
Try not to accuse people of personal attacks - which is itself a personal attack, you’re calling me an unkind liar - without being damn sure you have your facts right.
That’s a different person. The person you replied to did not say that.
This is what the person you replied to actually said:
X11 cannot do seamless DPI transitions across monitors, or drawing a window on two monitors at once with the correct DPI on both, the way macOS and KDE Wayland can, because its multi-monitor model, which is based on a layout using physical device pixels, is incompatible with that.
Looking at the two videos it’s pretty obvious that they are not doing the same thing at all. That dialog window is not being drawn with the correct DPI on each monitor, it’s either one or the other. “Mixed” is sufficiently elastic a word that I’m sure some semantic tolerance helps but I’m not exactly inclined to call that behaviour “mixed”, just like I also can’t point at the bottle of Coke in my fridge, the stack of limes in my kitchen and the bottle of rum on my shelf and claim that what I actually have is a really large Cuba Libre. (Edit:) I.e. because they’re not mixed, they’re obviously exclusive.
I don’t know if that’s all that X11 can do, or if it’s literally impossible to achieve what @lina is showing in the second video – at the risk of being an embarrassment to nerddom everywhere I’ve stoped caring a few years back and I’m just happy if the pixels are pixeling. But from what I see in the video, that’s not false information at all.
100% the same thing as Wayland is impossible in X. It can’t handle arranging mixed DPI monitors in a DPI-independent coordinate space, such that rendering is still pixel perfect on every monitor (for windows that don’t straddle monitors). X11 has no concept of window buffer scale that is independent of window dimensions.
The closest you can get is defining the entire desktop as the largest DPI and all monitors in that unit, then having the image scaled down for all the other monitors. This means you’re rendering more pixels though, so it’s less efficient and makes everything slightly blurry on the lower DPI monitors. It’s impossible to have pixel perfect output of any window on those monitors in this setup, and in practice, depending on your hardware, it might perform very poorly. It’s basically a hacky workaround.
This is actually what XWayland fakes when you use KDE. If you have mixed DPI monitors, it sets the X11 DPI to the largest value. Then, in the monitor configuration presented via fake XRandR to X11 clients, all monitors with a lower DPI have their pixel dimensions scaled up to what they would be at the max DPI. So X11 sees monitors with fake, larger resolutions, and that allows the relative layout to be correct and the positioning to work well. If I had launched KDialog under KDE Wayland with the backend forced to X11, it would have looked the same as Wayland in the video in terms of window behavior. It also wouldn’t have any tearing or glitches, since the Wayland compositor behind the scenes is doing atomic page flips for presentation properly, unlike Xorg. The only noticeable difference would have been that it’s slightly less sharp on the left monitor, since the window would be getting downscaled there.
That all works better than trying to do it in a native X11 session, because XWayland is just passing the window buffers to Wayland so only the X11 windows get potentially scaled down during compositing, not the entire screen.
Where it falls apart is hotplug and reconfiguration. There’s no way to seamlessly transition the X11 world to a higher DPI, since you have to reset all window positions, dimensions, monitor dimensions and layout, and client DPI, to new numbers. X11 can’t do that without glitches. In fact, in general, changing DPI under X11 requires restarting apps for most toolkits. So that’s where the hacky abstraction breaks, and where the proper Wayland design is required. X11 also doesn’t have any way for clients to signal DPI awareness and can’t handle mixed DPI clients either, so any apps that aren’t DPI aware end up tiny (in fact, at less than 1.0 scale on monitors without the highest DPI). This affects XWayland too and there’s no real way around it.
At best, in XWayland, you could identify which clients aren’t DPI aware somehow (like manual user config) and give them a different view of the X11 world with 1.0 monitor scales. That would mostly work as long as X11 windows from both “worlds” don’t try to cooperate/interact in some way. KDE today just gives you two global options, either what I described or just always using 1.0 scale for X11 (which makes everything very blurry on HiDPI monitors, but all apps properly scaled).
The closest you can get is defining the entire desktop as the largest DPI and all monitors in that unit, then having the image scaled down for all the other monitors [without hotplug or per-client DPI awareness].
That’s what I thought was happening, too, but I wasn’t really sure if my knowledge was up-to-date here. Like I said, I’m just happy if my pixels are pixeling, and I didn’t want to go down a debate where I’d have to read my way through source code. This end of the computing stack just isn’t fun for me.
I’m not exactly inclined to call that behaviour “mixed”,
This isn’t a term we invented in this thread, it is very common, just search the web for “mixed dpi” and you’ll find it, or click the links elsewhere in this thread and see how it is used.
A blog posted in a cousin comment sums it up pretty well: “A mixed-DPI configuration is a setup where the same display server controls multiple monitors, each with a different DPI.”
(DPI btw formally stands for “dots per inch”, but in practice, it refers to a software scaling factor rather than the physical size because physical size doesn’t take into account the distance the user’s eyes are from the display. Why call it DPI then? Historical legacy!)
Or, if that’s too far, go back to the grandfather post that spawned this very thread:
Wayland also supports multiple displays that have different DPIs, which is simply not possible at all in X.
“displays that have different DPIs”, again, the common definition spelled out.
What, exactly, happens when a window straddles two different monitors is implementation-dependent. On Microsoft Windows and most X systems, the window adopts the scaling factor for the monitor under its center point, and uses that across the whole window. If the monitors are right next to each other, this may cause the window to appear non-rectangular and larger on one monitor than the other. This is satisfactory for millions of people. (I’d be surprised if many people actually commonly straddle windows between monitors at all, since you still have the screen bezel at least right down the middle of it… I’d find that annoying. It is common for window managers to try to snap to monitor boundaries to avoid this, and some versions of Apple MacOS (including the Monterey 12.7.6 I have on my test computer) will not even allow you to place a window between monitors! It makes you choose one or the other.)
edit: just was reminded of this comment: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_1f0zhn and yes that setting is available on my mac version, but it requires a log out and back in. woof. not worth it for a demo here, but interesting that Apple apparently also saw fit to change their default behavior to prohibit straddling windows between monitors! They apparently also didn’t see much value in this rare use case. /edit
On Apple operating systems and most (perhaps all?) Wayland implementations… and some X installs, using certain xrandr settings (such as described here https://blog.summercat.com/configuring-mixed-dpi-monitors-with-xrandr.html), they do it differently: the window adopts the highest scaling factor the window appears on (or is present in the configuration? tbh im not exactly sure), using a virtual coordinate space, then the system downscales that to the target area on screen. This preserves its rectangular appearance - assuming the monitors are physically arranged next to each other and the software config mirrors that physical arrangement… and the OS lets you place it there permanently (but you can still see it while dragging at least) - but has its own trade offs; it has a performance cost and can lose visual fidelity (e.g. blurriness), especially if the scale factors are not integer multiples of each other, but sometimes even if they are because the application is drawing to a virtual screen which is scaled by a generic algorithm with limited knowledge about each other.
In all these cases, there is just one scale factor per window. Doing it below that level is possible, but so horribly messy to implement, massive complexity for near zero benefit (again, how often do people actually straddle windows between monitors?), so nobody does it irl. The difference is the Mac/Wayland approach makes it easier to pretend this works… but it is still pretending. The illusion can be pretty convincing a lot of the time though, like I said in that whole other lobsters link with lina before, I can understand why people like this experience, even if it doesn’t matter to me.
The question isn’t if the abstraction leaks. It is when and where it leaks.
This isn’t a term we invented in this thread, it is very common, just search the web for “mixed dpi” and you’ll find it, or click the links elsewhere in this thread and see how it is used.
I tried to before posting that since it’s one of those things that I see people talking past each other about everywhere, and virtually all the results I get are… both implementation-specific and kind of useless, because the functional boundary is clearly traced somewhere and different communities seem to disagree on where.
A single display server controlling multiple monitors, each with the same DPI is something that X11 has basically always supported, I’m not sure how that’s controversial. Even before Xinerama (or if your graphics card didn’t work with Xinerama, *sigh*) you could always just set up two X screens, one for each monitor. Same display server, two monitors, different DPIs – glorious, I was doing mixed DPI before everyone was debating it, and all thanks to shitty S3 drivers and not having money to buy proper monitors.
But whenever this is discussed somewhere, it seems that there’s a whole series of implicit “but also” attached to it, having to do with fractional scaling, automatic configuration, what counts as being DPI-aware and whatnot.
So it’s not just something we invented in this thread, it’s something everyone invents in their own thread. In Windows land, for example, where things like getting WM_DPICHANGED when the window moves between monitors are a thing, you can query DPI per window, and set DPI awareness mode per thread, I’m pretty sure you’ll find developers who will argue that the xrandr-based global DPI + scaling system we’ve all come to know and love isn’t mixed-DPI, either.
(Edit:) To be clear – I haven’t used that system in a while, but as I recall, the way it worked was it set a global DPI, and you relied on the display server for scaling to match the viewports’ sizes. There was no way for an application to “know” what DPI/scaling factor combination they were working with on each monitor so they could adjust their rendering for whatever monitor they were on (for their implementation-defined definition of on, “on”, sure – midpoint, immediate transition, complete transition, whatever). Toolkits tried to shoehorn that in, but that, too, was weird in all sorts of ways and assumed a particular setup, at least back in 2016-ish or however long ago it was.
I’m pretty sure you’ll find developers who will argue that the xrandr-based global DPI + scaling system we’ve all come to know and love isn’t mixed-DPI, either.
Well, I wouldn’t call that not mixed dpi, but I would call it suboptimal. So it seems you’re familiar with the way it works on Windows: move between monitors or change the settings in display properties, and the system broadcasts the WM_DPICHANGED message to top level windows that opted into the new protocol. Other windows are bitmap scaled to the new factor, as needed.
Applications use the current DPI for their monitor in their drawing commands - some of this is done automatically by the system APIs, others you multiply out yourself. You need to use some care not to double multiply - do it yourself, then the system api does it again - so it is important to apply it at the right places.
Your window is also automatically resized, as needed, as it crosses scaling boundaries, by the system.
Qt/KDE tries to apply similar rules… but they half-assed it. Instead of sending a broadcast message (a PropertyChange notification would be about the same in the X world), they settled for an environment variable. (The reason I know where that is in the source is that I couldn’t believe that’s the best they did…. for debugging, sure, but shipping that to production? Had to verify but yes, that’s what they shipped :( the XWAYLAND extension has proposed a property - see here https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197 - but they couldn’t agree on the details and dropped it, alas) There’s also no standard protocol for opting out of auto scaling, though I think XWAYLAND proposed one too, I can’t find that link in my browser history so I might be remembering wrong.
The KDE window manager, KWin, tries to apply scale as it crosses monitor boundaries right now, just like Windows does, but it seems to only ever scale up, not back down. I don’t know why it does this, could be a simple bug. Note that this is KWin’s doing, not Qt’s, since the same application in a different window manager does not attempt to resize the window at all, it just resizes the contents of the window.
But, even in the half-assed impl, it works; the UI content is automatically resized for each monitor’s individual scale factor. User informs of each monitor’s scale factor, either by position or by port name (again, half-assed, it should have used some other identifier which would work better with hotplugging, but does still work). If a monitor configuration changes, xrandr sends out a notification. The application queries the layout to determine which scaling factor applies to which bounding box in the coordinate space, then listens to ConfigureNotify messages from the window manager to inform them of where they are. Quick check of rectangle.contains(window_coordinate) tells it what scale it has, then this fires off the internal dpi changed event, if necessary. At this point, the codepaths between X and Windows merge as the toolkit applies the new factor. At this point, the actual scaling is done client side, and the compositor should not double scale it… but whether this works or not is hit and miss, since there’s no standardization! (The one nice thing about xwayland is they’re finally dismissing the utter nonsense that X cannot do this and dealing with reality - if the standard comes from wayland, i don’t really care, i just want something defined!)
A better way would be if the window manager sent the scale factor as a ClientMessage (similar to other EMWH messages) as it crosses the boundary, so the application need not look it up itself, which would also empower the user (through the window manager) to change the scale factor of individual windows on-demand - a kind of generic zoom functionality - and to opt some individual windows out of automatic bitmap scaling, even if the application itself isn’t written to support it. I haven’t actually implemented this in my window manager or toolkit; the thought actually just came to mind a few weeks ago in the other thread with lina, but I’d like to, I think it would be useful and a nice little innovation.
As a practical matter, even if the window manager protocol is better, applications would probably still want to fallback to doing it themselves if there is no window manager support; probably query _NET_SUPPORTED, and if absent, keep the DIY impl.
None of this is at all extraordinary. Once I implement mine, I might throw it across the freedesktop mailing list, maybe even the xwayland people, to try to get some more buy-in. Working for me is great - and I’ll take it alone - but would be even nicer if it worked for everybody.
If a framework has to go way out of its way to implement some hack to make it work despite X’s shortcomings, but all the other frameworks don’t support it at all, then X simply doesn’t support this feature.
I want to preface this by saying: 1) I run neither X nor Wayland 99% of the time; the kernel’s framebuffer is usually enough for my personal needs; 2) it’s been months since I tried Wayland on any hardware.
That said, the one thing I seemed to notice in my “toe dip” into the Wayland world was pretty problematic to me. When I would start X to run some graphical config tool on a remote machine with no GPU and low-power CPU, it seemed to me that “ssh -X” put almost no load on the remote computer; however, attempting to run the same via waypipe put a lot of load on the remote machine, making it essentially unusable for the only things I ever needed a graphical interface for.
If I’ve incorrectly understood the root cause here, I’d love to have someone explain it better. While I don’t use either one very often, it’s clear that X11 is not getting the development resources wayland is, and I’d like to be able to continue using my workflow decades into the future…
The primary reason for Wayland was the security model, was it not? That I believe is truly unfixable. And if you’ve decided to prioritize that, then it makes sense to stop working on X.
No, the primary reason for Wayland is, in Kristian Høgsberg’s words, the goal of “every frame is perfect”.
And even if security was the priority… X also “fixed” it (shortly before Wayland was born; X Access Control Extension 2.0 released 10 Mar 2008, Wayland initial release 30 September 2008), but it never caught on (I’d argue because it doesn’t solve a real world problem, but the proximate cause is probably that the XACE is all code hooks, no user-friendly part. But that could be solved if anybody actually cared.)
Worth noting that Microsoft had man of the same questions with Windows: they wanted to add a compositor, add elevated process isolation, per-monitor fractional scaling, all the stuff people talk about, and they successfully did it with near zero compatibility breaks, despite Win32 and X sharing a lot of functionality. If it were fundamentally impossible for X, it would have been fundamentally impossible for Windows too.
Security can’t be solved retroactively. You can’t plug all the holes of a swiss cheese.
“Solutions” were nesting X servers into one another and such, at that point I might as well run a whole other VM.
And good for windows, maybe if we would have the legacy X API available for use under Wayland, so that Wayland’s security benefits could apply, while also not losing decades of programs already written, we could also have that for linux.. maybe we could call it WaylandX! [1]
“Solutions” were nesting X servers into one another and such, at that point I might as well run a whole other VM
No they weren’t. X11 is a client-server protocol. The only things that a client (app) sees are messages sent from the server (X.org). The default policy was that apps were trusted or untrusted. If they were untrusted, they couldn’t connect to the server. If they were trusted, they could do anything.
The security problems came from the fact that ‘anything’ meant read any key press, read the mouse location, and inspect the contents of any other window. Some things needed these abilities. For example, a compositing window manager needed to be able to redirect window contents and composite it. A window manager that did focus-follows-louse needed to be able to read all mouse clicks to determine which window was the current active one and tell the X server to send keyboard events there. A screenshot or screen sharing app needed to be able to see the rendered window or sceen contents. Generally, these were exceptions.
The X Access Control Extensions provided a general mechanism (with pluggable policies) to allow you to restrict which messages any client could see. This closed the holes for things like key loggers, while allowing you to privilege things like on-screen keyboards and screenshot tools without needing them to be modified. In contrast, Wayland just punted on this entirely and made it the compositor’s problem to solve all of these things.
For full documentation please check the manual pages.
Nothing wrong with that per se, but I’m wondering - if you stumble over that (and don’t see the (current) HTML version linked, like in this repo) - what do you typically do?
So far I’ve been at “sigh, then build the software and view them without installing” - but for people who don’t regularly package software or write manpages themselves… is there an easy way? a quick hack?
If you use NoScript for browsing, it’s infuriating how many websites that absolutely do not need JS render as blank pages. And if you active NoScript, well, they require a beefy CPU to move.
One of the offenders that rub me worst is Mastodon, because of its federated nature, adding NoScript exceptions is a pain. I kinda pondered contributing to some Mastodon client to be able to navigate through threads. (Tusky on Android kinda does this.) I don’t know it’s because my account is on a Takahe server, or if this happens to Mastodon users too, but I tend to get partial threads locally, which means if I want to reply, I’d better check the upstream thread to see if I’m repeating what someone already said.
I don’t know it’s because my account is on a Takahe server, or if this happens to Mastodon users too, but I tend to get partial threads locally, which means if I want to reply, I’d better check the upstream thread to see if I’m repeating what someone already said.
This is a known issue across most/all fedi implementations - the only messages you get in threads are messages that your instance holds for some other reason, for example because someone on your instance follows the author. There’s an outstanding PR to Mastodon upstream to explicitly fetch all replies, and I imagine in time the same approach will be duplicated by other implementations.
Interesting. I’ve not validated this, but sometimes Firefox shows me Reader Mode in what looks a blank page… and it works. It might be a symptom of this phenomenon.
The tech worker stuff I saw back in 2016-2017 was not compelling. When Macej came through town, he seemed more interested in riling us up to give donations to defeat Trump than to, you know, work on common issues like contracts.
During a stint in Brooklyn in 2019, I attended a TWC event (I think it was them, could’ve been somebody else) and was summarily unimpressed with the organizing efforts–least of all the amount of time spent by a Google contractor who, bless her heart, didn’t seem to understand that they weren’t actually there for her but for “real employees”. There was also a bunch of time wasted with the usual progressive genuflections.
For the past several years, I’ve had the pleasure of watching a CWA shop play out its bargaining from up close, and seen the slow disillusionment of the bargaining unit with the process–as a comrade noted after bouncing from the place, “having a union just means you get to help hold the knife when layoffs come”.
If I had to sum up many of my criticisms and observations (and this is heavily anchored in a US background):
In order for unions to be successful, you need broad appeal among your base. For whatever reason, the progressives in the US cannot peacefully coexist and form coalitions with more conservative fellow workers, and that is to the detriment of both factions when placed across from Capital.
For historical reasons, unions in the US are very, very different from unions in places like Germany or elsewhere. They are explicitly very political and if you read the limits and affordances on them it’s clear a lot of time is spent making sure they’re able to serve their other masters, the political party that they throw in with. This is not the same cause as helping the workers. (Were I a more cynical sock, I’d suggest that this is by design and a good way of rendering toothless what was once a more threatening hotbed of activism by the working-class socialist and anarchist.)
For historical reasons, conservative tech workers are actively propagandized against unionization and do not understand the history of how we got here, the potential benefits and tradeoffs for having or not having a union, and generally that their needs as workers could possibly be handled better via collective action than the luck-of-the-draw of their currently negotiated position.
For historical reasons–I suspect mainly that unions primarily formed in Democrat/progressive-leaning areas due to urbanization and where historical capital/factories were concentrated–the modern union organizers definitely and the members frequently have a set of political beliefs that are let us say inefficient in achieving the goals of a union. To wit: the purpose of a union is ultimately to get pro-worker treatment via a monopoly on labor…so, it is fundamentally incompatible with any sort of pro-immigrant or pro-globalization stance. This is awkward for tech workers, who as class lean progressive (arguably due to a previous position of privilege) and who are used to working in a space (as much as these days it is popular to trip over oneself to mock such libertarian ideals) free of the weary giants of flesh and steel that would afford the protectionism that empowers unions.
Nearly all of us rely on open-source software, again something which knows not borders. It is very difficult to be pro-open-source software while still maintaining the desired monopoly on labor.
There is negligible cost for reproduction for a lot of our software; if done properly, once a library solves an issue the library maintainer can disappear and we’ll all still benefit. This dynamic is not the same as for, say, a factory worker whose absence will be felt until filled. The issue this presents is: you can’t meaningfully control a labor supply when the outputs of the labor supplant that labor!
Many people who want to enter into a bargaining agreement don’t quite understand that there is actual bargaining that is going on–once a company’s management enters into these negotiations, they are going to seek concessions on everything possible (because it’s a negotiation, right?). Many first-time union people, bless their hearts, do not understand how negotiations work and will leave things on the table only to be dismayed later about their absence (I had to explain such fundamental concepts as BATNA to one set of folks, only to watch them get screwed on total comp because they didn’t understand how to value their profit share and equity).
Many people in the US who kick off a unionization process do not understand that they are casting Summon Bureaucracy III and that it will be a multi-year journey. Something like two-thirds of bargaining units do not have agreements in place after two years, and other figures I’ve seen are between 400-500 days. It’s a long, drawn-out process and in an industry where we have (had?) such high turnover, this can be hard to maintain.
For smaller firms, especially SMBs and (god-forbid) startups, the introduction of a bargaining unit creates all kinds of annoying issues for middle management. If you have a low performer, or a malicious worker, or even just somebody who needs a nudge in the right direction to get back on track, you suddenly need to consider how that all fits in with the union dynamics. In some cases–speaking from experience–this greatly complicates the ability to use a lighter touch and keep things out of documentation that could later be used against the employee. Again, the union implementation in the US is a bureaucratic and inherently adversarial one. During the time of negotiations, everything is under even a closer microscope and that is not always to the workers’ or company’s benefit!
Because a lot of the people in tech come from California, there’s a sort of baseline level of progress they assume and in their privilege fail to account for when interacting with folks elsewhere in the country–for example, non-competes are a constant source of worker oppression in our industry but I do not see that focused on nearly as much. Again as an example, when Macej came through he failed to address any of the (relatively straightforward, non-partisan) issues we faced as tech workers in Texas around things like non-competes, reasonable exercise windows, and so forth.
The unionization efforts I’ve seen in tech do not account for the fact that seniority in a position does not mean a good fit all the time. There is a constant evolutionary pressure for firms to employ the best and latest techniques, and in small firms and startups failure to do so is often a matter of life-or-death in the marketplace. Demanding that workers with more up-to-date skills be de-prioritized in favor of somebody with tenure works great until the company is eaten alive by other firms. I suspect a sufficiently clever union could address this issue via training requirements or whatever, but in practice I’ve seen this typically just turn into a jobs program. This is by design, but it does not work if there is actual competition from other firms (which there is, indeed there is a global marketplace for tech competition!).
In small firms in tech, there is less of a buffer with how close tech workers are to business factors. In a large factory stamping out car frames or windows, your assembly line worker can afford to be ignorant of the company’s position in the marketplace (and even if they couldn’t, there’s not a lot that Glue Station 3 second-shift can do about it). In a small tech company (at least according to our tribal legends) a few developers who really know the business can make all the difference in the world. At the same time, for the reasons listed above, pro-union techies tend to come with a lot of progressive baggage that makes it incredibly difficult to acknowledge fundamental truths about economics and the marketplace they engage in, which tends to have a deleterious effect. I have seen aspiring union workers actively proud that they are ignorant of business concerns that ultimately do things like pay for their negotiated healthcare or benefits packages (only to be surprised, surprised! when RIFs happen a year later).
For chrissake, please please please read about the perils of hotshops before you try to organize.
If I ever get my blog back up, I could write a small treatise on all of this.
To wit: the purpose of a union is ultimately to get pro-worker treatment via a monopoly on labor…so, it is fundamentally incompatible with any sort of pro-immigrant or pro-globalization stance.
What? Immigrant/offshore workers can act as scabs, of course, but I don’t see why this is a fundamental truth. Immigrants can be union workers too.
It’s not a fundamental truth. It’s cherry-picking of the most dysfunctional traits a union can have to build a strawman that is the easiest to shoot down and feel more intelligent about it.
Typed by an immigrant union organizer in a “Migrant Organizing Unit”.
Are you in the US, or elsewhere (as I gather from your profile)? I was pretty clear I was addressing the US operating regime–if you’re in Germany or whatever you have a different kettle of fish.
The de facto purpose of getting H1-B visas in the US is to have a captive workforce that can work more cheaply than native labor. If they cost the same to employers, I wager they wouldn’t be as attractive to hire. Here, go look for yourself–“some of these things are not like the others”, as one might say.
The de facto purpose of globalization is to export work processes to where it’s cheaper to have them occur, whether that’s due to avoiding expensive environmental regulations, expensive worker compensation, expensive resource extraction, or whatever else. If you are a union, you do not want your employer to get labor elsewhere.
I’m explaining this not to excuse any of it but to make sure anybody (in the US, again) who is looking at solving the puzzle knows more of the pieces and dynamics at play, and to encourage people to look past whatever easy ideology they likely to have have because they’re (comparatively) wealthy and in tech because it will fail them as times get rough (and times, they are getting rough).
If you want to make a useful contribution @chobeat instead of just sniping at me perhaps you could share your experience and background with a “Migrant Organizing Unit” and talk about what works, what doesn’t, and where they show up.
Not that I have any more experience with labor organization than yourself but unionism breaks into different strains and your conception of it is called business unionism, where a specific union exists solely to forward the narrow economic self-interest of its then-existing membership. Other conceptions of unionism include labor liberalism, where unions exist for workers as a class to more effectively lobby the state (which is the source of the association with dem party politics you saw) and also class struggle unionism, which takes an explicitly combative approach with capital and also involves the sort of “ideological baggage” you talk about. The latter tends to take a “workers of the world unite” type approach and does not inherently view immigrants or workers elsewhere as scabs. Whether this last strain actually makes any sense when operating from within the imperial core can certainly be debated. But anyway I’m not here to argue for one conception or the other, just to say that your conception of what a union is is not the only one. Most of the ideas in this post come from the book Class Struggle Unionism by Joe Burns.
The de facto purpose of getting H1-B visas in the US is to have a captive workforce that can work more cheaply than native labor. If they cost the same to employers, I wager they wouldn’t be as attractive to hire.
This is true, but I’m not sure how you get from there to “unions must be anti-immigrant”.
A union’s goal should be to get a collective agreement that covers immigrant workers too, so they’re no longer cheaper. Maybe that means they hire fewer immigrants (though I honestly don’t think there would be a noticeable effect in tech), but the immigrants they do hire would get much better working conditions, I’d call that pro-immigrant. I think immigrant workers would gladly sign on to that.
We are stronger together than apart. Your point about divisions along political alignment lines applies to division between citizens and immigrants, if we exclude them, we just set ourselves up to get scabbed on.
An immigrant who is established enough in their new country to be a union worker now also has an economic incentive to oppose further immigration from the place they originally came from, just as native workers in the same union do.
This isn’t true and the history of labour organising shows how excluding people on the basis of race, sex, nationality, homelessness, etc makes a union weaker. (E.g. IWW organising “hobos” in a logging industry dispute. Listen to Cool People Who Did Cool Stuff for more examples).
You may also be making the “lump of labour fallacy”.
I acknowledge your stated intentions here about inspiring people to adapt tactics. But this is not a forum where your coparticipants are union insiders with the power to make the kinds of changes you want.
The primary net impact of sucking up all the oxygen in a discussion space with a huge critique post like yours is going to be to dissuade potential new organisers from engaging. Instead of leading to the change you want to see, it’s more likely contributing to further entrenching the structures and strategies you dislike by depriving the labour movement of the new blood it depends on to refresh its thinking.
You seem pretty well read on this general topic. If you ever do get that blog post series written, I’d encourage you as a next step to consider ways of putting the ideas into practice through real organising. The labour movement has plenty of armchair generals who can tell you a million reasons why this or that aspect of how things are done is doomed to failure. As in any other field of endeavour, you earn your influence over the direction things take by the merits of your prior contributions. It’s unlikely for a Substack authored by someone who attended a TWC event in Brooklyn six years ago and knows some people at a place with a union deal is going to produce the outcomes you want to see on its own.
Because of the aforementioned adversarial nature of unions in the US, I can neither confirm nor deny any actions I may or may not have taken that may have facilitated, directly or indirectly, a bargaining unit’s progress.
Nice attempt at a gotcha though! Maybe consider the solidarity part of worker solidarity, friendo. They want us buddyfucking each other.
Less glibly: I believe that by explaining these issues, especially around the dynamics of unionization in the US in tech, there’s a better chance to adapt tactics and find a path forward that better serves tech workers. I suspect that something other than the current union framework in the US would actually be more to our benefit, perhaps a guild system or similar. I see too much cheerleading from the latte class who haven’t either formed, worked with, or managed members of a bargaining unit in tech, and that cheerleading I have seen mislead and screw workers who made the simple mistake of trying to do what they were told would magically solve all their problems.
I feel the other thing that isn’t addressed is, sure the Apple connector is much fancier and has much more amazing design stuff or whatever, maybe such that it is “worth” the price due to cost of construction.
But it doesn’t address the elephant in the room: does all that complexity and design actually make a meaningful difference?
Like someone could make a laptop with a case made out of solid gold and sure it would be “worth more” than the non solid gold ones, but does that actually mean it is actual worth the cost? The use of gold makes it more expensive but it doesn’t make it better
This is one of the better criticisms of bsky/atproto I’ve read. So glad to read a good one. Just two comments:
DMs were added out of protocol for exactly the reason the author suspects: users were clamoring for this functionality, and doing it right will take a while. So they’ve alluded to plans to bring them back into the protocol, but for now, most people are okay with trusting Bluesky and being able to do what they want to do. It’s effectively a non-regression from the point of “I’m migrating from Twitter.”
it seems unlikely that downplaying the role of domains is something Bluesky as an organization will be motivated to do since selling domains is currently a Bluesky business strategy.
It seems like this integration has disappeared, as far as I can tell. They didn’t say anything about it publicly that I saw.
Personally I am baffled by this mindset. How can a company that has every incentive to data mine everything that touches their servers be any better than a random dude without any such incentive. Granted the dude might be a creep, but I think these people get found out pretty quick… the simile of “many eyes make all bugs shallow” can be applied here. People smell a rat quite quickly on the internet.
I think both are reasonable. Some people prefer to only need to trust one party, instead of needing to re-figure out trust every time they message someone on a different server.
I personally just never put anything that I wouldn’t mind others reading into something that’s not E2E encrypted. I wouldn’t put something into a bsky DM that I would be upset with the team reading anyway.
I do think the risk is smaller than a lot of people make it out to be, but the odds of my fedi admin knowing and caring enough about me to snoop on my messages is significantly higher than that of a Twitter sysadmin.
I am actually exploring a user encrypted storage option for the ActivityPub service I develop.
Theoretically vanilla ActivityPub should support everything out of the box, but I don’t know for sure if the HTTP-Signatures that the protocol uses for inter-instance authorization would work when the private keys are not stored on the server itself but only on the client.
Because a lot of people are on fedi instances operated by their friends, or (if they aren’t already friends) users and admins on small-medium instances will inevitably get to know each other. There’s a lot more motivation to snoop on people you know, because by and large you don’t care about the private lives of complete strangers (and, frankly, it’s much more likely to cause me problems if someone I know snoops on my messages compared to some twitter sysadmin I’ve never met).
Obviously you’d hope nobody’s going around snooping on their friends’ posts, but people you thought you liked turn out to be shitty sometimes.
I guess the snooping that large companies are incentivized to do has a more diffuse impact, like everyone buying slightly more useless junk, with less risk of acute harms as long as you stay within certain bounds.
I generally agree with you, but I think the idea is weighing the difference between a corporate entity which nominally has certain legal compliance obligations and may offer a degree of transparency versus a completely random individual human answerable and transparent to nobody. Neither is inherently trustworthy, but they are certainly untrustworthy in different ways for different reasons.
Companies are very careful with private data beyond what the TOS permits for good reasons. Individuals are always problematic even with the best intentions. You lurking at private data in a company is a firing offense. You doing that out of power on a mastodon server is something that would not be spotted let alone be something that’s particularly problematic for you.
20 years ago I had an email address managed by an acquaintance of an acquaintance and eventually we figured out that they had a bash script running looking for keywords. Was definitely a lesson for me.
Google knowing what’s in my e-mail affects me far less than people I know and deal with regularly knowing what’s in my e-mail, simply because I don’t personally know Google and they don’t know me, and have no direct personal or emotional involvement in me. Likewise, if I’m on a mastodon server run by someone I know, them knowing what I’m DMing about is creepier by default. Imagine if you texted a friend about relationship troubles. Would you prefer someone else you know having access to that or an impartial, unrelated entity like Google?
This is, of course, assuming E2EE is not an option, which is true for both alternatives in consideration.
In a non-E2EE situation, I trust a company (or any other organisation) much more for this kind of problem than a random, unspecified, sometimes unknowable person on an instance I haven’t chosen (the administrator of the personal instance of the person I’m talking to ‘in private’).
But the thing is that on the Fediverse you can join an instance that has a well known community and sysops. And, with the risk of repeating the same trite thing as everyone else: you can always host your own. :P
I can’t choose the admin of the instance of my recipient, and they can’t do either for mine, so I think that point is moot?
(And I’ll reply what everyone else may have replied to you before: not everyone can host their own, it’s a common fallacy but not everybody has the technical knowledge, free time or purchasing power to rent a server to do so.)
How can a company that has every incentive to data mine everything that touches their servers be any better than a random dude without any such incentive.
Why do you think the company has this incentive but the random dude doesn’t?
Granted the dude might be a creep, but I think these people get found out pretty quick… the simile of “many eyes make all bugs shallow” can be applied here. People smell a rat quite quickly on the internet.
Why does “trust and ditch if they turn out to be a creep” policy apply to a random dude and not a company?
Because selling data on users is how companies with free services usually get money. The dude doesn’t because probably there’s no market for not mass sourced data, but I might be wrong.
Why does “trust and ditch if they turn out to be a creep” policy apply to a random dude and not a company?
It does, of course, but currently there’s only one Bluesky, so there’s nowhere else to go if you ditch them.
Well, I think that you could replace “DM” with “emails” in that context, and still get a clear picture of how much people care about that, in general.
As super techno-geeks living in the future /s, it would be nice to offer something more private to the world, rather than repeat the same mistakes. I understand Bluesky may have been pressed by time/resources to ship DMs. I can only hope that they will improve on this first version.
I definitely think adding DMs was a mistake. They weren’t ready to do it right, and really there’s no reason to do it at all. We have dozens of chat protocols already we didn’t need another half baked one.
I’m very interested in the novel stuff atproto is doing for the social space. The bolt on, less interesting.
Funnily enough the GNU social people were saying exactly the same thing when Mastodon was adding DMs. The lack of proper security against admins (plus footguns where @-ing someone you were talking about added them as a recipient) made it a pretty compromised thing. To this day I think we’d be better off using different tools for broadcast and for private chat.
The repository data structure is content-addressed (a Merkle-tree), and every mutation of repository contents (eg, addition, removal, and updates to records) results in a new commit data hash value (CID).
After you delete a post, it will be immediately removed from the user-facing app. Any images attached to your post will be immediately deleted in our data storage too. However, it takes a bit longer for the text content of a post to be fully deleted in storage. The text content is stored in a non-readable form, but it is possible to query the data via the API. We will periodically perform back-end deletes to entirely wipe this data.
so i don’t quite understand. are they going back and re-writing the tree history? or when you download someone else’s data repo (which seems to be a core design feature (i think i’m into it)), do you just see all their deleted posts also?
sorry if i’m stepping into discourse – i haven’t followed the technical details of atproto too closely until now.
As best I can tell (context: have a back burner project to reimplement all this, so I’ve looked into the details, but very possible I’m missing something), a bluesky repo is a merkle tree, ie a data structure where the pointers are hashes. But crucially, unlike git or a blockchain, that data structure isn’t a linked list, it’s a B tree. So removing/updating an object requires replacing a few hashes, but it’s O(log n), not O(n).
For a sufficiently big n that doesn’t sound so good anymore. And I imagine that when dealing with twitters numbers of DAUs you will hit this.
I also wonder how the whole thing will play out once they have to deal with that amount of deletion requests (from users and various legal entities). Especially for content that is illegal to even store - but is now distributed through all feed listeners.
Which all in all sounds like an actually decentralized social network of global size might not be feasible - unless you have a centralized but globally regulated group to operate the DB and servers. In which case you don’t have to pay the replication fee but everyone has access. - Except this comes with global politics. (There are a few similarities to our internet.)
For a sufficiently big n that doesn’t sound so good anymore. And I imagine that when dealing with twitters numbers of DAUs you will hit this.
Even at Twitter size, logarithms scale well.
Say there are 500 million daily tweets and 50 years of history for a total of about 10 trillion stored messages, and say they’re all stored in the same tree. If it’s log base 10, then the cost to remove/update a message is only ~13 times higher than it was when there was only one message. Or if it’s log base 2, then the cost is ~40 times higher than it was when there was only one message.
Has Bluesky actually progressed beyond decentralization in name only, or is it still just the one provider? If Bluesky the company shut their doors tomorrow, would the network survive?
I don’t know (or, to be honest, care that much) about the relative merits of bluesky’s protocol vs ActivityPub, but I am suspicious of the lack of actual federation occurring with bluesky. Mastodon isn’t perfect, but it exists and is actually decentralised in practice, not just on paper.
Not sure why this old meme is back again, when Bluesky has clearly progressed far enough now and you can host your own PDS with relative ease (for the Lobsters demographic).
It’s possible I’ve missed something but the PDS seems like the least interesting part. To get a coherent view of the network, all relevant PDSes need to be pushing to and the AppView need to be reading from the same relay (or set of relays). I am dubious that this is going to be tidy when groups start fragmenting into their own relays, particularly when the experience for the mainstream is that “it just works because I use the official ones so y’all could just stop trying to do something weird”.
This is my understanding as well; running your own PDS is viable but doesn’t really give you much benefit because everyone who will find your stuff will be doing so thru the centralized index run by an organization that is accountable to no one.
You can host your own PDS with ease; how does one use a PDS to communicate with another Bluesky user, without Bluesky-the-company being involved? My understanding is that it involves spinning up quite a lot of other stuff, and asking that other user to reconfigure their setup.
Just spun up a PDS for myself today! I’m feeling optimistic about Bluesky. I feel like it will be decent assuming there’s a committed effort among people to run servers and get some friends on them.
All the components are far enough along that the network would probably survive in some form. It has too many good ideas built into it for no one to run with it. There are already independent PDSes, experiments in running relays, and it just came out how easy it is to run the actual Bluesky web app: https://bsky.app/profile/joelhooks.com/post/3l7syfl7xqk2g
Some of the better perks of the system are still theoretical. It should end up good but it could also all go horribly wrong in some exciting way people write papers about for generations. I don’t know that I’ve seen any third-party PDSes that let other people use them.
Right now a lot operates on confidence in the people building it, the way the company is structured (the same structure that let it escape Twitter), and the fact that they keep delivering on the things they say they want to deliver on. That buys a lot of trust these days, but not everyone accepts the currency.
alternative AppViews providing a microblogging experience do not exist right now (because they … honestly don’t really need to at the moment) – but the PDS stats (i.e. where the data lives) are “37 hosted by Bluesky, 927 hosted by third-parties (of which 263 are offline)”
and since Bluesky has 13 million users you can assume that each bsky PDS has about 350k account repos stored on it but the self-hosted ones probably only have one or two each
Someone would have to set up a new one, and all the people who set a domain would have to update a TXT record. Everyone else would be lost in the drift.
One thing the devs talk about is moving the directory to an independent organization. It would have to be carefully set up to try and avoid the issues of DNS without creating new and worse problems. Right now using or building around Bluesky and AT is a bet on their intentions beating whatever brain worms seem to afflict companies after a while. It’s a race and the brain worms might win.
They acknowledge it and seem self-aware about the risks:
FWIW the Bluesky team agrees. Hopefully not in 5 years (I’d like at least 10 good years) but everybody knows the cycle. The company is a future adversary.
Sad to see the Matrix team repeating the lie that Bluesky is decentralized. When you look at the distinction between the two, it’s clear as day that we either need to stop calling Bluesky decentralized, or choose a new word for things that actually promote a network without megainstances and centralization.
Running a single Synapse server is enough to chat with your friends, completely in isolation. Two groups running Synapse can talk to each other without any interference from a third party, and you can self-host sydent or ma1sd or what have you for the identity API, too. You store and transmit the data required for conversations you participate in.
Running a Bluesky PDS, on the other hand, gives you control over your own data, to an extent, but Bluesky-the-company, or some other large entity, must be involved in order for you to talk to anyone else, because running a relay is expensive and legally risky. While you can argue this is technically “decentralized”, it’s qualitatively different from the way that things like Matrix and ActivityPub work.
Twitter has a single center. ATProto is designed to facilitate a network with a few centers rather than one, and views megarelays like bluesky.network as a success; a relay that isn’t enormous is a failure. Matrix, ActivityPub, and so forth are designed for a network with thousands of small “centers”, none of which need a complete view of the network, and the community tends to view mega-instances like mastodon.social, matrix.org, etc. as failures of the system.
imo, there is a line that drawn between ideologically pure decentralisation and mass adoption, and bluesky falls right in the middle on this line.
Onboarding my friend on was a nightmare, explaining things like
pick an instance (dont pick mastodon.social or any of the weird ones because some instances refuse to federate with mastodon.social and a few other instances (“you can move your account to another instance” argument does not work because most people just arent going to bother doing that))
if someone shares a link to a post while they are on a different instance than you, and you open the link, your login does not carry over.
mostly incompatible activitypub things can be viewed from the same thing (peertube, lemmy, mastodon feeds in the same place), no app properly supports this.
to someone who just wants to “use something like twitter that is not twitter” is a fool’s errand.
Bluesky has managed to surpass this hurdle (you download the bluesky app and make an account)(same can also be said about threads.net btw) by centralising a lot of its infrastructure into a cohesive brand and therefore, it has done something that neither mastodon or matrix or pgp has been able to do – actually being used by people
This may be a fine argument for building centralized systems, but it’s not at all an argument for calling Bluesky “decentralized,” which is what the parent comment was arguing against.
Sure. But if it’s not actually decentralized, what’s the point? Just use a centralized service, which will have an even better user experience, such as not exposing private info like likes and blocks.
I am not really sure what you’re saying here. If people care about the benefits of decentralization, they need to use something actually decentralized; if people don’t care about the benefits of decentralization, they should use a centralized solution that doesn’t have the tradeoffs of something like Bluesky.
i guess i didnt word my comment properly, i am sorry.
what i meant to say is thay bluesky, with all of its flaws right now, is a pretty good middle ground between ideologically pure decentralisation and mass market appeal
That’s the point, making a product technical superior doesn’t guarantee success. Matrix developers frequently have to explain why joining a channel can be slow - even slower than the decades-old IRC network. However, they rarely acknowledge that this performance issue is one of several key barriers holding back wider adoption of Matrix.
Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.
source
The OP explicitly cites faster room joins as something for the post-2.0 roadmap.
I’ll evaluate Matrix’s usability after version 2.0 is released - though I wouldn’t hold my breath for that. Perhaps Matrix should redesign their protocol specifications to require fewer $ to impl or operate while matching the performance of contemporary chat platforms.
I am still on the side of thinking matrix as alpha-stage software in 2024.
Running a Bluesky PDS, on the other hand, gives you control over your own data, to an extent, but Bluesky-the-company, or some other large entity, must be involved in order for you to talk to anyone else, because running a relay is expensive and legally risky. While you can argue this is technically “decentralized”, it’s qualitatively different from the way that things like Matrix and ActivityPub work.
From your link, I gather that running a relay the size of the largest relay costs somewhere less than $200/month. I agree that would be expensive if I were doing it for myself and my friends group, but it seems rather inexpensive at the scale they’re talking about. I haven’t looked into running one other than reading the post you linked; are you arguing that it’d be impossible (or not useful) to run a small one?
And can you elaborate on how it’s more legally risky than running a synapse server or a mastodon instance?
Sure - but $200/mo is both an order of magnitude more than it costs me to run four GoToSocial instances, and as the author says,
my guess is that it could do an order of magnitude more event rate, but will run out of disk before too long (eg, in the next year).
can you elaborate on how it’s more legally risky than running a synapse server or a mastodon instance?
Not to put too fine a point on it, but, I trust my friends and the people we talk to not to post CSAM; I don’t have that trust relationship with everyone on the entire Bluesky network, which is an open-signup set.
Sure - but $200/mo is both an order of magnitude more than it costs me to run four GoToSocial instances, and as the author says,
my guess is that it could do an order of magnitude more event rate, but will run out of disk before too long (eg, in the next year).
I wasn’t disagreeing that it’s too expensive for a friends/family instance.
My question was really (because I don’t understand the setup well enough) whether it’s possible to run an instance 10% the size for 10% the cost. Do you know if small instances are possible given the protocol/federation arrangement?
Not to put too fine a point on it, but, I trust my friends and the people we talk to not to post CSAM; I don’t have that trust relationship with everyone on the entire Bluesky network, which is an open-signup set.
Does a federated Mastodon instance carry that same risk? That’s the part I’m trying to get my head around… I had kind of understood this to be about the same lift as a Mastodon instance, in most ways. Now that I hear it’s not, I’m trying to get my head around where the differences lie.
I like your characterization that “the community tends to view mega-instances like mastodon.social, matrix.org, etc. as failures of the system” when it comes to the community differences. Now I’m just trying to update my mental model of legal/tech differences.
Ah yeah, this is exactly the difference I’m trying to get at. The Bluesky architecture is designed around what they call a “big world” concept; each relay is supposed to have a complete view of the whole network, including from accounts and instances you’re not following, have never seen, have never interacted with you, etc. That’s what makes the cost explode so much for a relay; there’s not really such a thing as a “friends and family” instance. They pay some lip service to the idea of this in the protocol documentation, but there’s essentially no actual support for it in practice.
On a fedi instance, you only store posts (and media) from people you follow, including things boosted by those people, and posts fetched as parts of threads and so forth, so your exposure - both in terms of storage/processing cost and in terms of liability - is dramatically lessened. On a Matrix server, it’s even more so; you store only messages in rooms one of your users is in.
To elaborate a bit, the bluesky protocol (as currently implemented) makes it impossible to do a lot of important things without a big world relay - for example there’s no protocol-level notification mechanism for likes/replies/follows/etc, users are just expected to have a relay crawling the entire network for actions which concern them.
(That being said it’s just about possible to build a bare-minimum small-world “see what my friends are posting” thing, and I intend to do this at some point.)
For people only subscribed through RSS, I don’t see that anything more than a redirect is necessary for account migration.
As for signed posts… can’t we simply rely on HTTPS to your own domain to prevent man-in-the-middle modification of posts? If Bluesky requires you to have your own domain anyway…
Running a relay that subscribes to the entire global network is relatively expensive to run, but there’s no reason you couldn’t subscribe to and relay a smaller sub-graph of the network featuring only your friends.
This seems entirely tangential to the release of Matrix 2.0, but it’s perpeptuating a big misconception about how AT Proto works
I subscribe to the megarelay and it’s about 12 megabits per second at peak times. The burden for running a megarelay is relaying to all subscribers (which is NOT all PDSes – just appviews, feeds, and labelers) and storing recently broadcasted // all ever broadcasted posts. The relay is not integral to the network (PDSes could & can just subscribe to each other), it’s a bolt-on for performance
Plus there’s no reason you couldn’t be connected to a smaller relay that forwards your stuff upstream to the large firehose (so that bluesky AppView can see it) or not at all (so only subscribers to your alt relay can see it) – Much differently to ActivityPub, the auth is at the data layer and not the request layer, so relays can feed into each other and rebroadcast without betraying message integrity
It took 1+ day for this content to propagate to the IPFS gate.
Well, in my experience direct IPFS access is not much faster. I tried multiple times over the years and every time it takes forever to access anything on IPFS. The demon sits ih the background, chewing CPU and juggling bytes on the network and I still can’t get anything to load. For all I know it might as well be interplanetary for real and trying to fetch something from the moons of Jupiter.
Domains are useful. They make things look at least somewhat human-oriented. I can read a domain name out loud and I don’t sound like I’m having a stroke. Apart from malicious typosquatting and such most domains are recognisable, I can tell them apart and I can find them in my browser history if I need to. Hashes on IPFS make it absolutely unusable. There’s no hope telling one apart from another. I just can not use IPFS unless I have a link. I don’t think there’s any hope for IPFS unless somene comes up with IPNS.
(There is an IPNS - but the names are still opaque strings, presumably public keys of some sort, you just gain the ability to change what content they refer to.)
Since everyone is talking about torrents in this thread, I’ll also add that BitTorrent v2 added a feature like this, but I’m not sure how widely supported it is yet.
Well, in my experience direct IPFS access is not much faster. I tried multiple times over the years and every time it takes forever to access anything on IPFS. The demon sits ih the background, chewing CPU and juggling bytes on the network and I still can’t get anything to load.
NAT hole punching has improved significantly in recent years and has become much more reliable.
In most cases, the slowness that people experience is either related to:
Failure to establish direct connections (due to NAT for example)
Failure to find the providers for a given CID (basically a hash)
Domains are useful. They make things look at least somewhat human-oriented. I can read a domain name out loud and I don’t sound like I’m having a stroke. Apart from malicious typosquatting and such most domains are recognisable, I can tell them apart and I can find them in my browser history if I need to. Hashes on IPFS make it absolutely unusable. There’s no hope telling one apart from another.
Indeed hashes are not human friendly. DNSLink solves this problem and is implemented in most IPFS implementations. Basically allows mapping from DNS -> CID.
er…. well I agree with the observations, but the conclusion does not follow and is dangerously wrong
do not use the Microsoft or Apple ecosystems for passkeys. they will get you in serious trouble if you ever find yourself at odds with the company, or simply want to leave. use a physical hardware token, and if that’s financially prohibitive for you or otherwise impossible, stick with older methods of authentication. do not tie your entire life to a single megacorp.
A YubiKey can only hold 25 resident keys. They are also clunky and annoying.
There’s a real risk Apple might someday ban my account without recourse. But hardware tokens are too annoying to consider using them in any serious capacity.
I have a YubiKey backup that I could bootstrap from, if needed, but in the meantime I’m going to take the convenience of Apple iCloud.
This is the move, or something like it. I lock down a Vaultwarden instance using Yubikeys and TOTP keys and etc. on top of a secure passphrase, and then that Vaultwarden instance and the Bitwarden Firefox extension + mobile app get me into most other things. This was a change I made in 2024 and I truly don’t know how I ever lived without it.
Vault/Bitwarden support passkeys too, so you get one-ish click logins to anything that supports them (GitHub, whatever), protected by a physical hardware key a layer above. Best of both worlds, and works around stupid sites doing stupid things like limiting you to one Yubikey per account, a horrible practice that should have been forbidden in the spec somehow.
Fortunately the number of web services I use that support passkeys is less than 25, and I also have 3 yubikeys ^^;
They are also clunky and annoying.
What about the Yubikey Nano? You just pop it in your USB port and you won’t even notice it’s there.
But hardware tokens are too annoying to consider using them in any serious capacity.
I don’t get that argument, I have nothing but good things to say about hardware tokens, and I use them for everything. I guess that’s all down to personal preferences in the end.
The UX of YubiKey compared to Apple iCloud is prehistoric.
With Apple iCloud all I have to do is present my face or my fingerprint. Additionally I only have to do this once when I make a new account.
With YubiKeys I have to:
Find token #1.
Plug it in, which is very annoying because it is attached to my keys.
Fiddle with the hard to press button, which I have to press twice.
Remember and input a PIN, which I always fail to do correctly on my phone.
Hope the YubiKey software works, sometimes it just doesn’t.
Hope the service that I am trying to log into doesn’t time out while I fiddle with my keys.
Additionally when enrolling a key I have to do the same thing, but thrice, and I have to find out how to enroll multiple keys (every service does this differently). I also have to hope the service allows me to label my keys, many which don’t. I don’t have to deal with any of this when using Apple iCloud.
But it gets even worse, I now have to deal with resident vs. non-resident keys, know which is which, and deal with cryptic errors while inevitably I run out of resident key slots.
Also, when I am traveling I only have two out of my three keys with me, so when I come back home I need to remember to enroll the third key, and I need to remember for which new services I have to do this.
To add insult to injury, the NFC function only works on my iPhone after I plug it in!!!
Also my YubiKeys don’t work with government websites because they are not FIPS complaint. But the app they provide supports passwords (stored in iCloud) and Face/Touch ID, so there you go.
This is a kafkaesque nightmare. If you think this is good you are a masochist. With Apple iCloud I literally don’t have to do any of this. It just works!
I use YubiKeys but only for e-mail and Apple iCloud recovery. I can bootstrap every other service from that. It would be insane to have to use YubiKeys everyday.
Not to say that your experience is invalid or anything, but somehow none of these ever become a problem for me.
For me, my token is always plugged in when I am in my house. When I leave I take them with me, when I return I plug them back in, this never felt inconvenient to me. My yubikeys are with my keys too, by doing so I always know where my keys are, which is a big plus since I am very forgetful. If you dislike needing a PIN, get the Yubikey Bio and you can use your fingerprint for verification.
I need to press my Yubikey many, many times a day. I use it for logins for start, besides that I also use it to unlock my encrypted disk, sign my git commits, etc. And I rarely have trouble hitting the button. Maybe I just have smaller fingers or something?
I also never had to worry about resident key vs non-resident. I am kind of curious, maybe I should worry? In what cases would this matter?
I think the argument they’re making is that, worst case, you can just go through the “reset password” flow, so it’s not critical to never lose your passkeys? Of course this assumes that the password reset flow exists (and it’s not like, eg, Discord’s 2FA where losing your secrets locks you out hard), and that you don’t need a passkey to get into your email itself.
yeah, that sounds like it could be where they’re coming from. it’s at least a coherent position, which I wish were better elaborated.
I don’t personally even want a megacorp to be able to observe what I log into or when, I think the risks of that kind of surveillance being normalized are extraordinary. this is also my complaint about the long-standing practice of relying on megacorps as identity providers with OAUTH.
I’m not sure why you seem to think passkeys/WebAuthn are in any way comparable to OAuth. In passkeys/WebAuthn there is no equivalent of the remote “identity provider” in OAuth “sign in” flows – passkeys/WebAuthn is literally just public-key cryptography where you prove identity by proving you’re in possession of the private key. Note I do say you, not “your identity provider”, because passkeys are local credentials. Apple’s gone to some lengths to provide the ability to share a set of passkeys among all devices signed in to a single Apple ID without also giving themselves all your private keys, but I’m not aware of anything which would remotely notify Apple of which sites you’re authenticating to with passkeys.
Also, there’s nothing about passkeys which inherently makes them non-portable or prevents them being backed up. Multiple implementations already have the ability to back up and export (I believe Apple’s even has the ability to do trusted sharing of a passkey to another person in order to enable something like “password sharing” in more traditional auth flows).
So I think anyone who wants to claim passkeys involve the same level of observability as third-party IdP systems like OAuth needs to provide evidence to back up that claim.
there’s nothing about passkeys which inherently makes them non-portable or prevents them being backed up
The OP explicitly claims that passkeys are non-portable and cannot be backed up, by design. This is the central claim of the post. It’s what the title “Passkeys are not passwords” refers to. But apparently this is possible if you have an Apple ID and trust Apple and its cloud.
The person you are replying to stated:
do not use the Microsoft or Apple ecosystems for passkeys. they will get you in serious trouble if you ever find yourself at odds with the company, or simply want to leave.
So advising them to get an Apple ID isn’t helpful to them. Or to me, because I don’t have an Apple ID, Google ID or Microsoft ID, and have no plans to get one. I’m only interested in security solutions that are open source and local first, where I own the hardware where the passwords or security keys or credentials are stored, where I can back up critical information and transfer it to another device. The OP says that the design of passkeys makes what I want impossible, and you say trusting Apple and the iCloud is how I get these features. You also mention “other implementations”, but what about implementations that aren’t Google or Microsoft cloud based, and which are both local and secure?
The OP says that the design of passkeys makes what I want impossible, and you say trusting Apple and the iCloud is how I get these features.
The design of passkeys does not make it impossible. The claim that it’s impossible to back up or export passkeys “by design” is verifiably factually false. “Passkeys” is literally just a new brand name for WebAuthn, and WebAuthn is, as I’ve pointed out, literally just public-key cryptography. Signing up for a site with “passkeys” just involves the site associating the public key with your account, and when you authenticate there in the future it just checks that you are able to sign things with the corresponding private key.
Nothing about passkeys requires that the private key be somehow un-back-up-able or un-export-able. There are implementations that you can download and use, right now, today, that can export to plain-text formats. To the extent that some implementations don’t have those features right now, it is a “haven’t prioritized/got round to it”, not a “that is impossible by design of passkeys”.
And I never said you have to “trust Apple and the iCloud” to get these features. There was an assertion up-thread that Apple was somehow secretly surveilling passkey usage and would know every time you use one and where you used it. I pointed out there’s no evidence for this whatsoever, and that Apple’s implementation in fact seems to have been quite thoughtful about privacy-preserving ways of doing difficult things – like how to let a user share key material among multiple devices, or to a trusted third party for credential sharing, without exposing that key material to the full view of Apple itself or of untrusted third parties.
You could, if you wanted to, go out today and obtain a copy of Bitwarden and run it on whatever device(s) you choose and use it to generate and manage passkeys. You can even export them out of Bitwarden as plain JSON, right now, today, and they say they’re working on full import/export transferability to and from other passkey implementations for future releases.
The mere existence of Bitwarden, as Free Software with that feature set, overturns most of the negative claims being made about passkeys. Will it matter or change anyone’s mind? Who knows.
As I understand it, there is a lot more to passkey authentication than “it just checks that you are able to sign things with the corresponding private key”. There’s also an attestation system so that the server can identify the software running on the client. This is intended to allow servers to ensure that private keys are resident in an HSM or device secure enclave, or that software clients obey certain rules such as never exporting private keys.
None of what you’re saying is really a counterargument, though, as far as I can tell. Yes, there’s lots of extra stuff available around the core public-key cryptography stuff, because there’s a desire on the part of giant companies to make passkeys or something like it part of their employee auth setup, and probably on the part of government agencies and other such entities.
But those things are not going to apply to every site and every user and every implementation. Claiming that those sorts of restrictions are going to apply to 100% of users as an “inherent” part of passkeys is just nonsense. A good analogy is MDM: you can do lots of restrictive things to a device with MDM, but that doesn’t mean that any device which is capable of being enrolled in MDM is always operating under the most restrictive possible things MDM can do. Most devices aren’t enrolled at all!
Every authn/authz protocol eventually grows all those bells and whistles to satisfy huge entities whose audit checkboxes require them. That does not mean that all those bells and whistles are force-enabled for everyone everywhere all the time, and we need to stop acting as if they are.
I clicked on @fanf’s link and read the posts by Tim Cappalli. It seems the current looseness is a temporary situation, and the FIDO Alliance is working to close these loopholes. Once Passkey Provider Certification is fully deployed, it seems likely that any site that forces you to use a passkey rather than a password will be implementing the updated standard. I run GrapheneOS on my phone, and it’s already the case that some banking apps won’t run because Graphene, as a non-commercial open source project, can’t get certification from Google as a trusted operating system so that it will pass SafetyNet attestation checks. The same fate may await pure, non-commercial open source projects like VaultWarden. The main part of the internet is evolving into a proprietary-only walled garden, and people who want to use open source everything are increasingly confined to their own hobbyist ghetto. If you look at the FIDO Alliance membership list, it’s controlled by a bunch of propriety walled garden internet companies, like Google, and it won’t be surprising if those guys don’t see any business value in supporting non-commercial open source projects. I do see that Bitwarden is a second tier sponsor-level member of FIDO, but I don’t know if Bitwarden’s support for hosting your own server from open source that you compiled yourself will survive into the attestation era, and I’d rather run Vaultwarden.
The way I read that thread is that while the tone is unfortunate, they’re working on standardizing how import/export/etc. should work in a way that actually specifies how to safely handle private-key material. Which is a fine thing to standardize.
And I stand by what I said in my comment above, that a lot of this is people looking at a spec that’s growing all the “enterprise auth” bells and whistles and assuming that 100% of those features will be on 100% of the time for 100% of users, when the reality is it’s going to be more like “when you work for FooCorp, you will be required as a company policy to use this specific passkey implementation on a device specifically MDM’d by FooCorp and you will not be allowed to export out the private keys of your FooCorp passkeys, and there are specs to allow enforcement of that”. None of that affects what someone can do with a device they actually own – I have two laptops from the same manufacturer, running the same OS, but one is my personal device and the other is owned by my employer and MDM’d by them. The fact that MDM exists does not cause my personal laptop to be restricted in what it can do; it only affects the company laptop that’s actually enrolled in their MDM.
And I stand by what I said in my comment above, that a lot of this is people looking at a spec that’s growing all the “enterprise auth” bells and whistles and assuming that 100% of those features will be on 100% of the time for 100% of users, when the reality is it’s going to be more like “when you work for FooCorp, you will be required as a company policy to use this specific passkey implementation on a device specifically MDM’d by FooCorp and you will not be allowed to export out the private keys of your FooCorp passkeys, and there are specs to allow enforcement of that”
How do I guarantee that my bank will not be able to turn it on when I use an alternative OS, or a custom build of a mainstream OS or browser? For example, a Chrome patched to extend ad-blocking or debugging capabilities.
How do I guarantee that my bank will not be able to turn it on when I use an alternative OS, or a custom build of a mainstream OS or browser?
I don’t have the knowledge to answer your question, but I wonder why this specific guarantee would matter. An authentication technology can’t guarantee that you’ll always be able to sign in with it from any platform, because it can’t guarantee that your bank won’t switch to a different authentication technology.
I agree, it’s going to be a constant fight to keep the harmful capabilities out of popular authentication technology, and to keep authentication technology that includes it from becoming popular.
The only way you “guarantee” your bank won’t do something you dislike is by not having a bank at all.
Your bank could already, today, right now, suddenly decide to only allow you to sign in using some form of OAuth/OIDC/whatever from a single identity provider with a bunch of restrictions on acceptable browsers/operating systems. That is something that is already 100% within their legal and technical power to do. I doubt they are just waiting for another auth system to come along with the same capabilities before finally twirling their mustaches and cackling “ha-ha, at last we can implement our plan to destroy privacy and software freedom forever”, so WebAuthn gaining extensions to let corporate use cases do MDM-y things is likely to be no net change on that front.
People always complain in these threads that their banks already do stuff like don’t allow their app to run on a rooted Android device or whatever. Regardless of whether it’s part of the specific auth protocol or done another way, the simple fact is they already have the capability and do not need to wait for someone to develop it for them. So once again: none of these MDM-y extensions being developed for passkeys represent a net change in your bank’s capabilities to restrict how and from what devices you log in.
Currently, that capability is restricted to mobile platforms. It would be very good to make it harder to expand those capabilities to the desktop or other platforms.
The only acceptable attestation is having every install generate a new self-signed attestation key that I can register with my account.
I still don’t see a meaningful change to the status quo here.
Also, attestation in general has user-empowering use cases – a remote machine being able to cryptographically prove that it’s running what you installed on it, for example, rather than secretly running something someone else installed without your knowledge – and I’m kinda tired of the knee-jerk posts portraying it as inherently evil.
Anyway, passkeys are not a secret plot to destroy your freedom forever. Nor were the last fifty things people insisted were secret plots to destroy your freedom forever. The people who you think are out to destroy your freedom generally are not.
Yes. And when I can prove to providers that I am running the software I intended to install, rather than proving that I gave Microsoft or Apple money, you might be able to convince me that this is a benefit.
I would love to be able to prove to providers that I am in full control of my machine, and that all the patches to the OS were intentionally installed by me. I can’t do that. The tools are broken.
And none of the providers reciprocate: They know how restrictive this ks. There’s a reason I can’t get attestation that the hosts running my GitHub account are running a known software stack.
Anyway, passkeys are not a secret plot to destroy your freedom forever.
And yet, it gets harder and harder for alternative implementations.
So, no. This is fucking me over, even if it’s simply through apathy. Stop trying to fuck me over.
I don’t personally even want a megacorp to be able to observe what I log into or when
This is not something that passkeys enable. A passkey is just a marketing name for a private key that is stored in some hardware root of trust (or a fake one in some cases). There is no communication with Apple when you use an Apple device to log in with a passkey, the server sends you a nonce, you encrypt it (and some other stuff) with your private key and send it back, they decrypt it with the public key they have on file and now they have a proof that you are the person who gave them the public key. Each key pair is specific to a site. Some devices do this by having a single secret and using a KDF to derive per-site keys, others do random keys per site.
The thing that Apple adds on top is the really hard bit: allowing keys to be moved from one secure device to another. I’d love to see a vendor neutral way of doing this but it’s a complex problem. Your root of trust needs to do some kind of key exchange with the target, validate that there isn’t a MITM attack going on, then encrypt the keys and transfer them. It needs to have some confidence that you are really the person authorising this (and not, say, someone who borrowed your YubiKey when you went to the bathroom) and that the target device is secure (and not something that will just leak all of your keys). Oh, and you need to make sure that it’s hard for someone to threaten you and steal all of your keys.
If you have a proposal for how to make that work, I’d love to hear it.
So far, the vendor neutral solution is just “HSMs are overkill paranoia for this (and restoring from 0 active devices is actually not to be dismissed), the same level of security that worked for password managers is sufficient, so they just become passkey managers as well” :)
iCloud Keychain at least purports to end-to-end encrypt its data (with escrow unless you turn on the full blown advanced protection), which would prevent them from gathering data about your login habits.
There’s still the lock-in issue, but I don’t see the privacy aspect unless I’m missing something…
Does that apply to any logs that they keep on the authentication attempts? No info on that (and for some folks trying to pry, that’d be enough info to continue the “old school” route
What logs? How do you think they’re generated and sent to Apple? Do you have proof from, e.g., packet sniffing that Apple devices are notifying Apple whenever you use a passkey? What led you to believe this was a thing that might be happening?
Passkeys, as far as I know, are literally just public-key cryptography where a keypair is generated for each site you want to authenticate to, and the site stores the public key and you prove your identity by having and using the private key. The implementation is literally not much more than fancy UI around a keyring, something that’s been around for ages at this point.
This was a purely speculative comment (since most professional environments keep logs on activity to prevent fraud; unless Apple’s privately figured out how to do so), to answer those questions in one go.
I’m familiar with the infrastructure around Passkeys, still am in the FIDO WG though I don’t contribute much. What I’m saying is that there’s probably (because we will never know unless someone decompiles Apple’s stuff) some marker to note how they authenticated. There’s also a chance that they don’t mark that, but you can see what devices have been signed in on most Apple devices (like on one’s laptop or desktop via that iCloud panel) as well as log-in location.
The operative word in my comment was any so it could have been ephemeral ones like in that dashboard or ones kept in their secure systems.
What I’m saying is that there’s probably (because we will never know unless someone decompiles Apple’s stuff) some marker to note how they authenticated.
The original context of this thread was someone (not you) asserting as a legitimate concern that Apple is going to “observe” what they log into and when, comparing it to OAuth.
Which I interpret as a claim that if, say, they authenticate to example.com on an Apple device and using Apple’s implementation of passkeys, they believe Apple would be aware that they have just authenticated to example.com .
While it’s true that with OAuth (which really is about authorization where passkeys/WebAuthn are authentication) the resource server (i.e., Google, Facebook, Microsoft, etc. in OAuth-based “sign in with” flows) has information about each client requesting authorization, and thus knows every client application a given resource owner (user) is authorizing, I’m unaware of any equivalent ability, or even anything close to equivalent, in passkeys/WebAuthn.
So I think the claim that passkeys somehow enable the same level of observability as OAuth, or that Apple has somehow built a similar level of observability into its passkeys implementation, is an extraordinary one and requires extraordinary evidence, and probably should not be speculated on without at least some actual evidence that it’s there.
Another thing to consider is the flipside situation, it is physically possible for yubikeys to die. I had this happen to me recently with my 5C nano. Suddenly decided to brick itself, won’t even power on or be detected anymore.
I prefer to put my passkeys in 1password, though I won’t defend them per say, it just works best for me in my present situation
My only concern with 1Password is that I don’t think you can export or move the keys. Hell, you can’t even fix up entries where the passkey has gone to one entry and the password is on another.
I read it as “here’s a thing you might not have understood about passkeys”, which indeed, I did not. I certainly don’t see a conclusion anywhere near as forceful as what you might have. I read the final paragraph as “if you’re going to use passkeys, this is the best way to use them”, without speaking to whether or not passkeys are an objectively good or bad idea.
(I mean, the author is clearly invested in the idea to some degree, so the existence of the post at all suggests some enthusiasm, but it hardly seems like a full-throated endorsement).
On macOS, at least the last time I tried, the browsers don’t let you make that choice. Safari doesn’t let you save a passkey without iCloud Keychain turned on. Chrome doesn’t let you do it without using Chrome Password Manager. Not sure about Firefox.
With the Safari Bitwarden extension I can store passkeys in there (and then secure Bitwarden with hardware keys). But the UI is clunky and still doesn’t work on phones yet.
On desktop currently, 3rd party passkey managers provide extensions that override the built-in passkey handling right inside of the web pages. On mobile (iOS >= 17, Android >= 14) they hook into the system API for passkey providers.
Ah, it was a while ago that I tried it. I was also on an older iPhone that could only go up to iOS 15, so maybe that was why. I have a newer iPhone now and I just tried, and it indeed does seem to support it. But when I tried logging into GitHub with Bitwarden’s passkey, it said: “Error reading passkey. There was a problem reading your passkey for github.com. Try again later.” I guess I won’t be going passkey-only anytime soon.
Not super related, but I wish using physical hardware tokens were as easy as that. I don’t use any passkeys; I have a couple of Yubikeys for FIDO (…? FIDO2? U2F? I don’t even know and this is half the problem)-based flows, TOTP where I can’t, SMS where even those aren’t an option.
But the Yubikeys work on maybe 65% of websites. Some combination of OS/browser/? means that some sites prompt correctly for them, but then just give some inexplicable error on touching the capacitive button. This is unfortunate because it means e.g. I can log in fine with my keys on Firefox on a Macbook, but the same keys on Firefox on Linux don’t achieve the same result.
Some you have to dance around with various settings, and some only work if you have a PIN set. I think this is related to the FIDO(2)/U2F confusion — I’ve spent a while trying different combinations of which are enabled on my keys and the results in varying websites are all completely different, presumably depending on the APIs they use. A thankfully very small proportion only let you add one hardware key, which is terrible.
I still go through the effort of attempting everywhere I can, but I can see why people would take up passkeys instead of it. (It doesn’t help that all the relevant ecosystems are pushing them in a way that makes using a hardware key instead several extra clicks than they used to be; 1Password keeps wanting to save a passkey when I want to use my already-plugged-in-key instead, Windows doesn’t let you disable this thing, macOS wants to get in the way too (which combines with 1Password’s for extra clicks), etc. etc. etc.)
very belatedly, in case it’s still useful to you: yes, requiring a PIN is a specific thing that site owners can turn on starting in FIDO2. I had to dig into this recently so I happen to know…
However I don’t understand the reaction to the vendor response:
the legitimate ones I’d initially generated still worked
How can the initially generated API tokens still work? If the private key is known, there is no way to differentiate a “legitimate” token, from a “forged” one.
It can if their system has a record of all tokens it legitimately issued. Given the short lifetime, the risk that someone manages to recreate the attack in the remaining time and manages to brute force an already existing valid token is probably not that high (and something they can monitor for). My guess would be that if they broke all existing tokens devices would need to be logged in again etc, so this way they can let them naturally refresh to the new secure tokens.
The strange bit, of course, is that if they have a record of every token, then they could’ve avoided JWT in the first place, just used random tokens, and eliminated this whole class of bug!
Yeah, it is entirely a guess, but given the description in the Ars article of this being an early decision made by relatively junior people, it sounds possible. JWT gets (IMHO) recommended way to much as the obvious approach, so it’s not unlikely to be picked, and accidentally or intentionally logging enough that they can get a list of tokens now and enforce them centrally also seems possible (and if they have some central API gateway etc its easier to do that for now vs rebuilding all the backend things to not use JWTs)
The token given in the beginning is valid 7 days, so it makes sense.
(if they record all emitted tokens, it feels like another security hazard: having read access to this table would be give an attacker quite a lot of power…)
It would negate one of the benefits of JWTs too - stateless verification. The downside is of course that you can’t really revoke them. 7 days feels like a long expiry, but obv I’m not privy to their threat model
If they have a record of token IDs they could look up the info of the owner and “regenerate” the info that would have been signed in the token from the DB.
Very technical post and good thinking, I like it. I believe that the post would benefit from a gentler introduction for people who aren’t well-versed in functional programming and type theory. Even though I think about this stuff a lot, it took me a minute to orient myself and figure out what we are talking about because the reader is instantly thrown into cold water.
There’s a common pattern in UIs where you ask the user a question, then depending on the answer to that question, reveal two different sets of fields - he uses the example of setting up a project in an IDE, where you can choose to point it at an existing directory (specifying the path) or tell it to clone a repo (specifying a git repo, access token, and the path you want to clone it to). Logically, you would represent the user’s input from the form using something like this Rust enum:
But from a UI perspective, it’s really annoying if you start to enter the information for a clone, click the “local” radio button for a moment, change your mind and switch back to “clone”, and you lose everything you’ve already typed into the form. So the underlying data structure - at least while the user is filling in the form - actually needs to look like this:
The insight is that even though logically you’re producing something represented by a sum type (type theory for what Rust calls an enum), for good UI, the form internally needs to use a product type (type theory for what Rust calls a struct) containing all the options from the sum type.
This is actually very relevant and one of the most common mistakes I see devs making. They avoid to create types that describe exactly that. Instead they try to directly transform some raw input (e.g. html state) into the final sumtype.
I thought that (and it made no sense) until I read the replies here. I absolutely hate the naming conventions, they’re confusing and even knowing about them I have to keep looking up whether product means “struct” or “union”.
The notation where the OP uses 2*A*B didn’t help either. 2 isn’t a type…
2 can stand in for any two-valued type because they’re all isomorphic. It could be data RB = Red | Black or data Bool = True | False, or any number of other names.
About the only time I’ve seen discussions of cardinalities of types is in the context of this semiring of types, where it’s simultaneously helpful (because it’s capturing the essential feature of all n-valued types) and obscuring (because |n| = n for any n ∈ ℕ). My set theory classes are a distant memory, but I think we built numbers out of sets such that x ∈ y iff x < y.
I always give the opposite feedback. At some point, you have to decide who your target audience is. Posts lose clarity when they have to define every single concept down to first principles.
A happy medium is to link to other posts that describe something. But, at the same time, it’s also pretty low effort to do some googling about algebraic data types.
The screenshot of the rotating ticket also includes an “Add to Apple Wallet” button; given you can’t easily implement this kind of rotating code with Apple Wallet, I wonder whether the resulting wallet pass just has a static code instead (bypassing the need to reverse the ticket)?
Do you have a source? The developer docs don’t mention this functionality, but I wouldn’t be surprised if that was intentional obfuscation…
edit: it appears Google have a rotating barcode thing; Apple’s support pages on the other hand seem to be filled with people complaining about rotating barcodes not working with Apple Wallet, so perhaps they indeed just don’t!
There is one user claiming that it works on Google Wallet with what sounds like a first-hand description and one user stating that it also rotates in Apple’s wallet.
Wallet passes have HTTP endpoints to do stuff like update the pass. That’s how your boarding passes for flights can be updated if the terminal changes.
Larry’s stated goal is to have every free software project using BitKeeper within a few years.
I had heard about the famous bitkeeper kerfuffle of course, but I always assumed bitkeeper was written primarily for corporate users; I had no idea McVoy was so hilariously out of touch with the free software world that he could ever actually think this.
BitKeeper includes a logging feature. Once multiple repositories are in use, BitKeeper will log all changes to a central server; these logs will be made available via a web page. Thus anybody can go to the web site and see what’s happening with any development project out there which is using BitKeeper.
BitHub???
There are a number of other features to the BitKeeper license. Subsections of the code - generally library modules that could be useful elsewhere - will be available under the GPL. If the logging servers go away, or if work on the system stops for two years, the whole thing goes GPL.
Apparently they moved it to the Apache Public License in 2016.
I had heard about the famous bitkeeper kerfuffle of course, but I always assumed bitkeeper was written primarily for corporate users; I had no idea McVoy was so hilariously out of touch with the free software world that he could ever actually think this.
Of course, there’s the further irony that git did go on to achieve this level of domination!
For anyone who isn’t familiar: in Turkish, ı and i are distinct letters, with corresponding capital variants I and İ; this causes all sorts of fun localization problems, as “i”.toUpperCase() is “I” in english but “İ” in Turkish.
why not change the shortcut it in the editor instead?
iirc, this is what people who use non-latin languages in such editors do, for example, change the shortcuts ctrl+x to ctrl+ч, ctrl+z to ctrl+я, and so on
I’ve had some similar issues - not specifically with i, but with the placement of characters like [,], | and the like. I’ve ended up switching to using a US-ANSI keyboard layout, with a compose key for using the non-English characters in my native language.
The reason for this is that pretty much every piece of software I use assumes a US-ANSI layout, and remapping all of them is a giant hassle. (and also, I’ve found I like the ANSI shape for Enter and left-shift better). Also, like OP, I type in English more than in Danish.
I think once you factor in the relay, the answer is clearly no, unless you are running a splinter network. Which makes this article feel a bit disingenuous to me.
Related: https://dustycloud.org/blog/how-decentralized-is-bluesky/
i get it. i did try to carve that out as a caveat right at the top and make it clear that this was only addressing one of the two main cost critiques of atproto. it honestly took a lot of work for me to get it here, and the scope of this post was already a challenge for me to try to make cohesive.
that said i won’t argue but will push back on “clearly”, at least it’s not as obvious to me as it seems to be to you.
Christine’s post is fantastic! It’s linked from my post too, it’s great! I’ll add that it’s worth checking out her work on the Spritely Institute for really cool possible decentralized futures.
You can run Jetstream however, which is a lot lighter: https://bsky.bad-example.com/consuming-the-firehose-cheaply/
Jetstream isn’t a relay replacement - it exists downstream of an existing relay.
I’d really like something like this (crucially, at a similar price point to the Steam Deck) that I can just connect to from my laptop.
Wayland bad. X11 good. /s
Imagine if all that Wayland effort was put into fixing the supposed issues with X11…
They can’t be fixed, these are design issues. And this is said by the very developers and maintainers of X, who moved on to develop Wayland.
This is false, completely false, but repeated over and over and over and over and over and over and over again, then upvoted over and over and over again.
It can be fixed, and the Wayland developers said it can be fixed, they just didn’t want to.
See the official wayland faq: https://wayland.freedesktop.org/faq.html#heading_toc_j_5
“ It’s entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X.”
From their own website, in their own words.
And that’s a good enough reason. As far as I know, none of us are paying them for their work. Since we benefit from what they (or their employers) are freely giving, we have no right to complain.
I’m not an X11 partisan, it seems plausible enough that Wayland is a good idea, but you’re just begging the question that we’re benefiting from what they’re freely giving.
We’re using what they’re freely given, but it’s not guaranteed that we’re benefiting.
With the risk of engaging with someone who’s words read as an emotional defence…
What do you suppose the benefits of sticking with X.ORG were?
I know of no person who could reasonably debug it- even as a user, and the code itself had become incredibly complex over time, accumulating a vast array of workarounds.
The design (I’m told) was gloriously inefficient but hacked over time to be performant - often violating the principles in which it existed in the first place.
It also forced single-threaded compositing due to the client-server architecture…
Fixing these issues in X11 would have been incredibly disruptive, and they chose to do the python3 thing of a clean break, which must have been refreshing.
The “Hate” seems to be categorisable in a few ways:
Do you have something else to add to this list, or do you think I’ve mischaracterised anything?
It just works for tons of people. X runs the software I want it to run, and it does it today. Wayland does not.
I think I could make it work with probably hundreds of hours of effort but…. why? I have better things to do than run on the code treadmill.
I’ve encountered one bug in X over the last decade. I make a repro script, git cloned the x server, built it, ran my reproduction in gdb, wrote a fix, and submitted it upstream in about 30 minutes of work. (Then subsystem maintainer Peter Hutterer rewrote it since my fix didn’t get to the root cause of the issue, my fix was to fail the operation when the pointer was null, his fix ensured the pointer never was null in the first place. So the total time was more than the 30 mins I spent, but even if my original patch was merged unmodified, it would have solved the issue from my perspective.)
After hearing all the alleged horror stories, I thought it’d be harder than it was! But it wasn’t that bad at all. Maybe other parts of the code are worse, I don’t know. But I also haven’t had a need to know, since it works for me (and also for a lot of other people).
Also important to realize that huge parts of the X ecosystem are outside the X server itself. The X server is, by design, hands off of a lot decisions, allowing independent innovation. You can have a major, meaningful contribution to the core user experience without ever touching the core server code, by working on inter-client protocols, window managers, input methods, toolkits, compositors, desktop panels, etc., etc., etc.
Every programmer likes the idea of a clean break. Experienced programmers usually know that the grass might be greener now if you rip out Chesterson’s fence, but it won’t stay that way for long.
Keep running it then, nobodies stopping you if it works, it just won’t be updated.
With all the posturing you’d think someone would have stepped up to maintain it; based on this comment you have the capability.
Like I said before, I had one issue with it recently, last year, and the bug report got a quick reply and it was fixed.
I don’t know what you expect from an open source maintainer, but replying promptly to issues, reviewing and merging merge requests, and fixing bugs is what I expect from them. And that’s what I got out of the upstream X team, so I can’t complain. Maybe I’m the lucky one, idk, but worst case, if it does ever actually get abandoned, yeah, compiling it was way easier than I thought it would be, so I guess I could probably do it myself. But as of this writing, there’s no need to.
Yes, I remember looking at the code of
xinit(that is supposed to be a small shell script just to start the X server) and it was… bad to say the least. I also had some experience implementing a protocol extension (Xrandr) in python-xlib and while I was surprised it worked first try with me just following the X11 documentation at the time, it was really convoluted to implement even including the fact that the code base of python-xlib already abstracted a lot for me.I don’t know if I designed a replacement of X.org it would like Wayland, I think the least X.org needed was a full rewrite with lots of testing, but it wouldn’t happen considering even the most knowledge people in its codebase don’t touch parts of it because of fear. If anything, Wayland is good because there are people that have entusiasm hacking its code base and constantly improving it, something that couldn’t be said about X.org (that even before Wayland existed, had a pretty slow development).
I think a lot of the hate happens because “it has bugs” magnifies every other complaint.
The xdg-portal system certainly addresses things like screensharing on a protocol level. But pretty much every feature that depends on it – screen sharing, recording etc. – is various kinds of broken at an application level.
E.g. OBS, which I have to use like twice a year at most, currently plays a very annoying trick on me where it will record something in a Wayland session, but exactly once. In slightly different ways – under labwc the screen video input only shows up the first time, then it’s gone; on KDE it will produce a completely blank video.
I’m sure there’s something wrong with my system but a) I’ve done my five years of Gentoo back in 2005, I am not spending any time hunting bugs and misconfiguration until 2035 at the very least and b) that just works fine on X11.
If one’s goal is to hate Wayland, b) is juuuust the kind of excuse one needs.
I understand the frustration, but I was raised on X11 and these bugs sound extremely milquetoast compared to the graphical artifacting, non-starting and being impossible to debug, mesa incompatibility, proprietary extensions not driving the screen and the fucking “nvidia-xconfig” program that worked 20% of the time.
X11 is not flawless either, we got better at distro maintainers handling various hacks to make it function well enough- especially out of the box, but it remains one of the more brittle components of desktop linux by a pretty wide margin.
Oh, no, I’m not disagreeing, that was meant as a sort of “I think that’s why Wayland gets even more hate than its design warrants”, not as a “this is why I hate Wayland”. I mean, I use labwc, that occasional OBS recording is pretty much the only reason why I keep an X11 WM installed.
I’m old enough for my baseline in terms of quirks to be XFree86,
nvidia-xconfigfelt like graduating fromedto Notepad to me at some point :-D.mesa incompat wil bite people in WL too.
But then they’d be maintaining this new model and the rest of X.Org, which the maintainers could not do. It might not matter that it’s technically possible if it’s not feasible.
Wayland is the new model plus xwayland so that the useful parts of X11 keep working without them having to maintain all the old stuff.
Again, provably false - they are maintaining the rest of X.Org, first like you said, xwayland is a thing… that’s all the parts they said were obsolete and wanted to eliminate! But also from the same FAQ link:
A lot of the code is actually shared, and much of the rest needs very little work. So compared to what is actually happening today, not developing Wayland would have been less maintenance work, not more. All that stuff in the kernel, the DRI stuff, even the X server via xwayland, is maintained either way. Only difference is now they’ve spent 15 years (poorly) reinventing every wheel to barely regain usability parity because it turns out most the stuff they asserted was useless actually was useful and in demand.
I like to say Graphics are, at best, 1/3 of GUI. OK, let’s assume you achieved “every frame is perfect”. You still have a long way to go before you have a usable UI.
That’s like saying that we are maintaining both English and German language. Who are “they”? And X is very much in life support mode only - take a look at the commit logs.
XWayland is much smaller than the whole of X, it’s just the API surface necessary to keep existing apps working. That’s like saying that a proxy is a web browser..
Code sharing:
The DRM subsystem and GPU code is “shared”, as in it is properly modularized in Linux and both make use of it. If anything, Wayland compositors make much better use of the actual Linux kernel APIs, and are not huge monoliths with optional proprietary binary blobs. It’s pretty trivial to write a wayland compositor from scratch with no external libraries at all - where is the shared X code?
All right here, notice how xwayland is just one of the many “hw” backends of the same xserver core:
https://gitlab.freedesktop.org/xorg/xserver
There’s also backends for other X servers (xnest), Macs (xquartz), Windows (xwin), and, of course, the big one for physical hardware (xfree86, which is much smaller than it used to be - over 100,000 lines of code were deleted from there around 2008 - git checkout a commit from 2007 and find … 380k lines according to a crude
find | wcfor .c files, git checkout master and find 130k lines by the same measure in that hw/xfree86 folder. Yeah, that’s still a lot of code, but much less than it was, because yes, some if it was simply deleted, but also a lot of it was moved - so nowadays both the X server and Wayland compositors can use it).But outside of the hw folder, notice how much of the X server core code is shared among all these implementations, including pretty much every user-facing api and associated implementation bookkeeping in the X server.
XWayland not only is a whole X server, it is a build of the same X.org code.
“Maintaining” can mean different things. The X server is “maintained” in the sense that it’s kept working for the benefit of XWayland, but practically nobody is adding new features any more. Not having to maintain the “bare metal” backend also removes a lot of the workload in practice.
This is a much simpler and less work than continuing to try to add features to keep the X protocol up to date with the expectations of a modern desktop.
In other words, yes, the X server is maintained, in the sense that it’s in maintenance mode, but there’s very little active development outside of XWayland-specific stuff.
If you look at the Git tags on that repo, you’ll see that XWayland is also on a completely different release cadence now, with a different version number and more frequent releases. So even though it’s the same repo, it’s a different branch.
XWayland is not a mandatory part of the Wayland protocol, though. Of course they chose the easiest/most compatible way to implement the functionality, which will be to build on the real thing, but it’s a bit dishonest on your part to say that an optional part, meant to provide backwards compatibility, could be considered “shared code”.
I have to admit that I don’t know much about X.Org’s internals, but I think a lot of that stuff extracted to libraries and into the kernel is in addition to, not replacing, the old stuff.
For example X.Org still has to implement its own modesetting in addition to KMS. It has to support two font systems in addition to whatever the clients use. It has to support the old keyboard configuration system and libxkbcommon. It has to support evdev and libinput. It has to implement a whole graphics API in addition to kernel DRM.
Wayland can drop all this old stuff and just use the new. Xwayland isn’t X.Org, I don’t think it has to implement any of this. It’s “just” a translation layer for the protocol.
Please be careful about assuming what somebody else will find easy / less work. If the maintainers said they can’t support it anymore, I’m inclined to believe them. Sometimes cutting your losses is the easier option.
I think this is unfair to people working on Wayland. I know you don’t like it, but It’s an impressive project that works really well for many people.
I don’t think anybody was “asserting [features] are useless”, they just needed the right person to get involved. I’m assuming you mean things like screen sharing, remote forwarding, and colour management. People do this work voluntarily, it might not happen immediately if at all, and that’s fine.
XWayland does have to implement all the font/drawing/XRender/etc. stuff, since X11 clients need that to work. That’s part of its job as a “translation” layer.
(I should know, Xorg/XWayland does some unholy things with OpenGL in its GLAMOR graphics backend that no other app does, and it has tripped up our Apple Mesa driver multiple times!)
But the most important part is that XWayland doesn’t have to deal with the hardware side (including modesetting, but also multi screen, input device management, and more), which is where a lot of the complexity and maintenance workload of Xorg lies.
The core Wayland protocol is indeed just buffer exchange and update based on a core Linux subsystem. It’s so lean that it is used in car entertainment systems.
And HTTP 1.0 is another protocol, that can also be added to other programs. They are pretty trivial, obviously they can be incorporated into X. I can also attach an electric plug to my water plumping, but it wouldn’t make much sense either. Having two ways to do largely overlapping stuff, that will just overstep each other’s boundaries would be bad design.
Wayland has a ready-made answer to “every frame is perfect” – adding that to X would just make some parts of a frame perfect. Wayland also supports multiple displays that have different DPIs, which is simply not possible at all in X.
GPUs weren’t even a thing when X was designed - it had a good run, but let it rest now. I really don’t support reinventing the wheel unnecessarily, that seems all too common in IT, but there are legitimate points where we have to ask if we really are heading in the direction we want to go. It is the correct decision in case of X vs Wayland, as seen by the display protocols of literally every other OS, whose internals are pretty similar to it.
Then how do you explain it being implemented and functional and working in X (with Qt or KDE applications) since at least 2016? Its configuration is a bit janky https://github.com/qt/qtbase/blob/1da7558bfd7626bcc40a214a90ae5027f32f6c7f/src/gui/kernel/qhighdpiscaling.cpp#L488 but it does work.
EDIT: I posted a video comparison in this comment because I’m tired of arguing in text about something that is obvious when you see it in real life. X11 and Wayland are not the same, and only Wayland can seamlessly handle mixed DPI.
We already went over this in another thread here in the past. X11 does not implement different DPIs for different monitors today, and it doesn’t work out of the box (where you say “janky”, what you really mean is “needs manual hacks and configuration and cannot handle hotplug properly”).
Even if you did add the metadata to the protocol (which is possible, but hasn’t been done), it’s only capable of sudden DPI switching when you move windows from one screen to another.
X11 cannot do seamless DPI transitions across monitors, or drawing a window on two monitors at once with the correct DPI on both, the way macOS and KDE Wayland can, because its multi-monitor model, which is based on a layout using physical device pixels, is incompatible with that. There’s no way to retroactively fix that without breaking core assumptions of the X11 protocol, which would break backwards compatibility. At that point you might as well use Wayland.
Indeed and I am not sure why you keep repeating the same misconceptions despite being told multiple times that all these things do work in X11.
The links posted by @adam_d_ruppe are good, but I think the oldest post talking about it is oblomov’s blog post. He even had patches that implement mixed DPI for GTK on X11, but obviously the GTK folks would never merge something that would improve their X11 backend (mind you, they are still stuck on xlib).
It gets even funnier, because proper fractional mixed DPI scaling was possible in X11 long before Wayland got the fractional scaling protocol, so there was ironically a brief period not long ago where scaling was working better in XWayland than in native Wayland (that particular MR was a prime example of Wayland bikeshedding practice, being blocked for an obnoxious amount of time mostly because GTK didn’t even support fractional scaling itself, even quite some time after the protocol was added).
Yes it can and it works ootb with any proper toolkit (read: not GTK) and renders at the native DPI of each monitor switching seemlessly inbetween. We don’t even have to lock ourselfes to Qt, even ancient toolkits like wxWidgets support it.
This doesn’t work, neither on Wayland nor X11 and not a single major toolkit supports this usecase and for good reason, the complexity needed would be insane and you can forget basically about any optimizations across the whole rendering stack.
Also the whole usecase is a literal edge case in its own rights, I don’t think many people are masochist enough to keep a window permanently on the edge of different-DPI monitors for a long time.
It doesn’t work on KDE Wayland the way you think it does, you get the same sudden switch as soon as you move more than half over to the other monitor. If you don’t believe me, try setting one monitor to a scale factor that corresponds to a different physical size. Obviously you will not notice any sudden DPI changes if the scale factors end up as the same physical size, but that works in X11 too.
At this point the only difference is that X11 does not have native per-window atoms for DPI, so every toolkit adds their own variables, but that hardly makes any difference in practice. And to get a bit diabolical here, since Wayland is so keen on shoehorning every usecase they missed (i.e. everything going beyond a basic Kiosk usecase) through a sideband dbus API,
wp-fractional-scale-v1might as well have become a portal API that would have worked the same way on X11.After a decade of “Wayland is the future” it is quite telling that all the Wayland arguments are still mostly based on misconceptions like this (or the equally common “the Wayland devs are the Xorg devs” - not realizing that all of the original Wayland devs have long jumped the burning ship), while basic features such as relative-window positioning or god forbid I mention network transparency are completely missing.
Sigh.
I’m tired of pointless arguing, so here’s a video. This is what happens on X11, with everything perfectly manually configured through environment variables (which took some experimentation because the behavior wrt the global scale is a mess and unintuitive):
https://photos.app.goo.gl/H9TRvexd2SQWxLg28
This is what happens on Wayland out of the box, just setting your favorite scale factors in System Settings, with no environment variable tweaks:
https://photos.app.goo.gl/XjS36F2MbHye1F276
In both tests the screen configuration, resolution, relative layout (roughly*), and scale factors are the same (1.5 left, 2.0 right).
These two videos are not the same.
I guess I should also point out the tearing on the left display and general jank in the X11 video, which are other classic symptoms of how badly X11 works for some systems. This is with the default modesetting driver, which is/was supposed to be the future of X11 backends and is the only one that is driver-independent and relies on the Linux KMS backend exclusively, but alas… it still doesn’t work well. Wayland doesn’t need hardware-specific compositor backends to work well.
Also, the reason why I used a KDialog window is that it only works as expected with fixed size windows. With resizeable windows, when you jump from low scale to high scale, the window expands to fit the (now larger) content, but when you jump back, it keeps the same size in pixels (too large relative to the content now), which is even more broken. That’s something that would need even more window manager integration to make work as intended on X11. This is all a consequence of the X11 design that uses physical pixels for all window management. Wayland has no issue since it deals in logical/scale-independent units only for this, which is why everything is seamless.
Also, note how the window decorations are stuck at 2.0 scale in X11, even more jank.
* X11 doesn’t support the concept of DPI-independent layout of displays with different DPI, so it’s impossible to literally achieve the same layout anyway. It just works completely differently.
Funnily enough on my system the KDE Wayland session behaves exactly like what you consider so broken in the X11 session.
There is a lot to unpack here, but let’s repeat the obvious since you completely ignored my comment and replied with basically a video version of “I had a hard time figuring out the variables, let’s stick with the most broken one and just dump it as a mistake of X11”: What’s happening in the Wayland session is most certainly not what you think it is, Qt (or any toolkit for that matter) is not capable of rendering at multiple DPIs at the same time in the same window. As I stated before, something like that would require ridiculous complexity in the entire render path. Imagine drawing an arc somewhere in a low-level library and you suddenly have to change all your math, because you cross a monitor boundary. Propagating that information alone is a huge effort and let’s not even start with more advanced details, like rotated windows.
The reason why you see no jump in the Wayland session is because you chose the scaling factor quite conveniently so that it is identical in physical size on both monitors (and that would work on X11 too). Instead of doubling down, it would have taken you 5 seconds to try out what I suggested, i.e. set one of the scale factors to one with a different physical size (maybe 1.0 left, 2.0 right) and you will observe that indeed also Wayland cannot magically render at different DPIs at the same time and yes you will observe those jumps.
Now obviously your scaling factors of 1.5 vs 2.0 should produce the same result on X11. I don’t know your exact configuration, so I can only reach to my magic crystal ball, but since you already said you had a hard time figuring out the variables, a configuration error is not far fetched: Maybe you are applying scaling somewhere twice, e.g. from leftover hacks with
xrandrscaling or hardcoding font DPI, or kwin is interfering in a weird way (setPLASMA_USE_QT_SCALINGto prevent that). But honestly, given that you start your reply with “Sigh” and proceed to ignore my entire comment, I don’t think you are really interested in finding out what was wrong to begin with. If you are though, feel free to elaborate.In my case I have the reverse setup of yours, i.e. my larger monitor is 4k and my laptop is 1080p, so I apply the larger scale factor to my larger screen (I don’t even know my scaling factors, I got lucky in the EDID lotto and just use
QT_USE_PHYSICAL_DPI). So yes this means also on Wayland I get the “jump” once a window is halfway over to the next monitor. The size explosions are not permanent as you say though, neither on Wayland nor on X11.She obviously doesn’t think that that is what’s happening. In the comment you yourself linked, she explains how it works:
With this correct understanding, we can see that the rest of your comment is incorrect:
I just tried using the wrong DPI and there was no jump (I’m on Sway). On on screen, the window I moved was much bigger, and on the other, it was much smaller. But it never changed in size. The only thing that changed was the DPI it was rendering it, while seamlessly occupying the exact same space on each monitor as it did so. This works because Wayland uses logical coordinates instead of physical pixels to indicate where windows are located or how big they are. So when a window is told to render at a different scale, it remains in the same logical position, at the same logical size.
There is a noticeable change, but it’s just the rendering scale adjustment kicking in causing the text on the monitor the window is being moved into to become pixel sharp, and the text in the old monitor getting a bit of a blur.
My Mac refuses to show a window spanning two monitors.
This changed a few years ago to allow per-display spaces (what Linux calls “workspaces”) - presumably they decided they didn’t want to deal with edge cases where a window is on an active space on one monitor and an inactive space on another. (Or what happens if you move a space containing half a window across monitors?)
You can get the old behavior back by turning off Settings > Desktop & Dock > Mission Control > Displays have separate spaces.
Indeed - the fact that it does actually work, albeit with caveats, proves that it is, not, in fact, “simply not possible at all”.
We can discuss the pros and cons of various implementations for various use cases, there’s legitimate shortcomings in Qt and KWin, some of which are easy to fix* (e.g. the configuration ui, the hotplugging different configurations), some are not (the window shape straddling monitor boundaries), there’s some advantages so it too (possibly better performance and visual fidelity), but a prerequisite to a productive technical discussion is to do away with the blatant falsehoods that universally start these threads.
“You can do it, but….” is something reasonable people can discuss.
“It is simply not possible at all” is provably flat-out false.
I appreciate that you’ve now tried it yourself. I hope you’ll never again repeat the false information that it is impossible.
The use of quote marks here implies that the commenter you’re replying to used this exact term in their comment, but the only hit for searching the string is your comment.
I’m flagging this comment as unkind, because my reading of this and other comments by you in this thread is that you are arguing in bad faith.
https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_argozj
Try not to accuse people of personal attacks - which is itself a personal attack, you’re calling me an unkind liar - without being damn sure you have your facts right.
That’s a different person. The person you replied to did not say that.
This is what the person you replied to actually said:
Looking at the two videos it’s pretty obvious that they are not doing the same thing at all. That dialog window is not being drawn with the correct DPI on each monitor, it’s either one or the other. “Mixed” is sufficiently elastic a word that I’m sure some semantic tolerance helps but I’m not exactly inclined to call that behaviour “mixed”, just like I also can’t point at the bottle of Coke in my fridge, the stack of limes in my kitchen and the bottle of rum on my shelf and claim that what I actually have is a really large Cuba Libre. (Edit:) I.e. because they’re not mixed, they’re obviously exclusive.
I don’t know if that’s all that X11 can do, or if it’s literally impossible to achieve what @lina is showing in the second video – at the risk of being an embarrassment to nerddom everywhere I’ve stoped caring a few years back and I’m just happy if the pixels are pixeling. But from what I see in the video, that’s not false information at all.
100% the same thing as Wayland is impossible in X. It can’t handle arranging mixed DPI monitors in a DPI-independent coordinate space, such that rendering is still pixel perfect on every monitor (for windows that don’t straddle monitors). X11 has no concept of window buffer scale that is independent of window dimensions.
The closest you can get is defining the entire desktop as the largest DPI and all monitors in that unit, then having the image scaled down for all the other monitors. This means you’re rendering more pixels though, so it’s less efficient and makes everything slightly blurry on the lower DPI monitors. It’s impossible to have pixel perfect output of any window on those monitors in this setup, and in practice, depending on your hardware, it might perform very poorly. It’s basically a hacky workaround.
This is actually what XWayland fakes when you use KDE. If you have mixed DPI monitors, it sets the X11 DPI to the largest value. Then, in the monitor configuration presented via fake XRandR to X11 clients, all monitors with a lower DPI have their pixel dimensions scaled up to what they would be at the max DPI. So X11 sees monitors with fake, larger resolutions, and that allows the relative layout to be correct and the positioning to work well. If I had launched KDialog under KDE Wayland with the backend forced to X11, it would have looked the same as Wayland in the video in terms of window behavior. It also wouldn’t have any tearing or glitches, since the Wayland compositor behind the scenes is doing atomic page flips for presentation properly, unlike Xorg. The only noticeable difference would have been that it’s slightly less sharp on the left monitor, since the window would be getting downscaled there.
That all works better than trying to do it in a native X11 session, because XWayland is just passing the window buffers to Wayland so only the X11 windows get potentially scaled down during compositing, not the entire screen.
Where it falls apart is hotplug and reconfiguration. There’s no way to seamlessly transition the X11 world to a higher DPI, since you have to reset all window positions, dimensions, monitor dimensions and layout, and client DPI, to new numbers. X11 can’t do that without glitches. In fact, in general, changing DPI under X11 requires restarting apps for most toolkits. So that’s where the hacky abstraction breaks, and where the proper Wayland design is required. X11 also doesn’t have any way for clients to signal DPI awareness and can’t handle mixed DPI clients either, so any apps that aren’t DPI aware end up tiny (in fact, at less than 1.0 scale on monitors without the highest DPI). This affects XWayland too and there’s no real way around it.
At best, in XWayland, you could identify which clients aren’t DPI aware somehow (like manual user config) and give them a different view of the X11 world with 1.0 monitor scales. That would mostly work as long as X11 windows from both “worlds” don’t try to cooperate/interact in some way. KDE today just gives you two global options, either what I described or just always using 1.0 scale for X11 (which makes everything very blurry on HiDPI monitors, but all apps properly scaled).
That’s what I thought was happening, too, but I wasn’t really sure if my knowledge was up-to-date here. Like I said, I’m just happy if my pixels are pixeling, and I didn’t want to go down a debate where I’d have to read my way through source code. This end of the computing stack just isn’t fun for me.
This isn’t a term we invented in this thread, it is very common, just search the web for “mixed dpi” and you’ll find it, or click the links elsewhere in this thread and see how it is used.
A blog posted in a cousin comment sums it up pretty well: “A mixed-DPI configuration is a setup where the same display server controls multiple monitors, each with a different DPI.”
(DPI btw formally stands for “dots per inch”, but in practice, it refers to a software scaling factor rather than the physical size because physical size doesn’t take into account the distance the user’s eyes are from the display. Why call it DPI then? Historical legacy!)
Or, if that’s too far, go back to the grandfather post that spawned this very thread:
“displays that have different DPIs”, again, the common definition spelled out.
What, exactly, happens when a window straddles two different monitors is implementation-dependent. On Microsoft Windows and most X systems, the window adopts the scaling factor for the monitor under its center point, and uses that across the whole window. If the monitors are right next to each other, this may cause the window to appear non-rectangular and larger on one monitor than the other. This is satisfactory for millions of people. (I’d be surprised if many people actually commonly straddle windows between monitors at all, since you still have the screen bezel at least right down the middle of it… I’d find that annoying. It is common for window managers to try to snap to monitor boundaries to avoid this, and some versions of Apple MacOS (including the Monterey 12.7.6 I have on my test computer) will not even allow you to place a window between monitors! It makes you choose one or the other.)
edit: just was reminded of this comment: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_1f0zhn and yes that setting is available on my mac version, but it requires a log out and back in. woof. not worth it for a demo here, but interesting that Apple apparently also saw fit to change their default behavior to prohibit straddling windows between monitors! They apparently also didn’t see much value in this rare use case. /edit
On Apple operating systems and most (perhaps all?) Wayland implementations… and some X installs, using certain xrandr settings (such as described here https://blog.summercat.com/configuring-mixed-dpi-monitors-with-xrandr.html), they do it differently: the window adopts the highest scaling factor the window appears on (or is present in the configuration? tbh im not exactly sure), using a virtual coordinate space, then the system downscales that to the target area on screen. This preserves its rectangular appearance - assuming the monitors are physically arranged next to each other and the software config mirrors that physical arrangement… and the OS lets you place it there permanently (but you can still see it while dragging at least) - but has its own trade offs; it has a performance cost and can lose visual fidelity (e.g. blurriness), especially if the scale factors are not integer multiples of each other, but sometimes even if they are because the application is drawing to a virtual screen which is scaled by a generic algorithm with limited knowledge about each other.
In all these cases, there is just one scale factor per window. Doing it below that level is possible, but so horribly messy to implement, massive complexity for near zero benefit (again, how often do people actually straddle windows between monitors?), so nobody does it irl. The difference is the Mac/Wayland approach makes it easier to pretend this works… but it is still pretending. The illusion can be pretty convincing a lot of the time though, like I said in that whole other lobsters link with lina before, I can understand why people like this experience, even if it doesn’t matter to me.
The question isn’t if the abstraction leaks. It is when and where it leaks.
I tried to before posting that since it’s one of those things that I see people talking past each other about everywhere, and virtually all the results I get are… both implementation-specific and kind of useless, because the functional boundary is clearly traced somewhere and different communities seem to disagree on where.
A single display server controlling multiple monitors, each with the same DPI is something that X11 has basically always supported, I’m not sure how that’s controversial. Even before Xinerama (or if your graphics card didn’t work with Xinerama, *sigh*) you could always just set up two X screens, one for each monitor. Same display server, two monitors, different DPIs – glorious, I was doing mixed DPI before everyone was debating it, and all thanks to shitty S3 drivers and not having money to buy proper monitors.
But whenever this is discussed somewhere, it seems that there’s a whole series of implicit “but also” attached to it, having to do with fractional scaling, automatic configuration, what counts as being DPI-aware and whatnot.
So it’s not just something we invented in this thread, it’s something everyone invents in their own thread. In Windows land, for example, where things like getting WM_DPICHANGED when the window moves between monitors are a thing, you can query DPI per window, and set DPI awareness mode per thread, I’m pretty sure you’ll find developers who will argue that the xrandr-based global DPI + scaling system we’ve all come to know and love isn’t mixed-DPI, either.
(Edit:) To be clear – I haven’t used that system in a while, but as I recall, the way it worked was it set a global DPI, and you relied on the display server for scaling to match the viewports’ sizes. There was no way for an application to “know” what DPI/scaling factor combination they were working with on each monitor so they could adjust their rendering for whatever monitor they were on (for their implementation-defined definition of on, “on”, sure – midpoint, immediate transition, complete transition, whatever). Toolkits tried to shoehorn that in, but that, too, was weird in all sorts of ways and assumed a particular setup, at least back in 2016-ish or however long ago it was.
Well, I wouldn’t call that not mixed dpi, but I would call it suboptimal. So it seems you’re familiar with the way it works on Windows: move between monitors or change the settings in display properties, and the system broadcasts the WM_DPICHANGED message to top level windows that opted into the new protocol. Other windows are bitmap scaled to the new factor, as needed.
Applications use the current DPI for their monitor in their drawing commands - some of this is done automatically by the system APIs, others you multiply out yourself. You need to use some care not to double multiply - do it yourself, then the system api does it again - so it is important to apply it at the right places.
Your window is also automatically resized, as needed, as it crosses scaling boundaries, by the system.
Qt/KDE tries to apply similar rules… but they half-assed it. Instead of sending a broadcast message (a PropertyChange notification would be about the same in the X world), they settled for an environment variable. (The reason I know where that is in the source is that I couldn’t believe that’s the best they did…. for debugging, sure, but shipping that to production? Had to verify but yes, that’s what they shipped :( the XWAYLAND extension has proposed a property - see here https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1197 - but they couldn’t agree on the details and dropped it, alas) There’s also no standard protocol for opting out of auto scaling, though I think XWAYLAND proposed one too, I can’t find that link in my browser history so I might be remembering wrong.
The KDE window manager, KWin, tries to apply scale as it crosses monitor boundaries right now, just like Windows does, but it seems to only ever scale up, not back down. I don’t know why it does this, could be a simple bug. Note that this is KWin’s doing, not Qt’s, since the same application in a different window manager does not attempt to resize the window at all, it just resizes the contents of the window.
But, even in the half-assed impl, it works; the UI content is automatically resized for each monitor’s individual scale factor. User informs of each monitor’s scale factor, either by position or by port name (again, half-assed, it should have used some other identifier which would work better with hotplugging, but does still work). If a monitor configuration changes, xrandr sends out a notification. The application queries the layout to determine which scaling factor applies to which bounding box in the coordinate space, then listens to ConfigureNotify messages from the window manager to inform them of where they are. Quick check of rectangle.contains(window_coordinate) tells it what scale it has, then this fires off the internal dpi changed event, if necessary. At this point, the codepaths between X and Windows merge as the toolkit applies the new factor. At this point, the actual scaling is done client side, and the compositor should not double scale it… but whether this works or not is hit and miss, since there’s no standardization! (The one nice thing about xwayland is they’re finally dismissing the utter nonsense that X cannot do this and dealing with reality - if the standard comes from wayland, i don’t really care, i just want something defined!)
A better way would be if the window manager sent the scale factor as a ClientMessage (similar to other EMWH messages) as it crosses the boundary, so the application need not look it up itself, which would also empower the user (through the window manager) to change the scale factor of individual windows on-demand - a kind of generic zoom functionality - and to opt some individual windows out of automatic bitmap scaling, even if the application itself isn’t written to support it. I haven’t actually implemented this in my window manager or toolkit; the thought actually just came to mind a few weeks ago in the other thread with lina, but I’d like to, I think it would be useful and a nice little innovation.
As a practical matter, even if the window manager protocol is better, applications would probably still want to fallback to doing it themselves if there is no window manager support; probably query
_NET_SUPPORTED, and if absent, keep the DIY impl.None of this is at all extraordinary. Once I implement mine, I might throw it across the freedesktop mailing list, maybe even the xwayland people, to try to get some more buy-in. Working for me is great - and I’ll take it alone - but would be even nicer if it worked for everybody.
If a framework has to go way out of its way to implement some hack to make it work despite X’s shortcomings, but all the other frameworks don’t support it at all, then X simply doesn’t support this feature.
Also, take a look at @lina ’s videos.
I want to preface this by saying: 1) I run neither X nor Wayland 99% of the time; the kernel’s framebuffer is usually enough for my personal needs; 2) it’s been months since I tried Wayland on any hardware.
That said, the one thing I seemed to notice in my “toe dip” into the Wayland world was pretty problematic to me. When I would start X to run some graphical config tool on a remote machine with no GPU and low-power CPU, it seemed to me that “ssh -X” put almost no load on the remote computer; however, attempting to run the same via waypipe put a lot of load on the remote machine, making it essentially unusable for the only things I ever needed a graphical interface for.
If I’ve incorrectly understood the root cause here, I’d love to have someone explain it better. While I don’t use either one very often, it’s clear that X11 is not getting the development resources wayland is, and I’d like to be able to continue using my workflow decades into the future…
The primary reason for Wayland was the security model, was it not? That I believe is truly unfixable. And if you’ve decided to prioritize that, then it makes sense to stop working on X.
No, the primary reason for Wayland is, in Kristian Høgsberg’s words, the goal of “every frame is perfect”.
And even if security was the priority… X also “fixed” it (shortly before Wayland was born; X Access Control Extension 2.0 released 10 Mar 2008, Wayland initial release 30 September 2008), but it never caught on (I’d argue because it doesn’t solve a real world problem, but the proximate cause is probably that the XACE is all code hooks, no user-friendly part. But that could be solved if anybody actually cared.)
Worth noting that Microsoft had man of the same questions with Windows: they wanted to add a compositor, add elevated process isolation, per-monitor fractional scaling, all the stuff people talk about, and they successfully did it with near zero compatibility breaks, despite Win32 and X sharing a lot of functionality. If it were fundamentally impossible for X, it would have been fundamentally impossible for Windows too.
Security can’t be solved retroactively. You can’t plug all the holes of a swiss cheese.
“Solutions” were nesting X servers into one another and such, at that point I might as well run a whole other VM.
And good for windows, maybe if we would have the legacy X API available for use under Wayland, so that Wayland’s security benefits could apply, while also not losing decades of programs already written, we could also have that for linux.. maybe we could call it WaylandX! [1]
[1] Arguably this name would make more sense
No they weren’t. X11 is a client-server protocol. The only things that a client (app) sees are messages sent from the server (X.org). The default policy was that apps were trusted or untrusted. If they were untrusted, they couldn’t connect to the server. If they were trusted, they could do anything.
The security problems came from the fact that ‘anything’ meant read any key press, read the mouse location, and inspect the contents of any other window. Some things needed these abilities. For example, a compositing window manager needed to be able to redirect window contents and composite it. A window manager that did focus-follows-louse needed to be able to read all mouse clicks to determine which window was the current active one and tell the X server to send keyboard events there. A screenshot or screen sharing app needed to be able to see the rendered window or sceen contents. Generally, these were exceptions.
The X Access Control Extensions provided a general mechanism (with pluggable policies) to allow you to restrict which messages any client could see. This closed the holes for things like key loggers, while allowing you to privilege things like on-screen keyboards and screenshot tools without needing them to be modified. In contrast, Wayland just punted on this entirely and made it the compositor’s problem to solve all of these things.
Microsoft has literal orders of magnitude more people to throw at backcompat work.
They also have literal orders of magnitude more users to create backcompat work in the first place, though.
Nothing wrong with that per se, but I’m wondering - if you stumble over that (and don’t see the (current) HTML version linked, like in this repo) - what do you typically do?
So far I’ve been at “sigh, then build the software and view them without installing” - but for people who don’t regularly package software or write manpages themselves… is there an easy way? a quick hack?
My instinct was just to read them out of the GitHub repo - the raw source is just about human-readable.
Yup, I saw this in HN some days ago. It’s been in my plans for a while, but hopefully this works well enough for my purposes.
If you use NoScript for browsing, it’s infuriating how many websites that absolutely do not need JS render as blank pages. And if you active NoScript, well, they require a beefy CPU to move.
One of the offenders that rub me worst is Mastodon, because of its federated nature, adding NoScript exceptions is a pain. I kinda pondered contributing to some Mastodon client to be able to navigate through threads. (Tusky on Android kinda does this.) I don’t know it’s because my account is on a Takahe server, or if this happens to Mastodon users too, but I tend to get partial threads locally, which means if I want to reply, I’d better check the upstream thread to see if I’m repeating what someone already said.
This is a known issue across most/all fedi implementations - the only messages you get in threads are messages that your instance holds for some other reason, for example because someone on your instance follows the author. There’s an outstanding PR to Mastodon upstream to explicitly fetch all replies, and I imagine in time the same approach will be duplicated by other implementations.
One more thing to know is: an impressive number of pages render as blank if you drop JS… and render just fine if you drop both JS and CSS.
Interesting. I’ve not validated this, but sometimes Firefox shows me Reader Mode in what looks a blank page… and it works. It might be a symptom of this phenomenon.
The tech worker stuff I saw back in 2016-2017 was not compelling. When Macej came through town, he seemed more interested in riling us up to give donations to defeat Trump than to, you know, work on common issues like contracts.
During a stint in Brooklyn in 2019, I attended a TWC event (I think it was them, could’ve been somebody else) and was summarily unimpressed with the organizing efforts–least of all the amount of time spent by a Google contractor who, bless her heart, didn’t seem to understand that they weren’t actually there for her but for “real employees”. There was also a bunch of time wasted with the usual progressive genuflections.
For the past several years, I’ve had the pleasure of watching a CWA shop play out its bargaining from up close, and seen the slow disillusionment of the bargaining unit with the process–as a comrade noted after bouncing from the place, “having a union just means you get to help hold the knife when layoffs come”.
If I had to sum up many of my criticisms and observations (and this is heavily anchored in a US background):
If I ever get my blog back up, I could write a small treatise on all of this.
What? Immigrant/offshore workers can act as scabs, of course, but I don’t see why this is a fundamental truth. Immigrants can be union workers too.
It’s not a fundamental truth. It’s cherry-picking of the most dysfunctional traits a union can have to build a strawman that is the easiest to shoot down and feel more intelligent about it.
Typed by an immigrant union organizer in a “Migrant Organizing Unit”.
Are you in the US, or elsewhere (as I gather from your profile)? I was pretty clear I was addressing the US operating regime–if you’re in Germany or whatever you have a different kettle of fish.
The de facto purpose of getting H1-B visas in the US is to have a captive workforce that can work more cheaply than native labor. If they cost the same to employers, I wager they wouldn’t be as attractive to hire. Here, go look for yourself–“some of these things are not like the others”, as one might say.
The de facto purpose of globalization is to export work processes to where it’s cheaper to have them occur, whether that’s due to avoiding expensive environmental regulations, expensive worker compensation, expensive resource extraction, or whatever else. If you are a union, you do not want your employer to get labor elsewhere.
I’m explaining this not to excuse any of it but to make sure anybody (in the US, again) who is looking at solving the puzzle knows more of the pieces and dynamics at play, and to encourage people to look past whatever easy ideology they likely to have have because they’re (comparatively) wealthy and in tech because it will fail them as times get rough (and times, they are getting rough).
If you want to make a useful contribution @chobeat instead of just sniping at me perhaps you could share your experience and background with a “Migrant Organizing Unit” and talk about what works, what doesn’t, and where they show up.
Not that I have any more experience with labor organization than yourself but unionism breaks into different strains and your conception of it is called business unionism, where a specific union exists solely to forward the narrow economic self-interest of its then-existing membership. Other conceptions of unionism include labor liberalism, where unions exist for workers as a class to more effectively lobby the state (which is the source of the association with dem party politics you saw) and also class struggle unionism, which takes an explicitly combative approach with capital and also involves the sort of “ideological baggage” you talk about. The latter tends to take a “workers of the world unite” type approach and does not inherently view immigrants or workers elsewhere as scabs. Whether this last strain actually makes any sense when operating from within the imperial core can certainly be debated. But anyway I’m not here to argue for one conception or the other, just to say that your conception of what a union is is not the only one. Most of the ideas in this post come from the book Class Struggle Unionism by Joe Burns.
Excellent pointers on terminology, thank you–will doubtless incorporate that in the essay!
This is true, but I’m not sure how you get from there to “unions must be anti-immigrant”.
A union’s goal should be to get a collective agreement that covers immigrant workers too, so they’re no longer cheaper. Maybe that means they hire fewer immigrants (though I honestly don’t think there would be a noticeable effect in tech), but the immigrants they do hire would get much better working conditions, I’d call that pro-immigrant. I think immigrant workers would gladly sign on to that.
We are stronger together than apart. Your point about divisions along political alignment lines applies to division between citizens and immigrants, if we exclude them, we just set ourselves up to get scabbed on.
An immigrant who is established enough in their new country to be a union worker now also has an economic incentive to oppose further immigration from the place they originally came from, just as native workers in the same union do.
This isn’t true and the history of labour organising shows how excluding people on the basis of race, sex, nationality, homelessness, etc makes a union weaker. (E.g. IWW organising “hobos” in a logging industry dispute. Listen to Cool People Who Did Cool Stuff for more examples).
You may also be making the “lump of labour fallacy”.
If they only think in terms of narrow, first-order effects, sure.
I acknowledge your stated intentions here about inspiring people to adapt tactics. But this is not a forum where your coparticipants are union insiders with the power to make the kinds of changes you want.
The primary net impact of sucking up all the oxygen in a discussion space with a huge critique post like yours is going to be to dissuade potential new organisers from engaging. Instead of leading to the change you want to see, it’s more likely contributing to further entrenching the structures and strategies you dislike by depriving the labour movement of the new blood it depends on to refresh its thinking.
You seem pretty well read on this general topic. If you ever do get that blog post series written, I’d encourage you as a next step to consider ways of putting the ideas into practice through real organising. The labour movement has plenty of armchair generals who can tell you a million reasons why this or that aspect of how things are done is doomed to failure. As in any other field of endeavour, you earn your influence over the direction things take by the merits of your prior contributions. It’s unlikely for a Substack authored by someone who attended a TWC event in Brooklyn six years ago and knows some people at a place with a union deal is going to produce the outcomes you want to see on its own.
Thanks for typing this up, I would read more if you wrote more.
Once again begging progressive people to learn how money works and read the FT.
and how did you contribute to make this better?
Because of the aforementioned adversarial nature of unions in the US, I can neither confirm nor deny any actions I may or may not have taken that may have facilitated, directly or indirectly, a bargaining unit’s progress.
Nice attempt at a gotcha though! Maybe consider the solidarity part of worker solidarity, friendo. They want us buddyfucking each other.
Less glibly: I believe that by explaining these issues, especially around the dynamics of unionization in the US in tech, there’s a better chance to adapt tactics and find a path forward that better serves tech workers. I suspect that something other than the current union framework in the US would actually be more to our benefit, perhaps a guild system or similar. I see too much cheerleading from the latte class who haven’t either formed, worked with, or managed members of a bargaining unit in tech, and that cheerleading I have seen mislead and screw workers who made the simple mistake of trying to do what they were told would magically solve all their problems.
Union as aesthetic don’t work.
It’s a shame this doesn’t compare the Apple cable to other cables which support the same features.
Right?
I feel the other thing that isn’t addressed is, sure the Apple connector is much fancier and has much more amazing design stuff or whatever, maybe such that it is “worth” the price due to cost of construction.
But it doesn’t address the elephant in the room: does all that complexity and design actually make a meaningful difference?
Like someone could make a laptop with a case made out of solid gold and sure it would be “worth more” than the non solid gold ones, but does that actually mean it is actual worth the cost? The use of gold makes it more expensive but it doesn’t make it better
Basically rehashing the same weak position seen in the Adam Savage video.
This is one of the better criticisms of bsky/atproto I’ve read. So glad to read a good one. Just two comments:
DMs were added out of protocol for exactly the reason the author suspects: users were clamoring for this functionality, and doing it right will take a while. So they’ve alluded to plans to bring them back into the protocol, but for now, most people are okay with trusting Bluesky and being able to do what they want to do. It’s effectively a non-regression from the point of “I’m migrating from Twitter.”
It seems like this integration has disappeared, as far as I can tell. They didn’t say anything about it publicly that I saw.
Trusting Bluesky for DMs privacy wise definitely beats whatever the DM situation is on Mastodon where you have to trust random admins you do not know.
Personally I am baffled by this mindset. How can a company that has every incentive to data mine everything that touches their servers be any better than a random dude without any such incentive. Granted the dude might be a creep, but I think these people get found out pretty quick… the simile of “many eyes make all bugs shallow” can be applied here. People smell a rat quite quickly on the internet.
I think both are reasonable. Some people prefer to only need to trust one party, instead of needing to re-figure out trust every time they message someone on a different server.
I personally just never put anything that I wouldn’t mind others reading into something that’s not E2E encrypted. I wouldn’t put something into a bsky DM that I would be upset with the team reading anyway.
I do think the risk is smaller than a lot of people make it out to be, but the odds of my fedi admin knowing and caring enough about me to snoop on my messages is significantly higher than that of a Twitter sysadmin.
I am actually exploring a user encrypted storage option for the ActivityPub service I develop.
Theoretically vanilla ActivityPub should support everything out of the box, but I don’t know for sure if the HTTP-Signatures that the protocol uses for inter-instance authorization would work when the private keys are not stored on the server itself but only on the client.
Why would you think that?
Because a lot of people are on fedi instances operated by their friends, or (if they aren’t already friends) users and admins on small-medium instances will inevitably get to know each other. There’s a lot more motivation to snoop on people you know, because by and large you don’t care about the private lives of complete strangers (and, frankly, it’s much more likely to cause me problems if someone I know snoops on my messages compared to some twitter sysadmin I’ve never met).
Obviously you’d hope nobody’s going around snooping on their friends’ posts, but people you thought you liked turn out to be shitty sometimes.
OK that makes sense.
I guess the snooping that large companies are incentivized to do has a more diffuse impact, like everyone buying slightly more useless junk, with less risk of acute harms as long as you stay within certain bounds.
Bluesky and Mastodon have enough public data. There is little incentive to go after private data. It’s high risk, low reward.
It’s worth saying that Elon Musk can read any DM ever sent on X.
Can he? I thought Twitter DMs were E2E except group chats and media.
As usual, Elon lied about a feature: https://9to5mac.com/2023/05/11/twitter-encrypted-dms-3/
How is it I keep needing to lower my expectations?
I generally agree with you, but I think the idea is weighing the difference between a corporate entity which nominally has certain legal compliance obligations and may offer a degree of transparency versus a completely random individual human answerable and transparent to nobody. Neither is inherently trustworthy, but they are certainly untrustworthy in different ways for different reasons.
Companies are very careful with private data beyond what the TOS permits for good reasons. Individuals are always problematic even with the best intentions. You lurking at private data in a company is a firing offense. You doing that out of power on a mastodon server is something that would not be spotted let alone be something that’s particularly problematic for you.
20 years ago I had an email address managed by an acquaintance of an acquaintance and eventually we figured out that they had a bash script running looking for keywords. Was definitely a lesson for me.
Google knowing what’s in my e-mail affects me far less than people I know and deal with regularly knowing what’s in my e-mail, simply because I don’t personally know Google and they don’t know me, and have no direct personal or emotional involvement in me. Likewise, if I’m on a mastodon server run by someone I know, them knowing what I’m DMing about is creepier by default. Imagine if you texted a friend about relationship troubles. Would you prefer someone else you know having access to that or an impartial, unrelated entity like Google?
This is, of course, assuming E2EE is not an option, which is true for both alternatives in consideration.
In a non-E2EE situation, I trust a company (or any other organisation) much more for this kind of problem than a random, unspecified, sometimes unknowable person on an instance I haven’t chosen (the administrator of the personal instance of the person I’m talking to ‘in private’).
By what mechanism are Bluesky admins specified, knowable or subject to your choice?
But the thing is that on the Fediverse you can join an instance that has a well known community and sysops. And, with the risk of repeating the same trite thing as everyone else: you can always host your own. :P
I can’t choose the admin of the instance of my recipient, and they can’t do either for mine, so I think that point is moot?
(And I’ll reply what everyone else may have replied to you before: not everyone can host their own, it’s a common fallacy but not everybody has the technical knowledge, free time or purchasing power to rent a server to do so.)
OTOH all the admins are (supposed to be) trusted by at least one person in the conversation, so they’re not random completely untrusted people.
Why do you think the company has this incentive but the random dude doesn’t?
Why does “trust and ditch if they turn out to be a creep” policy apply to a random dude and not a company?
Because selling data on users is how companies with free services usually get money. The dude doesn’t because probably there’s no market for not mass sourced data, but I might be wrong.
It does, of course, but currently there’s only one Bluesky, so there’s nowhere else to go if you ditch them.
Well, I think that you could replace “DM” with “emails” in that context, and still get a clear picture of how much people care about that, in general.
As super techno-geeks living in the future /s, it would be nice to offer something more private to the world, rather than repeat the same mistakes. I understand Bluesky may have been pressed by time/resources to ship DMs. I can only hope that they will improve on this first version.
I definitely think adding DMs was a mistake. They weren’t ready to do it right, and really there’s no reason to do it at all. We have dozens of chat protocols already we didn’t need another half baked one.
I’m very interested in the novel stuff atproto is doing for the social space. The bolt on, less interesting.
Funnily enough the GNU social people were saying exactly the same thing when Mastodon was adding DMs. The lack of proper security against admins (plus footguns where @-ing someone you were talking about added them as a recipient) made it a pretty compromised thing. To this day I think we’d be better off using different tools for broadcast and for private chat.
Yoy could even pick one and integrate it in your mastodon, bsky, whoever UI same as the DMs, but using a battle tested protocol instead of NiH
I had my first lunch today organized through bsky dm, so yes it’s very nice to have this feature in there.
i appreciated this article a lot. i’m already on fediverse but this article took a measured approach that i really appreciate.
i’m confused about something though: do deletes in bluesky actually delete? from the docs (https://atproto.com/specs/repository):
and then from the FAQ (https://bsky.social/about/blog/5-19-2023-user-faq):
so i don’t quite understand. are they going back and re-writing the tree history? or when you download someone else’s data repo (which seems to be a core design feature (i think i’m into it)), do you just see all their deleted posts also?
sorry if i’m stepping into discourse – i haven’t followed the technical details of atproto too closely until now.
As best I can tell (context: have a back burner project to reimplement all this, so I’ve looked into the details, but very possible I’m missing something), a bluesky repo is a merkle tree, ie a data structure where the pointers are hashes. But crucially, unlike git or a blockchain, that data structure isn’t a linked list, it’s a B tree. So removing/updating an object requires replacing a few hashes, but it’s O(log n), not O(n).
For a sufficiently big n that doesn’t sound so good anymore. And I imagine that when dealing with twitters numbers of DAUs you will hit this.
I also wonder how the whole thing will play out once they have to deal with that amount of deletion requests (from users and various legal entities). Especially for content that is illegal to even store - but is now distributed through all feed listeners.
Which all in all sounds like an actually decentralized social network of global size might not be feasible - unless you have a centralized but globally regulated group to operate the DB and servers. In which case you don’t have to pay the replication fee but everyone has access. - Except this comes with global politics. (There are a few similarities to our internet.)
The entire Merkle tree business is per-user.
Oh that changes things. You still need the power of rehashing everything - and telling everything they get force pushed but still.
It doesn’t help however with the global deletion request and operation of open relays.
Even at Twitter size, logarithms scale well.
Say there are 500 million daily tweets and 50 years of history for a total of about 10 trillion stored messages, and say they’re all stored in the same tree. If it’s log base 10, then the cost to remove/update a message is only ~13 times higher than it was when there was only one message. Or if it’s log base 2, then the cost is ~40 times higher than it was when there was only one message.
ah fantastic, thank you :)
Has Bluesky actually progressed beyond decentralization in name only, or is it still just the one provider? If Bluesky the company shut their doors tomorrow, would the network survive?
I don’t know (or, to be honest, care that much) about the relative merits of bluesky’s protocol vs ActivityPub, but I am suspicious of the lack of actual federation occurring with bluesky. Mastodon isn’t perfect, but it exists and is actually decentralised in practice, not just on paper.
Not sure why this old meme is back again, when Bluesky has clearly progressed far enough now and you can host your own PDS with relative ease (for the Lobsters demographic).
It’s possible I’ve missed something but the PDS seems like the least interesting part. To get a coherent view of the network, all relevant PDSes need to be pushing to and the AppView need to be reading from the same relay (or set of relays). I am dubious that this is going to be tidy when groups start fragmenting into their own relays, particularly when the experience for the mainstream is that “it just works because I use the official ones so y’all could just stop trying to do something weird”.
This is my understanding as well; running your own PDS is viable but doesn’t really give you much benefit because everyone who will find your stuff will be doing so thru the centralized index run by an organization that is accountable to no one.
You can host your own PDS with ease; how does one use a PDS to communicate with another Bluesky user, without Bluesky-the-company being involved? My understanding is that it involves spinning up quite a lot of other stuff, and asking that other user to reconfigure their setup.
Just spun up a PDS for myself today! I’m feeling optimistic about Bluesky. I feel like it will be decent assuming there’s a committed effort among people to run servers and get some friends on them.
All the components are far enough along that the network would probably survive in some form. It has too many good ideas built into it for no one to run with it. There are already independent PDSes, experiments in running relays, and it just came out how easy it is to run the actual Bluesky web app: https://bsky.app/profile/joelhooks.com/post/3l7syfl7xqk2g
How many 3rd-party hosts exist right now? Let’s assume I don’t want to run it myself. How do I find them?
Some of the better perks of the system are still theoretical. It should end up good but it could also all go horribly wrong in some exciting way people write papers about for generations. I don’t know that I’ve seen any third-party PDSes that let other people use them.
Right now a lot operates on confidence in the people building it, the way the company is structured (the same structure that let it escape Twitter), and the fact that they keep delivering on the things they say they want to deliver on. That buys a lot of trust these days, but not everyone accepts the currency.
They’ve put out a paper that covers a lot of their thinking and plans.
alternative AppViews providing a microblogging experience do not exist right now (because they … honestly don’t really need to at the moment) – but the PDS stats (i.e. where the data lives) are “37 hosted by Bluesky, 927 hosted by third-parties (of which 263 are offline)”
and since Bluesky has 13 million users you can assume that each bsky PDS has about 350k account repos stored on it but the self-hosted ones probably only have one or two each
What would happen if plc.directory disappeared tomorrow?
Someone would have to set up a new one, and all the people who set a domain would have to update a TXT record. Everyone else would be lost in the drift.
That’s one thing I tried to address with this: https://lobste.rs/s/84tpv1/nobody_cares_about_decentralization#c_j5naod
One thing the devs talk about is moving the directory to an independent organization. It would have to be carefully set up to try and avoid the issues of DNS without creating new and worse problems. Right now using or building around Bluesky and AT is a bet on their intentions beating whatever brain worms seem to afflict companies after a while. It’s a race and the brain worms might win.
They acknowledge it and seem self-aware about the risks:
But that might not be enough.
Sad to see the Matrix team repeating the lie that Bluesky is decentralized. When you look at the distinction between the two, it’s clear as day that we either need to stop calling Bluesky decentralized, or choose a new word for things that actually promote a network without megainstances and centralization.
Running a single Synapse server is enough to chat with your friends, completely in isolation. Two groups running Synapse can talk to each other without any interference from a third party, and you can self-host sydent or ma1sd or what have you for the identity API, too. You store and transmit the data required for conversations you participate in.
Running a Bluesky PDS, on the other hand, gives you control over your own data, to an extent, but Bluesky-the-company, or some other large entity, must be involved in order for you to talk to anyone else, because running a relay is expensive and legally risky. While you can argue this is technically “decentralized”, it’s qualitatively different from the way that things like Matrix and ActivityPub work.
Twitter has a single center. ATProto is designed to facilitate a network with a few centers rather than one, and views megarelays like bluesky.network as a success; a relay that isn’t enormous is a failure. Matrix, ActivityPub, and so forth are designed for a network with thousands of small “centers”, none of which need a complete view of the network, and the community tends to view mega-instances like mastodon.social, matrix.org, etc. as failures of the system.
imo, there is a line that drawn between ideologically pure decentralisation and mass adoption, and bluesky falls right in the middle on this line.
Onboarding my friend on was a nightmare, explaining things like
to someone who just wants to “use something like twitter that is not twitter” is a fool’s errand.
Bluesky has managed to surpass this hurdle (you download the bluesky app and make an account)(same can also be said about threads.net btw) by centralising a lot of its infrastructure into a cohesive brand and therefore, it has done something that neither mastodon or matrix or pgp has been able to do – actually being used by people
This may be a fine argument for building centralized systems, but it’s not at all an argument for calling Bluesky “decentralized,” which is what the parent comment was arguing against.
oh yeah absolutely my bad, my comment was very non sequitur. i am sorry
Sure. But if it’s not actually decentralized, what’s the point? Just use a centralized service, which will have an even better user experience, such as not exposing private info like likes and blocks.
so that the people who actually do care about it, can benefit from it
I am not really sure what you’re saying here. If people care about the benefits of decentralization, they need to use something actually decentralized; if people don’t care about the benefits of decentralization, they should use a centralized solution that doesn’t have the tradeoffs of something like Bluesky.
i guess i didnt word my comment properly, i am sorry.
what i meant to say is thay bluesky, with all of its flaws right now, is a pretty good middle ground between ideologically pure decentralisation and mass market appeal
No hard feelings - I just think we’re talking about slightly different things :)
That’s the point, making a product technical superior doesn’t guarantee success. Matrix developers frequently have to explain why joining a channel can be slow - even slower than the decades-old IRC network. However, they rarely acknowledge that this performance issue is one of several key barriers holding back wider adoption of Matrix.
we did a massive project to speed up room joins: https://element-hq.github.io/synapse/latest/development/synapse_architecture/faster_joins.html and https://github.com/matrix-org/matrix-spec-proposals/blob/rav/proposal/faster_joins/proposals/3902-faster-remote-joins.md etc. Ironically, we did the hard bit (refactored all of synapse to support non-atomic joins), but then ran out of $ before we could realise most of the advantages, and shifted gear to more fundamental things (ie slow sync). The OP explicitly cites faster room joins as something for the post-2.0 roadmap.
I’ll evaluate Matrix’s usability after version 2.0 is released - though I wouldn’t hold my breath for that. Perhaps Matrix should redesign their protocol specifications to require fewer $ to impl or operate while matching the performance of contemporary chat platforms. I am still on the side of thinking matrix as alpha-stage software in 2024.
From your link, I gather that running a relay the size of the largest relay costs somewhere less than $200/month. I agree that would be expensive if I were doing it for myself and my friends group, but it seems rather inexpensive at the scale they’re talking about. I haven’t looked into running one other than reading the post you linked; are you arguing that it’d be impossible (or not useful) to run a small one?
And can you elaborate on how it’s more legally risky than running a synapse server or a mastodon instance?
Sure - but $200/mo is both an order of magnitude more than it costs me to run four GoToSocial instances, and as the author says,
Not to put too fine a point on it, but, I trust my friends and the people we talk to not to post CSAM; I don’t have that trust relationship with everyone on the entire Bluesky network, which is an open-signup set.
I wasn’t disagreeing that it’s too expensive for a friends/family instance.
My question was really (because I don’t understand the setup well enough) whether it’s possible to run an instance 10% the size for 10% the cost. Do you know if small instances are possible given the protocol/federation arrangement?
Does a federated Mastodon instance carry that same risk? That’s the part I’m trying to get my head around… I had kind of understood this to be about the same lift as a Mastodon instance, in most ways. Now that I hear it’s not, I’m trying to get my head around where the differences lie.
I like your characterization that “the community tends to view mega-instances like mastodon.social, matrix.org, etc. as failures of the system” when it comes to the community differences. Now I’m just trying to update my mental model of legal/tech differences.
Ah yeah, this is exactly the difference I’m trying to get at. The Bluesky architecture is designed around what they call a “big world” concept; each relay is supposed to have a complete view of the whole network, including from accounts and instances you’re not following, have never seen, have never interacted with you, etc. That’s what makes the cost explode so much for a relay; there’s not really such a thing as a “friends and family” instance. They pay some lip service to the idea of this in the protocol documentation, but there’s essentially no actual support for it in practice.
On a fedi instance, you only store posts (and media) from people you follow, including things boosted by those people, and posts fetched as parts of threads and so forth, so your exposure - both in terms of storage/processing cost and in terms of liability - is dramatically lessened. On a Matrix server, it’s even more so; you store only messages in rooms one of your users is in.
To elaborate a bit, the bluesky protocol (as currently implemented) makes it impossible to do a lot of important things without a big world relay - for example there’s no protocol-level notification mechanism for likes/replies/follows/etc, users are just expected to have a relay crawling the entire network for actions which concern them.
(That being said it’s just about possible to build a bare-minimum small-world “see what my friends are posting” thing, and I intend to do this at some point.)
Does Bluesky offer RSS feeds? What advantages would this bare-minimum small-world approach offer over RSS?
This thread by one of the protocols developers explains a little bit. The TL;DR is signed posts and account migration.
https://bsky.app/profile/pfrazee.com/post/3l6xwi52zti2y
It would appear that it is possible to redirect an RSS feed to a new location: https://cyber.harvard.edu/rss/rssRedirect.html
For people only subscribed through RSS, I don’t see that anything more than a redirect is necessary for account migration.
As for signed posts… can’t we simply rely on HTTPS to your own domain to prevent man-in-the-middle modification of posts? If Bluesky requires you to have your own domain anyway…
Running a relay that subscribes to the entire global network is relatively expensive to run, but there’s no reason you couldn’t subscribe to and relay a smaller sub-graph of the network featuring only your friends.
This seems entirely tangential to the release of Matrix 2.0, but it’s perpeptuating a big misconception about how AT Proto works
I subscribe to the megarelay and it’s about 12 megabits per second at peak times. The burden for running a megarelay is relaying to all subscribers (which is NOT all PDSes – just appviews, feeds, and labelers) and storing recently broadcasted // all ever broadcasted posts. The relay is not integral to the network (PDSes could & can just subscribe to each other), it’s a bolt-on for performance
Plus there’s no reason you couldn’t be connected to a smaller relay that forwards your stuff upstream to the large firehose (so that bluesky AppView can see it) or not at all (so only subscribers to your alt relay can see it) – Much differently to ActivityPub, the auth is at the data layer and not the request layer, so relays can feed into each other and rebroadcast without betraying message integrity
Well, in my experience direct IPFS access is not much faster. I tried multiple times over the years and every time it takes forever to access anything on IPFS. The demon sits ih the background, chewing CPU and juggling bytes on the network and I still can’t get anything to load. For all I know it might as well be interplanetary for real and trying to fetch something from the moons of Jupiter.
Domains are useful. They make things look at least somewhat human-oriented. I can read a domain name out loud and I don’t sound like I’m having a stroke. Apart from malicious typosquatting and such most domains are recognisable, I can tell them apart and I can find them in my browser history if I need to. Hashes on IPFS make it absolutely unusable. There’s no hope telling one apart from another. I just can not use IPFS unless I have a link. I don’t think there’s any hope for IPFS unless somene comes up with IPNS.
(There is an IPNS - but the names are still opaque strings, presumably public keys of some sort, you just gain the ability to change what content they refer to.)
Since everyone is talking about torrents in this thread, I’ll also add that BitTorrent v2 added a feature like this, but I’m not sure how widely supported it is yet.
NAT hole punching has improved significantly in recent years and has become much more reliable.
In most cases, the slowness that people experience is either related to:
Indeed hashes are not human friendly. DNSLink solves this problem and is implemented in most IPFS implementations. Basically allows mapping from DNS -> CID.
Disclosure: I am an IPFS maintainer
er…. well I agree with the observations, but the conclusion does not follow and is dangerously wrong
do not use the Microsoft or Apple ecosystems for passkeys. they will get you in serious trouble if you ever find yourself at odds with the company, or simply want to leave. use a physical hardware token, and if that’s financially prohibitive for you or otherwise impossible, stick with older methods of authentication. do not tie your entire life to a single megacorp.
A YubiKey can only hold 25 resident keys. They are also clunky and annoying.
There’s a real risk Apple might someday ban my account without recourse. But hardware tokens are too annoying to consider using them in any serious capacity.
I have a YubiKey backup that I could bootstrap from, if needed, but in the meantime I’m going to take the convenience of Apple iCloud.
I think it’s quite annoying that the industry has decided to use resident keys for everything.
use the hardware token to open a keepassxc vault, that can contain more
This is the move, or something like it. I lock down a Vaultwarden instance using Yubikeys and TOTP keys and etc. on top of a secure passphrase, and then that Vaultwarden instance and the Bitwarden Firefox extension + mobile app get me into most other things. This was a change I made in 2024 and I truly don’t know how I ever lived without it.
Vault/Bitwarden support passkeys too, so you get one-ish click logins to anything that supports them (GitHub, whatever), protected by a physical hardware key a layer above. Best of both worlds, and works around stupid sites doing stupid things like limiting you to one Yubikey per account, a horrible practice that should have been forbidden in the spec somehow.
Vaultwarden is amazing, I use it with Tailscale to host my passwords while keeping my passwords accessible when I’m not on my home network.
Fortunately the number of web services I use that support passkeys is less than 25, and I also have 3 yubikeys ^^;
What about the Yubikey Nano? You just pop it in your USB port and you won’t even notice it’s there.
I don’t get that argument, I have nothing but good things to say about hardware tokens, and I use them for everything. I guess that’s all down to personal preferences in the end.
The UX of YubiKey compared to Apple iCloud is prehistoric.
With Apple iCloud all I have to do is present my face or my fingerprint. Additionally I only have to do this once when I make a new account.
With YubiKeys I have to:
Additionally when enrolling a key I have to do the same thing, but thrice, and I have to find out how to enroll multiple keys (every service does this differently). I also have to hope the service allows me to label my keys, many which don’t. I don’t have to deal with any of this when using Apple iCloud.
But it gets even worse, I now have to deal with resident vs. non-resident keys, know which is which, and deal with cryptic errors while inevitably I run out of resident key slots.
Also, when I am traveling I only have two out of my three keys with me, so when I come back home I need to remember to enroll the third key, and I need to remember for which new services I have to do this.
To add insult to injury, the NFC function only works on my iPhone after I plug it in!!!
Also my YubiKeys don’t work with government websites because they are not FIPS complaint. But the app they provide supports passwords (stored in iCloud) and Face/Touch ID, so there you go.
This is a kafkaesque nightmare. If you think this is good you are a masochist. With Apple iCloud I literally don’t have to do any of this. It just works!
I use YubiKeys but only for e-mail and Apple iCloud recovery. I can bootstrap every other service from that. It would be insane to have to use YubiKeys everyday.
Not to say that your experience is invalid or anything, but somehow none of these ever become a problem for me.
For me, my token is always plugged in when I am in my house. When I leave I take them with me, when I return I plug them back in, this never felt inconvenient to me. My yubikeys are with my keys too, by doing so I always know where my keys are, which is a big plus since I am very forgetful. If you dislike needing a PIN, get the Yubikey Bio and you can use your fingerprint for verification.
I need to press my Yubikey many, many times a day. I use it for logins for start, besides that I also use it to unlock my encrypted disk, sign my git commits, etc. And I rarely have trouble hitting the button. Maybe I just have smaller fingers or something?
I also never had to worry about resident key vs non-resident. I am kind of curious, maybe I should worry? In what cases would this matter?
I think the argument they’re making is that, worst case, you can just go through the “reset password” flow, so it’s not critical to never lose your passkeys? Of course this assumes that the password reset flow exists (and it’s not like, eg, Discord’s 2FA where losing your secrets locks you out hard), and that you don’t need a passkey to get into your email itself.
yeah, that sounds like it could be where they’re coming from. it’s at least a coherent position, which I wish were better elaborated.
I don’t personally even want a megacorp to be able to observe what I log into or when, I think the risks of that kind of surveillance being normalized are extraordinary. this is also my complaint about the long-standing practice of relying on megacorps as identity providers with OAUTH.
ah well.
I’m not sure why you seem to think passkeys/WebAuthn are in any way comparable to OAuth. In passkeys/WebAuthn there is no equivalent of the remote “identity provider” in OAuth “sign in” flows – passkeys/WebAuthn is literally just public-key cryptography where you prove identity by proving you’re in possession of the private key. Note I do say you, not “your identity provider”, because passkeys are local credentials. Apple’s gone to some lengths to provide the ability to share a set of passkeys among all devices signed in to a single Apple ID without also giving themselves all your private keys, but I’m not aware of anything which would remotely notify Apple of which sites you’re authenticating to with passkeys.
Also, there’s nothing about passkeys which inherently makes them non-portable or prevents them being backed up. Multiple implementations already have the ability to back up and export (I believe Apple’s even has the ability to do trusted sharing of a passkey to another person in order to enable something like “password sharing” in more traditional auth flows).
So I think anyone who wants to claim passkeys involve the same level of observability as third-party IdP systems like OAuth needs to provide evidence to back up that claim.
The OP explicitly claims that passkeys are non-portable and cannot be backed up, by design. This is the central claim of the post. It’s what the title “Passkeys are not passwords” refers to. But apparently this is possible if you have an Apple ID and trust Apple and its cloud.
The person you are replying to stated:
So advising them to get an Apple ID isn’t helpful to them. Or to me, because I don’t have an Apple ID, Google ID or Microsoft ID, and have no plans to get one. I’m only interested in security solutions that are open source and local first, where I own the hardware where the passwords or security keys or credentials are stored, where I can back up critical information and transfer it to another device. The OP says that the design of passkeys makes what I want impossible, and you say trusting Apple and the iCloud is how I get these features. You also mention “other implementations”, but what about implementations that aren’t Google or Microsoft cloud based, and which are both local and secure?
The design of passkeys does not make it impossible. The claim that it’s impossible to back up or export passkeys “by design” is verifiably factually false. “Passkeys” is literally just a new brand name for WebAuthn, and WebAuthn is, as I’ve pointed out, literally just public-key cryptography. Signing up for a site with “passkeys” just involves the site associating the public key with your account, and when you authenticate there in the future it just checks that you are able to sign things with the corresponding private key.
Nothing about passkeys requires that the private key be somehow un-back-up-able or un-export-able. There are implementations that you can download and use, right now, today, that can export to plain-text formats. To the extent that some implementations don’t have those features right now, it is a “haven’t prioritized/got round to it”, not a “that is impossible by design of passkeys”.
And I never said you have to “trust Apple and the iCloud” to get these features. There was an assertion up-thread that Apple was somehow secretly surveilling passkey usage and would know every time you use one and where you used it. I pointed out there’s no evidence for this whatsoever, and that Apple’s implementation in fact seems to have been quite thoughtful about privacy-preserving ways of doing difficult things – like how to let a user share key material among multiple devices, or to a trusted third party for credential sharing, without exposing that key material to the full view of Apple itself or of untrusted third parties.
You could, if you wanted to, go out today and obtain a copy of Bitwarden and run it on whatever device(s) you choose and use it to generate and manage passkeys. You can even export them out of Bitwarden as plain JSON, right now, today, and they say they’re working on full import/export transferability to and from other passkey implementations for future releases.
The mere existence of Bitwarden, as Free Software with that feature set, overturns most of the negative claims being made about passkeys. Will it matter or change anyone’s mind? Who knows.
As I understand it, there is a lot more to passkey authentication than “it just checks that you are able to sign things with the corresponding private key”. There’s also an attestation system so that the server can identify the software running on the client. This is intended to allow servers to ensure that private keys are resident in an HSM or device secure enclave, or that software clients obey certain rules such as never exporting private keys.
https://github.com/keepassxreboot/keepassxc/issues/10407
None of what you’re saying is really a counterargument, though, as far as I can tell. Yes, there’s lots of extra stuff available around the core public-key cryptography stuff, because there’s a desire on the part of giant companies to make passkeys or something like it part of their employee auth setup, and probably on the part of government agencies and other such entities.
But those things are not going to apply to every site and every user and every implementation. Claiming that those sorts of restrictions are going to apply to 100% of users as an “inherent” part of passkeys is just nonsense. A good analogy is MDM: you can do lots of restrictive things to a device with MDM, but that doesn’t mean that any device which is capable of being enrolled in MDM is always operating under the most restrictive possible things MDM can do. Most devices aren’t enrolled at all!
Every authn/authz protocol eventually grows all those bells and whistles to satisfy huge entities whose audit checkboxes require them. That does not mean that all those bells and whistles are force-enabled for everyone everywhere all the time, and we need to stop acting as if they are.
I clicked on @fanf’s link and read the posts by Tim Cappalli. It seems the current looseness is a temporary situation, and the FIDO Alliance is working to close these loopholes. Once Passkey Provider Certification is fully deployed, it seems likely that any site that forces you to use a passkey rather than a password will be implementing the updated standard. I run GrapheneOS on my phone, and it’s already the case that some banking apps won’t run because Graphene, as a non-commercial open source project, can’t get certification from Google as a trusted operating system so that it will pass SafetyNet attestation checks. The same fate may await pure, non-commercial open source projects like VaultWarden. The main part of the internet is evolving into a proprietary-only walled garden, and people who want to use open source everything are increasingly confined to their own hobbyist ghetto. If you look at the FIDO Alliance membership list, it’s controlled by a bunch of propriety walled garden internet companies, like Google, and it won’t be surprising if those guys don’t see any business value in supporting non-commercial open source projects. I do see that Bitwarden is a second tier sponsor-level member of FIDO, but I don’t know if Bitwarden’s support for hosting your own server from open source that you compiled yourself will survive into the attestation era, and I’d rather run Vaultwarden.
The way I read that thread is that while the tone is unfortunate, they’re working on standardizing how import/export/etc. should work in a way that actually specifies how to safely handle private-key material. Which is a fine thing to standardize.
And I stand by what I said in my comment above, that a lot of this is people looking at a spec that’s growing all the “enterprise auth” bells and whistles and assuming that 100% of those features will be on 100% of the time for 100% of users, when the reality is it’s going to be more like “when you work for FooCorp, you will be required as a company policy to use this specific passkey implementation on a device specifically MDM’d by FooCorp and you will not be allowed to export out the private keys of your FooCorp passkeys, and there are specs to allow enforcement of that”. None of that affects what someone can do with a device they actually own – I have two laptops from the same manufacturer, running the same OS, but one is my personal device and the other is owned by my employer and MDM’d by them. The fact that MDM exists does not cause my personal laptop to be restricted in what it can do; it only affects the company laptop that’s actually enrolled in their MDM.
How do I guarantee that my bank will not be able to turn it on when I use an alternative OS, or a custom build of a mainstream OS or browser? For example, a Chrome patched to extend ad-blocking or debugging capabilities.
I don’t have the knowledge to answer your question, but I wonder why this specific guarantee would matter. An authentication technology can’t guarantee that you’ll always be able to sign in with it from any platform, because it can’t guarantee that your bank won’t switch to a different authentication technology.
I agree, it’s going to be a constant fight to keep the harmful capabilities out of popular authentication technology, and to keep authentication technology that includes it from becoming popular.
The only way you “guarantee” your bank won’t do something you dislike is by not having a bank at all.
Your bank could already, today, right now, suddenly decide to only allow you to sign in using some form of OAuth/OIDC/whatever from a single identity provider with a bunch of restrictions on acceptable browsers/operating systems. That is something that is already 100% within their legal and technical power to do. I doubt they are just waiting for another auth system to come along with the same capabilities before finally twirling their mustaches and cackling “ha-ha, at last we can implement our plan to destroy privacy and software freedom forever”, so WebAuthn gaining extensions to let corporate use cases do MDM-y things is likely to be no net change on that front.
As far as I know, OIDC doesn’t currently drag in the attestation garbage.
People always complain in these threads that their banks already do stuff like don’t allow their app to run on a rooted Android device or whatever. Regardless of whether it’s part of the specific auth protocol or done another way, the simple fact is they already have the capability and do not need to wait for someone to develop it for them. So once again: none of these MDM-y extensions being developed for passkeys represent a net change in your bank’s capabilities to restrict how and from what devices you log in.
Currently, that capability is restricted to mobile platforms. It would be very good to make it harder to expand those capabilities to the desktop or other platforms.
The only acceptable attestation is having every install generate a new self-signed attestation key that I can register with my account.
I still don’t see a meaningful change to the status quo here.
Also, attestation in general has user-empowering use cases – a remote machine being able to cryptographically prove that it’s running what you installed on it, for example, rather than secretly running something someone else installed without your knowledge – and I’m kinda tired of the knee-jerk posts portraying it as inherently evil.
Anyway, passkeys are not a secret plot to destroy your freedom forever. Nor were the last fifty things people insisted were secret plots to destroy your freedom forever. The people who you think are out to destroy your freedom generally are not.
Yes. And when I can prove to providers that I am running the software I intended to install, rather than proving that I gave Microsoft or Apple money, you might be able to convince me that this is a benefit.
I would love to be able to prove to providers that I am in full control of my machine, and that all the patches to the OS were intentionally installed by me. I can’t do that. The tools are broken.
And none of the providers reciprocate: They know how restrictive this ks. There’s a reason I can’t get attestation that the hosts running my GitHub account are running a known software stack.
And yet, it gets harder and harder for alternative implementations.
So, no. This is fucking me over, even if it’s simply through apathy. Stop trying to fuck me over.
Not transferable between distinct passkey managers, in practice and by convention, is what OP said.
If you’re the ultra paranoid type, you can use KeePassX, or Bitwarden with self-hosted sync.
This is not something that passkeys enable. A passkey is just a marketing name for a private key that is stored in some hardware root of trust (or a fake one in some cases). There is no communication with Apple when you use an Apple device to log in with a passkey, the server sends you a nonce, you encrypt it (and some other stuff) with your private key and send it back, they decrypt it with the public key they have on file and now they have a proof that you are the person who gave them the public key. Each key pair is specific to a site. Some devices do this by having a single secret and using a KDF to derive per-site keys, others do random keys per site.
The thing that Apple adds on top is the really hard bit: allowing keys to be moved from one secure device to another. I’d love to see a vendor neutral way of doing this but it’s a complex problem. Your root of trust needs to do some kind of key exchange with the target, validate that there isn’t a MITM attack going on, then encrypt the keys and transfer them. It needs to have some confidence that you are really the person authorising this (and not, say, someone who borrowed your YubiKey when you went to the bathroom) and that the target device is secure (and not something that will just leak all of your keys). Oh, and you need to make sure that it’s hard for someone to threaten you and steal all of your keys.
If you have a proposal for how to make that work, I’d love to hear it.
So far, the vendor neutral solution is just “HSMs are overkill paranoia for this (and restoring from 0 active devices is actually not to be dismissed), the same level of security that worked for password managers is sufficient, so they just become passkey managers as well” :)
iCloud Keychain at least purports to end-to-end encrypt its data (with escrow unless you turn on the full blown advanced protection), which would prevent them from gathering data about your login habits. There’s still the lock-in issue, but I don’t see the privacy aspect unless I’m missing something…
Does that apply to any logs that they keep on the authentication attempts? No info on that (and for some folks trying to pry, that’d be enough info to continue the “old school” route
What logs? How do you think they’re generated and sent to Apple? Do you have proof from, e.g., packet sniffing that Apple devices are notifying Apple whenever you use a passkey? What led you to believe this was a thing that might be happening?
Passkeys, as far as I know, are literally just public-key cryptography where a keypair is generated for each site you want to authenticate to, and the site stores the public key and you prove your identity by having and using the private key. The implementation is literally not much more than fancy UI around a keyring, something that’s been around for ages at this point.
This was a purely speculative comment (since most professional environments keep logs on activity to prevent fraud; unless Apple’s privately figured out how to do so), to answer those questions in one go.
I’m familiar with the infrastructure around Passkeys, still am in the FIDO WG though I don’t contribute much. What I’m saying is that there’s probably (because we will never know unless someone decompiles Apple’s stuff) some marker to note how they authenticated. There’s also a chance that they don’t mark that, but you can see what devices have been signed in on most Apple devices (like on one’s laptop or desktop via that iCloud panel) as well as log-in location.
The operative word in my comment was any so it could have been ephemeral ones like in that dashboard or ones kept in their secure systems.
The original context of this thread was someone (not you) asserting as a legitimate concern that Apple is going to “observe” what they log into and when, comparing it to OAuth.
Which I interpret as a claim that if, say, they authenticate to
example.comon an Apple device and using Apple’s implementation of passkeys, they believe Apple would be aware that they have just authenticated toexample.com.While it’s true that with OAuth (which really is about authorization where passkeys/WebAuthn are authentication) the resource server (i.e., Google, Facebook, Microsoft, etc. in OAuth-based “sign in with” flows) has information about each client requesting authorization, and thus knows every client application a given resource owner (user) is authorizing, I’m unaware of any equivalent ability, or even anything close to equivalent, in passkeys/WebAuthn.
So I think the claim that passkeys somehow enable the same level of observability as OAuth, or that Apple has somehow built a similar level of observability into its passkeys implementation, is an extraordinary one and requires extraordinary evidence, and probably should not be speculated on without at least some actual evidence that it’s there.
Another thing to consider is the flipside situation, it is physically possible for yubikeys to die. I had this happen to me recently with my 5C nano. Suddenly decided to brick itself, won’t even power on or be detected anymore.
I prefer to put my passkeys in 1password, though I won’t defend them per say, it just works best for me in my present situation
My only concern with 1Password is that I don’t think you can export or move the keys. Hell, you can’t even fix up entries where the passkey has gone to one entry and the password is on another.
I read it as “here’s a thing you might not have understood about passkeys”, which indeed, I did not. I certainly don’t see a conclusion anywhere near as forceful as what you might have. I read the final paragraph as “if you’re going to use passkeys, this is the best way to use them”, without speaking to whether or not passkeys are an objectively good or bad idea.
(I mean, the author is clearly invested in the idea to some degree, so the existence of the post at all suggests some enthusiasm, but it hardly seems like a full-throated endorsement).
On macOS, at least the last time I tried, the browsers don’t let you make that choice. Safari doesn’t let you save a passkey without iCloud Keychain turned on. Chrome doesn’t let you do it without using Chrome Password Manager. Not sure about Firefox.
With the Safari Bitwarden extension I can store passkeys in there (and then secure Bitwarden with hardware keys). But the UI is clunky and still doesn’t work on phones yet.
Yes, I think Irene were suggesting not to use passkeys at all in such a case (since then a lost device means an inaccessible account).
It.. does, of course?
On desktop currently, 3rd party passkey managers provide extensions that override the built-in passkey handling right inside of the web pages. On mobile (iOS >= 17, Android >= 14) they hook into the system API for passkey providers.
Ah, it was a while ago that I tried it. I was also on an older iPhone that could only go up to iOS 15, so maybe that was why. I have a newer iPhone now and I just tried, and it indeed does seem to support it. But when I tried logging into GitHub with Bitwarden’s passkey, it said: “Error reading passkey. There was a problem reading your passkey for github.com. Try again later.” I guess I won’t be going passkey-only anytime soon.
I strongly agree.
Not super related, but I wish using physical hardware tokens were as easy as that. I don’t use any passkeys; I have a couple of Yubikeys for FIDO (…? FIDO2? U2F? I don’t even know and this is half the problem)-based flows, TOTP where I can’t, SMS where even those aren’t an option.
But the Yubikeys work on maybe 65% of websites. Some combination of OS/browser/? means that some sites prompt correctly for them, but then just give some inexplicable error on touching the capacitive button. This is unfortunate because it means e.g. I can log in fine with my keys on Firefox on a Macbook, but the same keys on Firefox on Linux don’t achieve the same result.
Some you have to dance around with various settings, and some only work if you have a PIN set. I think this is related to the FIDO(2)/U2F confusion — I’ve spent a while trying different combinations of which are enabled on my keys and the results in varying websites are all completely different, presumably depending on the APIs they use. A thankfully very small proportion only let you add one hardware key, which is terrible.
I still go through the effort of attempting everywhere I can, but I can see why people would take up passkeys instead of it. (It doesn’t help that all the relevant ecosystems are pushing them in a way that makes using a hardware key instead several extra clicks than they used to be; 1Password keeps wanting to save a passkey when I want to use my already-plugged-in-key instead, Windows doesn’t let you disable this thing, macOS wants to get in the way too (which combines with 1Password’s for extra clicks), etc. etc. etc.)
very belatedly, in case it’s still useful to you: yes, requiring a PIN is a specific thing that site owners can turn on starting in FIDO2. I had to dig into this recently so I happen to know…
Very interesting!
However I don’t understand the reaction to the vendor response:
How can the initially generated API tokens still work? If the private key is known, there is no way to differentiate a “legitimate” token, from a “forged” one.
It can if their system has a record of all tokens it legitimately issued. Given the short lifetime, the risk that someone manages to recreate the attack in the remaining time and manages to brute force an already existing valid token is probably not that high (and something they can monitor for). My guess would be that if they broke all existing tokens devices would need to be logged in again etc, so this way they can let them naturally refresh to the new secure tokens.
The strange bit, of course, is that if they have a record of every token, then they could’ve avoided JWT in the first place, just used random tokens, and eliminated this whole class of bug!
Yeah, it is entirely a guess, but given the description in the Ars article of this being an early decision made by relatively junior people, it sounds possible. JWT gets (IMHO) recommended way to much as the obvious approach, so it’s not unlikely to be picked, and accidentally or intentionally logging enough that they can get a list of tokens now and enforce them centrally also seems possible (and if they have some central API gateway etc its easier to do that for now vs rebuilding all the backend things to not use JWTs)
The token given in the beginning is valid 7 days, so it makes sense.
(if they record all emitted tokens, it feels like another security hazard: having read access to this table would be give an attacker quite a lot of power…)
It would negate one of the benefits of JWTs too - stateless verification. The downside is of course that you can’t really revoke them. 7 days feels like a long expiry, but obv I’m not privy to their threat model
Their tokens don’t expire by default.
oh, I missed the bit that said that it gave you the option to configure that!
The thing is they do allow the tokens to be revoked also?
The design seems mostly like a database with extra steps…
If they have a record of token IDs they could look up the info of the owner and “regenerate” the info that would have been signed in the token from the DB.
I think that’s what they did.
This blog post offers a better introduction, I think.
Very technical post and good thinking, I like it. I believe that the post would benefit from a gentler introduction for people who aren’t well-versed in functional programming and type theory. Even though I think about this stuff a lot, it took me a minute to orient myself and figure out what we are talking about because the reader is instantly thrown into cold water.
Yeah, I have literally no idea what this post is trying to say after reading it through twice (I didn’t go to university, but am gainfully employed).
I think the idea is:
There’s a common pattern in UIs where you ask the user a question, then depending on the answer to that question, reveal two different sets of fields - he uses the example of setting up a project in an IDE, where you can choose to point it at an existing directory (specifying the path) or tell it to clone a repo (specifying a git repo, access token, and the path you want to clone it to). Logically, you would represent the user’s input from the form using something like this Rust enum:
But from a UI perspective, it’s really annoying if you start to enter the information for a clone, click the “local” radio button for a moment, change your mind and switch back to “clone”, and you lose everything you’ve already typed into the form. So the underlying data structure - at least while the user is filling in the form - actually needs to look like this:
The insight is that even though logically you’re producing something represented by a sum type (type theory for what Rust calls an enum), for good UI, the form internally needs to use a product type (type theory for what Rust calls a struct) containing all the options from the sum type.
This is actually very relevant and one of the most common mistakes I see devs making. They avoid to create types that describe exactly that. Instead they try to directly transform some raw input (e.g. html state) into the final sumtype.
For the first 2/3 I thought it was about summing numbers. Then I had to go back and reread it once I had realized that it was talking about sum types.
I thought that (and it made no sense) until I read the replies here. I absolutely hate the naming conventions, they’re confusing and even knowing about them I have to keep looking up whether product means “struct” or “union”.
The notation where the OP uses
2*A*Bdidn’t help either. 2 isn’t a type…2 is short for 2 possible values.
Korrekt. It should either be
2*|A|*|B|orbool*A*B2can stand in for any two-valued type because they’re all isomorphic. It could bedata RB = Red | Blackordata Bool = True | False, or any number of other names.Is this common syntax when describing cardinalities of types? It makes sense but doesn’t seem very intuitive to me.
About the only time I’ve seen discussions of cardinalities of types is in the context of this semiring of types, where it’s simultaneously helpful (because it’s capturing the essential feature of all n-valued types) and obscuring (because |n| = n for any n ∈ ℕ). My set theory classes are a distant memory, but I think we built numbers out of sets such that x ∈ y iff x < y.
I always give the opposite feedback. At some point, you have to decide who your target audience is. Posts lose clarity when they have to define every single concept down to first principles.
A happy medium is to link to other posts that describe something. But, at the same time, it’s also pretty low effort to do some googling about algebraic data types.
Yeah… Honestly if you strip away the functional programming lingo this is a pretty trivial observation.
I re-submitted https://codewords.recurse.com/issues/three/algebra-and-calculus-of-algebraic-data-types, which help people who aren’t used to thinking this way.
The screenshot of the rotating ticket also includes an “Add to Apple Wallet” button; given you can’t easily implement this kind of rotating code with Apple Wallet, I wonder whether the resulting wallet pass just has a static code instead (bypassing the need to reverse the ticket)?
Apparently the rotating code is in fact implemented by Apple and Google’s wallets.
Do you have a source? The developer docs don’t mention this functionality, but I wouldn’t be surprised if that was intentional obfuscation…
edit: it appears Google have a rotating barcode thing; Apple’s support pages on the other hand seem to be filled with people complaining about rotating barcodes not working with Apple Wallet, so perhaps they indeed just don’t!
I just heard this second hand from other discussion: https://news.ycombinator.com/item?id=40906767
There is one user claiming that it works on Google Wallet with what sounds like a first-hand description and one user stating that it also rotates in Apple’s wallet.
Wallet passes have HTTP endpoints to do stuff like update the pass. That’s how your boarding passes for flights can be updated if the terminal changes.
Yeah, but if you do that every 15 seconds the phone will ratelimit you :p
maybe on Apple it just rotates every 20 hours?
Seems like that defeats the point, 20 hours is plenty of time to send screenshots of a ticket the day before.
People are already reselling the TOTP versions apparently. So it’s not like it’s really all that much worse ;)
I had heard about the famous bitkeeper kerfuffle of course, but I always assumed bitkeeper was written primarily for corporate users; I had no idea McVoy was so hilariously out of touch with the free software world that he could ever actually think this.
BitHub???
Apparently they moved it to the Apache Public License in 2016.
Of course, there’s the further irony that git did go on to achieve this level of domination!
And BitKeeper even has an official Git repository: https://www.bitkeeper.org/download.html
Yes, but even with Linus’s star power I’d say it still took more than just a few years to do it.
For anyone who isn’t familiar: in Turkish, ı and i are distinct letters, with corresponding capital variants I and İ; this causes all sorts of fun localization problems, as “i”.toUpperCase() is “I” in english but “İ” in Turkish.
why not change the shortcut it in the editor instead?
iirc, this is what people who use non-latin languages in such editors do, for example, change the shortcuts ctrl+x to ctrl+ч, ctrl+z to ctrl+я, and so on
Presumably for the other use case they mention, typing mostly in English but occasionally in Turkish.
As Gaelan said, yeah, I type primarily in English so changing the keymaps was worth it
I’ve had some similar issues - not specifically with i, but with the placement of characters like [,], | and the like. I’ve ended up switching to using a US-ANSI keyboard layout, with a compose key for using the non-English characters in my native language.
The reason for this is that pretty much every piece of software I use assumes a US-ANSI layout, and remapping all of them is a giant hassle. (and also, I’ve found I like the ANSI shape for Enter and left-shift better). Also, like OP, I type in English more than in Danish.