I suspect the reason for the difference here may be specific use case and the implications there on the size of the files? The author's use case is Lua files to run in Minecraft, and I strongly suspect their example file at 327KB is very much closer to "typical" for that use case than a 1GB SQL file.

It wouldn't surprise me at all that "more modern" compression techniques work better on larger files. It also wouldn't surprise me too much if there was no such thing as a 1GB file when bzip was originally written, according to Wikipedia bzip2 is almost 30 years old "Initial releases 18 July 1996". And there are mentions of the preceding bzip (without the 2) which must have been even earlier than that. In the mid/late 90s I was flying round the world trips with a dozen or so 380 or 500MB hard drives in my luggage to screw into our colo boxen in Singapore London and San Francisco (because out office only has 56k adsl internet).

They could probably fairly easily identify all the authors of the opensource software the hoovered up and used in their training set.

But them even admitting that was possible is a little bit to close to being able to be held accountable...

> if you believe quantum computing will ever happen.

... and you don't believe that everything will be totally fucked when it does happen.

If there is a global passive observer, and they get quantum computing, a huge amount of supposedly encrypted private information just got popped. Whether or not I care about my dinky little private social network posts when every ssl/tls connection I've ever made is being cracked and data mined is an interesting question.

I can think of at least a couple of dozen fairly technical friends who'd be capable enough to set this up themselves, and who're at least adjacently interested in recreational paranoia. And probably another dozen or two who're definitely into recreational (or possibly delusional and/or fully deserved paranoia) who'd be willing to learn or get help setting this up.

Right now, those circles of friends are _reasonable_ well served with some combination of Mastodon (effectively zero security but with decent findability) and Signal (much more limited mostly to only people you'd be OK with having your phone number).

I will definitely take this for a spin, and start having discussions with particular groups of friends to see it I get any traction.

I think a lot of even not very technical people have gotten used to TOTP QRCodes, and being able to store screenshots of them in password managers. (And having experience in losing 2FA keys that they'll go to some lengths to not repeat.)

I wonder if there's a decent way to encode these private keys in QRCodes? You can jam about 4kB in a high density one from memory? (I know that'd be possible from a developer/technical point of view, but if this were my project I'd want a talented UX designer to have complete authority over how this is presented and explained to users.)

One other idea - maybe implement a Shamir's Secret Sharing mechanism where your private keys get sharded and encrypted to a sufficient number of selected friends, so of you lose your s@ private key it can be re assembled by convincing - say - 8 out of 12 selected friends to give you their part?

Or alternatively - automate a "recovery mechanism" where you set up a new key pair and publish it on a temporary domain/site, and can then ask a friend/follower who can authenticate your identity out-of-band - to export all you posts decryptable with your new key, then put you new key and all your old posts back into your main site.