So far as I can tell, each Android device, or Windows with Hello, can act as a passkey. Basically anything that is modern Windows or Mac So you can both use your phones. When you try to log in with a passkey, you get a list of devices you can use. (That said, I've only just started exploring passkeys. Like you, I have strong passwords. For a few things I have memorised long strings of words. For others, I use hash-generated passwords combining a string unique to a particular website and a string common to a collection of websites as the hash input. The annoying thing is that you can't create passkeys on a Linux distro like Ubuntu. If I have access to one of my phones, or a Windows laptop, and likely (though I've not tried) a mac, I can log it in. For now i'll keep the password option available, but probably i'll sign in with a passkey wherever I can.)

If MS had the option to do what they allege Google might do, would they do it themselves? And what would they say when others complained about it?

They are complaining because they want to leverage courts and regulators to aid them in the competitive marketplace. They are saying whatever they think will help them in this regard. They are not saying this because they think the market is unfair, and would support an unfair market if it was unfair in their favour. That's just how business operates.

What needs to be done by somebody is to construct an overall picture of how the internet is structured: what is needed in terms of bandwidth and connectivity, what we have, and how it is paid for and by whom. Leaving things to the market means you have a bunch of interconnected fragments each controlled by a separate private entity who is primarily interested in their own profitability, not the overall picture and how they fit in. A modern company is incentivised to game rules to improve their own situation even if it comes at the cost of other players in the market. Areas of market failure (that is, areas where free market mechanics don't incentivise desirable overall outcomes), and then solutions sought. We want a market that leads to good overall outcomes, but this is far from guaranteed by just 'leaving it to the market to sort out'.

That's like saying there's no difference between a nuke and a stick of dynamite since they both go bang.
AI is capable of digesting and training on a level which is humanly impossible, just as nukes have the capacity to create explosions on a scale which is impractical to achieve with conventional explosives.

And it is easy to implement an end-to-end encryption messaging system given what open source code is already available.

So then companies such as Canonical (and RedHat) should be organising, funding and contributing the LTS for the kernels they use. If the mainstream kernel maintainers can't cope with the workload, others must take some of the burden.

How the f*** are you meant to type on a flat surface without looking at your hands?
How do you locate keys by feel?

A system based on self-organisation through selfishness and greed, that somehow magically works out well for everybody. Simples! What could possibly go wrong. I mean, an intermediary company who's main priority is to maximise profit will surely put the interests of the artists who, to them, are simply originators of stuff they can scalp for a profit, surely they'll think of the poor artists? Won't they? With modern business and our economy all promises are empty, save for the promise that a business will do all it can to make money, and see everything else as either a side-effect or a means to an end to be exploited.

Having a women category is better than not, so far as women's motivation and morale is concerned. Just like boxing has weight classes. Ultimately we want everybody to enjoy chess and, at the competitive end, we want women to have targets to aim at, and the general lack of women in the top 100 means that having them compete solely against men gives them too few targets to aim at. So a women's category is justified.

Look at the top 100 and how many women are in it. That's why we need a women category. If being cisgender male is an advantage, even if we can't pinpoint why, then from the point of view of women chess players' morale, we need a separate category, just as flyweight boxers need a category in which heavyweights can't compete. Just because a heavyweight boxer thinks he's really a "flyweight in a heavyweight's body" and "identifies as a flyweight" doesn't mean he should be allowed to "compete according to his 'weight' identity". Same with gender identity. The trouble with trans-rights people is that they seem to believe that their ideas of trans-rights trump everything else in society. Reality is, they don't. From a practical point of view, humanity needs cisgender women, and needs them a lot. We don't need trans-inclusivity to the same degree, if at all. If you don't fit in to society, I feel bad for you. Personally, I don't feel I fit in. (Nothing to do with gender identity on my part, everything to do with mental health and autism and stuff on my part.) But I'm not screaming to the hills demanding that the rest of the world trashes the place to make room for me. I just have to take what life gives me, do the best I can, find what place I can, and be content. Trans-women have to do the same.

Why 'men seem to be better' is an important question. I have no answer. But 'men seem to be better' is a trivially easy observation. Look at world rankings and see how many women are in the top 100. We want to encourage women to play chess. It serves this purpose to have a separate women's category, gives them more attainable targets to aim for. If trans-women aren't happy competing against men, or want a cisgender-men free category, for the same reasons as we have a 'women' category, then we need a separate trans-woman category. But if being physiologically male has some advantage at the chessboard, as it would seem based on an inspection of the evidence, then trans-women likely have that advantage too, and so it is unfair on cisgender women, and defeats the purpose of the women's category, to allow trans-women to compete in it. Trans-rights aren't the most important thing in the world. Giving cisgender women their own category where direct competition with men would be demoralising to an extent (what's the point in aiming to be in the top 100, compared to aiming to be the champion) is far more important than trans-rights. It's just it may not seem that way to trans-rights activists, who seem to have no priorities in life except advancing the bee they have in their bonnet. So basically if we need a trans-woman category, create a trans-woman category, but don't shoehorn trans-women into a category for cisgender-women as if trans-women's rights to be considered women and be treated as women in every way is more important than cisgender women's rights to be treated apart from men in ways it benefits them to do so.

They have lost the idea of mechanism vs policy. At the level of mechanism, what we want is a window management system that does what it is told,
and makes this relatively easy and painless. It should be easily scriptable, easy to send messages to via the command line, or other things (OSC everywhere
is a concept I'm currently obsessed with). The kind of thing that xdotool does, (sending arbitrary events to windows); being able to tell it to produce a tiled layer in which some windows are to be put (this is how they should implement their behaviour, not trying to do an Apple and force their idea of a designed interface on everybody). Be able to tell it that certain windows should go in certain virtual desktops/activities (the activities concept from KDE is another level of desktop virtualisation, one which I find useful for separating distinct projects).

There is no magic one-size-fits-all solution to window management, and it is folly to pursue such a thing. Just start by making everything easily possible, that's
what most of the people who want to run Linux run Linux for: if we wanted to be dictated to by some über-design-company, we'd buy Apple. Sensible defaults
are a good idea, but they should be defaults, not mandatory, and they should be constructed out of the same mechanism layer/API and function as a good example of how to do things.

Now I know this is short of what e.g. Signal provides. But as a thought experiment, suppose we have a shared key-value store somewhere. Any LAMP stack anywhere will do. There is some cookie based authentication
to allow users to read/write. Then (this is a quick and dirty sketch, to needs a little work)

1. To create a room, you have a shared passphrase $S with someone else.
2. You hash("key.$S") to get a row key $K, and hash("enc.$S") to get an encryption key $E..
3. You encrypt your message with $E to get $M, and store it via storage.put($K,$M)
4. The server stores only $K, $M, and and a timestamp $T or index for messages stored with the same key.
5. To read, you retrieve all records with row key $K, sorted by $T
6. The client decrypts the result.

The above can be accomplished with a few hundred lines of PHP and Javascript, given CryptoJS. A slightly more
robust one can be done with a few thousand lines at most. And it can be stuck anywhere a LAMP stack can go.

So a very quick play in Python. The idea is that you use some method (e.g. sha256) to hash the domain components.
Probably only the first two or three. But anyway, this is a quick play. Basically all you need to do is to check that the
checksum matches. You could use an email address of the form "andy=dda1-85d9@my.uni.ac.uk" where the convention
is that the "dda1-85d9" is a checksum of the domain name. Then a mail client could notice that "andy=dda1-85d9@my.uni.ac.at"
fails the checksum whereas "andy=dda1-85d9@my.uni.ac.uk". There's likely a far better checksum method, but basically
assign a four-char hex string to an email address, then append "=bd5f" or whatever to the name before the "@" and a client
can then easily pick up likely typos.

from hashlib import sha256

def f(x):
    sha = sha256()
    sha.update(x.encode())
    return sha.hexdigest()[:4]

def g(addr):
    dom = addr.split("@")[-1]
    ds = dom.split(".")
    da = [ ".".join(ds[i:]) for i in range(len(ds)) ]
    dy = [ f(x) for x in da[:-1] ]
    return "-".join(dy)

# output:
"""
>>> g("mrbob@mysite.co")
'237a'
>>> g("dave@mysite.co")
'237a'
>>> g("dave@mysite.com")
'42b9'
>>> g("dave@wibble.wobble.mysite.com")
'f64f-25f1-42b9'
>>> g("andy@my.uni.ac.uk")
'bde6-dda1-85d9'
"""

I've thought along these lines for a while. I'm using Qt as an example here. Rather than low level drawing, consider the facilities provided by a toolkit like Qt, or perhaps the Chromium rendering engine. If I just want to display some HTML on the display server, all I really need to do is create a window with an WebView widget and sent it contents, and perhaps send through Javascript for it to execute. That avoids a lot of network round-tripping. If I want to create a UI with widgets, actually have a standard set of widgets and an API for creating them, possibly server-drawn and possibly client-drawn. For client-drawn stuff, we want a Canvas API with a modern graphics API (as an example, rather than rendering client-side, you want to just send drawing instructions to a QWidget on the server). Then events the client is interested in are sent to the client. Some stuff can be dealt with purely server-side. But basically most use cases where you want the network transparency of X are better done at a higher level. Then implement this (like XWayland) as something that runs on top of Wayland, possibly integrated into a compositor.

As a mental exercise, consider you want to pop up an alert box from a python script. I'd like to only have to write something like

import display
display.Display("my-display-server:0").alertBox("Hello World",display.ErrorIcon,sync=True)

Or something. Basically have an actual toolkit with network transparency, the server-side part of which sits on the server and does the drawing.