Good that people are finding and fixing these, but basically allowing any untrusted client to talk to your X server is asking for trouble just by design. (Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.)

There are plenty of setups where the X server runs at higher privileges/on a different host than the (partially trusted) application that might exploit the X server. This is a classic elevation of privileges vulnerability in those setups.

X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program anyway, as there is no prevention of keystroke injection or screen recording, but that's a design flaw that will never be solved. That doesn't mean that EoP style attacks like these should be ignored or underestimated, though.

Digging deeper there are mechanisms for long time on internal X side (see https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv... ) - granted never seen it practically implemented.

And going to rabbit hole there are even proof of concept security implementation named Xnamespace for Xorg fork (needs polishing and much more patches but looks doable. see wip documentation: https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6... )

The way X11 developers ended up fixing this is by creating Wayland. This way privileged operations (like keylogging, screen capture, etc) require the cooperation and authentication through the display server.

That way you also prevent things possible in X11 to be impossible in Wayland, like a window setting it's own position, if you were to want that.

Fixing X11's security would of broken window positioning as well. Since that is a security issue.

The deal here is that the only way to fix X11's security issues is by breaking all those types of workflows and forcing application rewrites to implement them in authenticated ways.

So if you are going have to go and break all that stuff, why not fix a crapload of other problems while you are at it?

Calling Wayland "X13" may have avoided a lot of misunderstandings, but it probably would of caused others.

Good. Disallowing software to position its own windows has been a major usability improvement over the X11 days of software making stupid positioning decisions and having to patch it out everywhere...

That sort of solution is cancer if you want to do anything the display server authors didn't think of. I've got a script that I invoke with a global hotkey that determines the window title of the currently focused window and fuzzy matches it against pipewire audio stream names so I can mute the focused window with a single keypress. If I want that to work in Wayland I'm pretty much up shit creek because somebody with their head in the clouds thinks that my needs are super dangerous or something.

That sort of solution is cancer if you want to do anything the display server authors didn't think of.

Hey come on man, a locking screen saver is a totally niche application. No demand for that.

xscreensaver works just fine. It only needs to keep nosy roommates out, not the NSA. Not that Wayland would stop spooks anyway.

It doesn’t lock the screen properly under Wayland. There’s an abyss of complaining about Wayland on jwz’s blog.

https://www.jwz.org/blog/2025/07/xscreensaver-wayland-and-lo...

Wayland doesn't say "this is impossible", it says "this is out of scope of the core display protocol, implement this somewhere else".

Which, well, we do. Practically all the X usecases are covered on Wayland systems now. Screen sharing, screen clipping, global hotkeys, file pickers, getting the window title like you said... I can do all of that on KDE, right now, under Wayland.

Can you do it in a way that isn't KDE specific, and will work if you change your DE one day on a whim?

If you change to another DE that has less capabilities than KDE, of course you can't do it. Emacs and LibreOffice Writer will have vastly different capabilities and people can choose what they want based on the capabilities they desire.

As I understand, blind people can't use wayland right now.

X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1. This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately).

¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.

something any good engineering manager should have stopped immediately

Who exactly should and can control the horde of OSS developers?

That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on.

The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.

LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).

I think you did not understand my point. X11 has several such mechanisms, yes, but it also has the concept of untrusted clients that disallow the use of these mechanisms and could be used to provide safety similar to Wayland. The point is that this mechanism of untrusted X clients was neglected and I gave an explanation way.

Yes and your response in the whole thread reading top to bottom was the first one that really taught an old dog a new trick. I've been using gnu on x11 since 1991, been annoyed by fellow student's audio streams on my work station back then, and I've never heard about trusted vs untrusted x11 apps.

I wonder how this debate was mainstream? did some gamers try to squeeze 3 extra percent by taking the protocol out of local stacks? there must have been better ways to do that, without throwing out all X11 benefits?

to this day I'm annoyed I can't have a decent window manager integration on gWSL because the compositor doesn't implement the full window manager protocol.

See the ssh manpage for an explanation of untrusted/trusted clients. This debate was mainstream. Basically, some people presumable paid to work on Linux graphics decided to implement something new instead of doing their job, and gave talks about why X is fundamentally broken. I believe the driving force might have been the hope to support Linux on mobile or embedded devices, and X seems just unnecessary (although I think network transparency would be super useful on mobile devices). Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland". Wayland developers certainly did not do anything to stop such misconceptions. Later there was disappointment because obviously it was not faster (the drawing model for modern clients is essentially the same), but other myth such as the "fundamental security issue" prevailed.

It's like if Wayland is not just a graphical system, but a full business plan.

Control upstream, then companies wanting solutions will go to you first. Because why go to someone else in the FOSS market, when there is no certainty the code or standard (extension, protocol, etc) will get accepted, forcing you to maintain a fork? With IBM-RH and Ubuntu doings eg., it's hard to say FOSS is immune to vendor lock-in.

Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland".

This is incorrect. Kristian Høgsberg has explicitly stated that a primary motivation for Wayland is the reduced need for a central X server, as many programs already bypass it.

As far as I can tell, enabling the trusted/untrusted security feature breaks a lot of basic features, including clipboards, XRandR, GPU acceleration, XKB keyboard layouts, and whatnot. It's theoretically available but practically useless.

Xnamespaces looks to be more promising, but as far as I can tell that's still a WIP with little documentation, and from the documentation I can find it looks like it still breaks things like clipboard functionality.

Well, the threat is shared access to resources like clipboards, so securing against this of course breaks the clipboard. Pick your poison.

Pick your poison.

Permission system? X11 with a permission system is the next logical step for Unix graphics. There is absolutely no need to break 40 years of graphic software, or throw away 40 years of accumulated features.

I don't think I've seen X configured to run as root in probably 15 years. If anybody still does anything like that, they're literally asking for it.

Hmm.. On my Debian ps axuw|grep Xorg says

    root       34595  2.7  0.4 26146280 532248 tty4  Sl+  Nov13 783:33 /usr/lib/xorg/Xorg vt4 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3

That looks like the display manager (i.e. login screen) running on vt4, which is probably not where you are logged in. Does it switch to another user when you log in?

Note you have multiple virtual consoles which can have independent X servers.

Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.

Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.

What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.

I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation.

Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus.

So simple and easy to iterate on that Wayland compositors are still not as full-featured as X11 desktop environments after more then a decade, and can't be due to protocols no one is able to agree to implement.

> Wayland compositors are still not as full-featured as X11 desktop environments

It depends what features you care about. X11 doesn't have tear-free video playback, HDR, or as good a security model as Wayland.

Using a compositor fixes screen tearing, no need to use Wayland for that.

X11 has options for tear free video playback; it's not in the base protocol, and not all drivers offer it, etc, but it's acheivable. Fundamentally, you need to send the next frame to the server and ask it to switch frames during vblank (+/- notification), on today's systems, this is more of a coordination problem than a technical one; there's plenty of video ram to go around to double/tripple buffer.

HDR would fit in the X11 model of many bit depths, however the specifics don't really; afaik, X11 has a maximum bitdepth of 32 for pixel values, which means either limiting to 2-bits of alpha channel or using palettes (I think I saw that indexed colors can be defined with 16-bits per channel). An extension might be possible (with everything that brings), but I think the ship has sailed.

I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag.

I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag.

That is so true, I wanted to have a typing sound from my pc everytime I typed on wayland and I looked at LITERALLY every single solution and none of them worked... simply because of the security model of wayland (so things like Mechvibes and alternatives don't work generally speaking)

On one hand, its a good thing to prevent things like password injection etc. but on the other, really?

I got frustrated and I created a lot of github issues on every such project if they said that they are working on wayland and I didn't care if it meant running it as sudo, I just asked them kindly if there was a way or not/ what's the issue here

There are still times where I get a lot of notifications simply because someone commented on those issues

So naturally a lot of people are/were frustrated about it. Not sure if its a good thing or not, but I 100% agree about this comment of yours

Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers, Please let me know if there are apps which do this though, I know about weston but I haven't found ways to work with it/make it work (maybe my skill issue)

Are there any solutions to these things though? Fundamentally that mechvibes things requires an app to view the key from every other application and make a sound, Nothing stops it from being a key-logger as well if it had that capability and Wayland was created with a better security model but as you say and I experienced, that security model comes up with its own compromises and I am not sure if that's a good thing or bad thing....

Wayland is the way to go. The same applies to Flatpak, Pipewire, systemD, etc. I'd say that this is obvious, and doesn't even need to be argued, to 99%+ of those who actually use the Linux desktop. The only opposition to this is a small group of decelerationists with a major, irrational aversion to change.

Having only two major options, X and Wayland, doesn't mean either one is correct. It is generally true that X needs to be replaced, but Wayland is not necessarily the replacement we need. It would be good to have more competition.

On a separate note, I think it's probably true that Wayland has significant drawbacks that preclude it from being an obvious replacement.

I see wayland as the pulseaudio of display.

Everybody is pushing it and trying to convince the people who have problems with it that it's completely fine and their problems aren't important (like blind people being completely unable to use the computer).

At some point the pipewire of display will come along and we'll all forget wayland was ever a proposed solution.

What's insane about all these discussions is that NOBODY IS HACKING X SERVERS

I knew someone who worked for a small loan type company. Passwords were stored in plain text, but even worse, the login form didn't actually check the password at all, it created valid sessions as long as you provided a valid user name.

When he informed his boss that was very bad, his boss simply said that nobody has abused it, and nobody would, don't waste time changing it.

The point, of course, is why would you wait until people are getting hacked to address a known vulnerability?

Sure, there are others, and they should be closed too, and they are when they are found. It makes no sense whatsoever to leave one open just because.

I don't dispute your anecdote but I think the point was: x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses. So the vulnerability surface just isn't large enough.

I have definitely seen "these things" happen.

Source?

No, I've seen them. Myself. I didn't get this from a source.

What did you see specifically? And on what OS?

All of NIXen.

~/.profile

~/.env

~/.xprofile

Exploiting TMPDIR, /tmp race conditions, ~/.mailcap and mutt (I used that to get access to 'premium' binaries under restricted accounts).

If you have Emacs you can do tons of stuff from a single account.

And so on.

is why would you wait until people are getting hacked to address a known vulnerability?

Do you have some other way of _reliably_ identifying vulnerabilities?

It makes no sense whatsoever to leave one open just because.

It makes sense to have security options. If I want to leave it fully unlocked, that's my business, and I possibly have good environmental reasons to do this.

What you should really care about are security _defaults_. And in X11's case I'm not aware of any distribution that ships the server with TCP connections to the sever enabled. You have to go well out of your way to even begin using this functionality.

Do you have some other way of _reliably_ identifying vulnerabilities?

This is irrelevant given that we are talking about known vulnerabilities.

No, you can't reliably find all the vulnerabilities by auditing the code.

Yes, if you audit the code and believe you have found a vulnerability, you fairly reliably are correct in your belief. And should probably take action even if you aren't.

I think the point being made isn't that X.org shouldn't fix their vulnerabilities. It's that there's always a huge amount of discussion about vulnerabilities and security models when one is found in the display server or the window manager when actual exploitation doesn't seem to be particularly high.

Many distros, if not most distros, disable port 6000+ listening for X.org by default. So, immediately, it's not a remote exploit. OK, so it's scope is already limited to local escalation attacks. Looking at the CVE, the only reason it's high is because (a) X.org is everywhere, (b) you don't need to interact with [another] user to exploit it, and (c) it's not particularly complex to exploit.

That is bad, but it's also behind most of the other security, rather than bypassing essentially all of it like Heartbleed or Shellshock.

So, either I have to have X forwarding turned back on, or have people with SSH access to a server that is also running X. Both of those seem like uncommon situations. You probably shouldn't be running X or permitting X to be started unless you need X forwarding, and X forwarding is a pretty odd requirement given modern application design being so web-browser-focused.

So it might be CVE High 7+ if you're on a system where it's possible to exploit it. But it feels like you shouldn't often be on a system configured in a way where it could be exploited in spite of the prevalence of X.

Essentially: This isn't a rehash of the libXfont problem.

But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This randomly-generated string is needed to authenticate and establish a connection to the X server. You can use the xauth command to manually configure it as needed.

It's the equivalent of HTTP Digest authentication, and nobody's demanding that we rewrite HTTP because Digest authentication. It's in plaintext, so you shouldn't use it; but if a hacker doesn't know the secret, they can't get in.

This is because Wayland wants to differentiate itself from X on security. Wayland has to show it's more secure than X - as part of that, Wayland has to show that X is insecure.

No, wayland already differentiates itsself from X11 because X is a tool for graphical network terminals and Wayland is a tool for single machine rendering.

X11 is a mountain of tech debt that almost nobody wants to maintain.

Wayland is what you get when you decide to start a space program because, let's be honest, the electrical gremlins in your 1983 Mercedes 560SL are beyond properly fixing, and the kids still need to get to school

Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.

Any program you incidentally run within a typical graphical user session will have access to the X socket and a cookie, they will be able to connect. And after they connect... They basically just can do anything they want with zero real restrictions, including most likely some fairly trivial paths to root escalation. Even if they're running inside of a sandbox or container, with only an X11 socket poking through.

This problem was realized a very long time ago with the security extension but most of it never really caught on.

Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.

If you believe this is true, then what exactly is the point of any security measure? Why bother using isolation and sandboxing, or passwords? Why does Windows bother patching flaws if they know there are certainly more of them and they will never fix them?

Do you by chance also smoke because you're going to die anyways?

What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.

Lol. That's primarily because the Linux desktop is utterly irrelevant, not because nobody would care to do it. Is it really surprising that attacks against desktop computers would focus almost entirely on the OS that has 90+% of the market share? We don't get free software OS desktop malware for the same reason we don't get free software OS software ports.

Watching and waiting with security was a totally acceptable position in the 90s, but we get the general gist these days. We need security-by-design.

On the server side of Linux where Linux is relevant, the situation is much more impressive; auditing using eBPF, sandboxing with gVisor, microVMs with Firecracker and cloud-hypervisor, isolation using namespaces and seccomp-bpf and more.

On the desktop side, people are still arguing over whether or not it's a problem that any X client can by default silently keylog the entire system trivially. Okay, but a lot of us actually see that as a problem, and we're not interested much in "hearing you out". Most of us recognize that the Wayland protocol has warts (and too many damn protocols), but X11 has many more warts. I didn't care what was the successor to X11 specifically, I just cared that we eventually made some progress. Most people have nothing to offer here and just suggest we should've stuck with X11. Okay dude, but nobody wants to. The X.org devs would like to move on. The desktop environments really would like to move on. There was basically one serious guy that actually wanted to work on improving X11 and he turned out to be kind of crazy and couldn't stop breaking shit anyways.

You could use a proxy server (regardless of the protocol), which might improve security (and other things) better than other methods do, I think.

There are problems with both X11 and Wayland, although I dislike some of the features of Wayland.

Yeah, with Qubes that's exactly what they do. I forget what the software is called, but they use an X11 proxy that tries to enforce policy.

That said though, that does require you to proactively run every X application with this sandboxing. For Qubes which forces everything into VMs this is doable, but for most other systems there isn't an obvious way to handle this sort of thing.

My only major complaint about Wayland that can't just be fixed relatively easily is Mutter refusing to support SSD. (Well, the actual technical problem could be fixed relatively easily, but the social one not so much.)

Firejail uses nested X11 servers like xeohyr or xrdp to restrict application access to the primary X11.

including most likely some fairly trivial paths to root escalation

Why would this be likely?

Of course X has authentication, but once you're in, you're in. There are no elevated windows, screen recording permissions, or any sort of keylogger prevention. That was normal a few decades ago, but the world has moved on since.

There's no real reason it can't do any of that, it just doesn't and there are no real plans to add these features.

I'm not convinced by the "if you run a program you should assume you've already been hit by a CIA 0day". Obviously nobody is dialing into your X11 server from the internet, but this is a relatively easy nobody:nobody -> root/wm-session/whatever elevation of privilege.

If malware is in your X server, doesn't that mean it's running under your user account? And if that's the case, then couldn't it just steal your data right off the filesystem without needing to get it from X?

The valuable data on your machine might not be something permanently stored in the filesystem, but ephemerally recorded in a process. Say, a memorized password.

Couldn't the malware still get it without having to deal with X? E.g., by attaching to your process as a debugger?

Try doing that on a regular Linux install, you might be surprised.

Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.

Back in 1996 the level of X integration in Tk was awesome; I had a shell tool that could make Netscape do stuff by firing MIT magic cookies at it.

In a contemporary setting, it's pretty horrifying.

Didn't Netscape use Motif?

Some oldschool legends are still fixing bugs in xorg.

Alan Coopersmith in particular. He even fixed a bug I reported. :)

(I forgot in which app it was but the bug report should be somewhere still; it is not old, perhaps 2 years ago or 3 years ago. The xorg app in question behaved oddly when doing "--version". I only noticed this because I wrote a ruby script that displays which version of programs are installed, and that one kept on making problems, whereas the others worked fine. After I reported it, Alan fixed this very quickly. I think it was some missing flag in the C program or something like that; right now I can not remember the name of the program ... my brain tries to say xrandr but I think it was not xrandr but a less frequently used program somewhere in the FTP listing ...)

Would Fil-C have prevented the first or third?

Wonder how these play out against the https://github.com/X11Libre/xserver base, would be interesting to hear from that end as to how these things are handled. My understanding is that they address any sec issues that arise on x.org but it would be fascinating if the issues are already mitigated since XLibre updated their xserver port with 1000s of issues that were never addressed on the x.org side of things.

That project is a pipe dream. They don't have what it takes to continue X11 alive once X.Org pulls the plug.

That's the fork where the primary cause was to be "anti-woke", right? Honestly it seemed like it was just because that one guy was a little unbalanced, and he happened to be channeling that energy into an X server fork.

no the primary cause was that the main xorg project wasn't accepting the devs patches any more.

... because this dev's patches broke master, multiple times.

I feel this is an important detail to keep in mind while choosing a fork.

which mattered because everyone pulls from master, because xorg stopped doing proper releases. it's certainly something to bear in mind if you intend to run xlibre though.

I don't think "everyone" pulls from master - "everyone" run the distributions, and they always pin to the specific git commits. Only people who run xorg master are the ones who want bleeding edge, and those would be using it no matter release or not.

And it's not like metux will suddenly become more careful just because he does not have to worry about other anymore. If anything, I expect there to be much faster changes and much more breaking things... Here is a great quote [0]

@metux that you've had to fix this bug twice (!1844 (merged), !1845 (merged)) shows a lack of attention and care. This was a known regression, with clear reproduction steps, and at first glance, it does not look like you tested your PR at all.

And that goes in general; I really haven't seen the level of care and attention I would expect to see in these patches; several of them had obvious buffer overflow issues that would have easily been caught if tested.

[0] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797#no...

And he blamed wokeness.

On the github, he points to this document:

https://github.com/X11Libre/xserver/blob/master/HISTORY.md

Doesn't mention "woke" but the style is reminiscent to me from grandiosity/paranoia issues

XLibre looks nice with lots of work happening in only 5mo.

The problem with XLibre is political, not technical. When they came out they made a big deal of being the anti-woke free-speech no-vaccine-mandate alternative to woke cancel-culture Xorg, which instantly ruined their reputation before it even began.

Coverity is pretty good about finding these kinds of bugs. Is there a reason why a project as significant as Xorg isn't taking advantage of their gratis access for that tool?

I think the short story is that the people who develop Wayland are the people who used to develop Xorg.

And they’d rather spend their energy on giving you a compelling reason to switch, rather than using it to add to the reasons for staying on a project they now consider obsolete.

You may disagree with their assessment, but you can’t blame them for how they decide to prioritize.

I think the short story is that the people who develop Wayland are the people who used to develop Xorg.

They certainly say that to people a lot. Oftentimes the person saying it is young enough that I wonder how much time they spent working on X.

The main pain in linux is graphics. It's a shame.

Our chief pain is graphics... graphics and audio... audio and graphics... our two pains are audio and graphics... and wifi hardware support... Our three pains are audio, graphics, and wifi hardware support, and an almost fanatical devotion to the command line.... Our four... no... Amongst our pains... are such elements as graphics, audio.... I'll come in again.

_Roughtly_ speaking, X11 is only there for old games and the steam client. It is even worse with the steam client since the main executable in still 32bits.

_Roughtly_ speaking

_Strictly_ speaking X11 is only there because, after all those years, Wayland still does not meet expectations.

How did Twitter get away with taking X.com?

If it was the other way around, would an open source or whatever project have been able to take Twitter.org?

It was from x.com in the late 90s, merged with PayPal, Elon took the domain with him.