refalo

many native elements either do not function like people want or cannot be styled the same

This is like asking for people to stop engaging in capitalism. Good luck with that.

Appreciate you adding the ability to manage STUN and especially TURN servers because this is sorely lacking in so many tools.

The unfortunate reality in my experience seems to be that a very large percentage of users are behind symmetric NAT on both ends, making TURN necessary for WebRTC to work at all.

PayPay's server fell victim to a hacking attack, originating in Brazil, on November 28, 2020. As per the operator of PayPay, a server containing personal and financial information of its entire userbase was compromised. The company acknowledged that configuration flaws led to unauthorized access to information. The service operator was later notified of the incident and preventive measures were taken.

Japanese consumers are historically very privacy-conscious and afraid of identity theft, so it's no surprise to me that they don't want to use services like this. Even credit card usage in Japan is extremely low compared to the rest of the world.

Their usual cashless payment methods like Suica/etc. are anonymous and have been in widespread use since the early 2000s, so I predict that will continue to be the preferred payment method (besides cash) for the forseeable future.

potentially escaping the notion that because Qt is C++, it is not as safe to use.

How does this even potentially escape the notion? Qt is still C++, and still unsafe, no matter what you use for the rest of your application. And the fact that Widgets is being left out in the cold doesn't sit well with me either.

They still won't even say what these "bridges" are, other than it "does not necessarily replace existing bindings". Does that mean it's still yet another binding?

What would have been really nice IMO are some plain C bindings, for both widgets and QML.

Well general strategies are going to depend on where the bottleneck is, so the main general strategy is simply to find the bottleneck. From there, there may be other general strategies one would use for those, but there's so many possible starting places, it's hard to give any specifics as they all depend on what the bottleneck actually is.

I would argue TRON OS and its variants are in more devices on the planet than Linux is.

Have you actually analyzed what your real bottleneck is?

My experience with IPFS over the years has been abysmal, and I think people have said the protocol design cannot sustain any more growth, which is not even that big yet at all.

You also cannot realistically search for files reliably by its hash, because of how files are divided into smaller pieces, whereby the method of dividing can change between clients, making the hashes incomparable. BitTorrent v2 solves this to my understanding, but almost nobody uses it for some reason.

Often times you need to wait several minutes for IPFS to find a file, assuming it ever finds it, which sometimes fails even on two boxes next to each other.

the interface is not near as slow and clunky IMO, and it's always broken when using JShelter extension for me

IDK about "still" since you can disable the GIL and also use multiple threads/processes, but I get your point. But rust is certainly not the only other language that can bring more efficiency or parallel performance, was my point. Yes it allows you to use multiple cores, but so do many other languages, including python.

Being built in Rust allows server workers to use multiple CPU cores for superior performance

that's like saying "going outside lets you breathe air"