Quantum error correction goes well beyond breakeven

A demo of error-corrected qubits shows big reductions in errors as they grow.
https://arstechnica.com/science/2026/10/quantum-error-correction-goes-well-beyond-breakeven/?utm_brand=arstechnica&utm_social-type=owned&utm_source=mastodon&utm_medium=social

I think Cory D. wants to live in a world where he can have his cake and eat it too

He gets to be the knight in shining armor to rescue us from the horrible Big Tech companies

At the same time, he wants to embrace the technology produced by these Big Tech companies and say it's pretty great actually.

Fuck that shit. 💩

I shared a link from NPR Tiny Desk but there was no image preview or video embed. After investigating this I learned that when you do that, each instance picks up the link and individually retrieves the link preview nearly simultaneously. For gargantuan sites like YT or Reddit, this is a trivial amount of traffic and not a problem, but for smaller sites like NPR this results in a sort of botnet DDOS attack on the site’s servers. More here. Another example here . For that reason, NPR has blocked Fediverse servers like Mastodon.

I have experienced this on my personal server as well (DDOS), but at the time didn’t know why, exactly.

This isn’t the end of the world, but certainly is not great and hurts engagement with the content. Is there a solution for this? Perhaps using some sort of webtorrent service like PeerTube where they just fetch the information from another fediverse server instead of the source server? Maybe fetching embeds client-side? At least that would stagger the requests.

@christianselig huh?

gabagool

@nextcloud sovereign is when floppy disks, electron orbits, and silicon wafers :3

@mcc @ulldma Safari, but I tried firefox too. It follows exactly what Safari is doing. I expect that as a "Safari with a different skin", FF doesn't/cannot do anything about their trust store.

There are two proposed solutions I have seen. I do not claim that this is exhaustive, just only limited to the proposals that I have stumbled across.

FASP - Fediverse Auxiliary Service Provider

The idea that mastodon has is to have a third-party service that does something like generate a link preview once and then share that to fediverse instances that need it. They have a whole spec they wrote up about these kinds of services that can be run to help out fediverse instances with different things like this, search, or discoverability. They call these FASPs - the repo with the spec is here.

I don’t yet know of any FASP that is live and running, so it is kind of a paper spec at the moment. I don’t do too much on the microblogging side of the fediverse though, so I very well could be wrong.

Federate link metadata and the post at the same time

This comes from an issue on PieFed’s repo. It is basically just an idea at this point, but it is a pretty basic one; have the originating instance fetch the link preview information and simply federate it out alongside the post itself.

@eff so you proofed that #meta_corp works / collaborates with some #maga_fools to surveil various types of misfitting people / groups ?

e.g. in brazil #bolsonaro #cerimedo and DenHaag #icc ???

but prob also inside usa ?!?.. #NoKings
.
relevant for global focus on and development of #TechSov

@ele
@ulrichkelber

#SaveSocial

small singleplayer online FPS

@q it’s fucking literally that one xkcd wtf

4 times the SECP384-R1 base point is (0x138251cd52ac9298c1c8aad977321deb97e709bd0b4ca0aca55dc8ad51dcfc9d1589a1597e3a5120e1efd631c63e1835, 0xcacae29869a62e1631e8a28181ab56616dc45d918abc09f3ab0e63cf792aa4dced7387be37bba569549f1c02b270ed67)

https://repository.emsign.com/certs/roottlscag3.crt

for the non-cryptographers are the back of the room: the private key is 4, just the number 4, nothing more

Certificate:
 Data:
 Version: 3 (0x2)
 Issuer: C=IN, O=eMudhra Technologies Limited, CN=emSign Root TLS CA - G3
 Subject: C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C
 Subject Public Key Info:
 Public Key Algorithm: id-ecPublicKey
 Public-Key: (384 bit)
 pub:
 04:13:82:51:cd:52:ac:92:98:c1:c8:aa:d9:77:32:
 1d:eb:97:e7:09:bd:0b:4c:a0:ac:a5:5d:c8:ad:51:
 dc:fc:9d:15:89:a1:59:7e:3a:51:20:e1:ef:d6:31:
 c6:3e:18:35:ca:ca:e2:98:69:a6:2e:16:31:e8:a2:
 81:81:ab:56:61:6d:c4:5d:91:8a:bc:09:f3:ab:0e:
 63:cf:79:2a:a4:dc:ed:73:87:be:37:bb:a5:69:54:
 9f:1c:02:b2:70:ed:67
 ASN1 OID: secp384r1
 NIST CURVE: P-384