But why rewrite programs that existed for decades and have proven their stability and safety? Rewriting them to Rust won’t make them safer, it will just introduce the kind of issues original versions have got fixed long ago.

Of course rewriting them will introduce some new issues, but it will also eliminate classes of bugs from which there are definitely still a great many in old “stable” C code (bugs which are now being discovered and will presumably continue to be discovered at a much faster pace due to LLMs).

The whole project is about abolishing GPL. And Rust is just an excuse.

I don’t think it is just an excuse; I believe that improving security is also a goal… but removing GPL code is clearly also part of their motivation :(

No, it is not a good time. A project like Ubuntu should now be in freeze as they had about 3 months before release

This bug was reported (and resolved by rolling back to the GNU coreutils version of cp) on June 30, a little over 15 weeks prior to the scheduled release date.

Which distros have a feature freeze that far in advance?

Ubuntu hasn’t even scheduled theirs for this release yet; if you edit that url to look at previous releases’ schedules you can see their feature freeze and debian import freezes are typically about 2 months prior to release. (See here for descriptions of all of the different types of freezes…)

What an absolute shitshow

I’d say the month of June is actually a good time to be breaking and fixing things in a release that is due to come out in (checks notes) October.

see also previous thread in this community on this topic from a month ago

For each participant, Dialog logs a membership status, every retreat the person has attended, a biography, a home city, and a private access token. WIRED is not publishing the tokens, which function as login credentials, or the personalized account links that contain them.

This is an odd thing to say given that neither Wired nor their source (“the Swiss hacktivist maia arson crimew”) appear to be publishing any of the actual data whatsoever, beyond the handful of mostly nonspecific references to it in the article text. (Eg, lots of sentences like “The website directory names sitting Trump administration officials, two US senators, six members of the Paypal Mafia, a former Middle East chief of intelligence, and a sitting ambassador to the United States, along with the founders and directors of many of the country’s largest surveillance, data-broker, and advertising-data companies.” - omitting names of any of these people.)

Also, the linked archive says:

Update 6/16/2026, 5:47 pm EDT: WIRED updated this article to correct a conflation of two people named Jeff Epstein. A small revision was also made to address a security concern raised by a Dialog representative.

Someone helpfully had already made an earlier archive before that, so we can see what information Wired journalists Dell Cameron and Yulia Almazova removed at the request of a Dialog representative: where it now says “The retreat is scheduled for August 12-16 at a venue near Dublin” it originally said “The retreat is scheduled for August 12-16 at the Powerscourt Hotel outside Dublin”.

tuta is (like proton) snake oil. (here and here are two of my old comments about why…)

Mailbox.org lets you keep your own private key.

Every email provider lets you keep your own private key if you do encryption using the interoperable OpenPGP standard using software running on your own computer. Many email providers will recommend that you do exactly that, and will helpfully instruct you about how to do so (eg, the more reputable options in this thread such as migadu.com, mailbox.org, posteo.de, and even fastmail.com all have instructions for how to use some implementation of pgp to encrypt your email).

Meanwhile any company selling non-standard “email encryption” (eg, proton and tuta) which is not compatible with pgp (or, in the corporate world, s/mime, which is also a standard…) is firmly in the snake oil business and should be distrusted and boycotted regardless of which shitty youtubers they’re sponsoring this week.

Companies now block older browser versions

Now? This has been happening since the dawn of the web. At least the screenshot you pasted represents all of the big three rendering engines - it used to be common to see “Internet Explorer version XYZ required”, sometimes with javascript to prevent you from using the site with any other browser (even if in some cases it would actually work fine if you simply spoofed your user agent string).

I have used kinda retro devices to surf the web at times

Most websites became HTTPS-only sometime after the snowden disclosures in 2013.

Over time old versions of TLS have been deprecated and eventually support for them is dropped from browsers and web servers alike. So, a browser from even 15 years ago literally cannot connect to most webservers today.

Planned obsolescence is terrible but it’s a minor factor here: it’s actually dangerous to use even (especially?) a slightly-out-of-date web browser because every new release fixes vulnerabilities which can be exploited to run malicious code on your computer. The planned obsolescence which prevents people from being able to have an up-to-date browser comes mostly from proprietary operating system vendors; to have up-to-date software while continuing to use somewhat older computers you need to use free/libre software.

sydney morning herald my head

i concur, but a lot of people do start out with Arch afaict

Wait but that means your computer will stay on if the update fails, right?

If it was && then the second command would only run if the first command was successful.

But @vodka@feddit.org wrote only one & which instead means the first command will run in the background and the second will execute at the same time… which does not seem like a good idea in this case 😅

Many people do seem to like Arch fwiw

i don’t recommend Arch smh

As others have said it is a huge amount of work to maintain a fork of such a complicated piece of software.

Especially around security: web browsers constantly process potentially-malicious data, which gives them a large attack surface. Every browser regularly has new vulnerabilities discovered which must be fixed. Hard forking a browser means that, even ignoring any bugs in the new code the fork has added, every time a bug is discovered and fixed in the code they forked from someone needs to analyze the upstream’s fix and port it to the fork. The more they diverge, the more work this is. Failing to do this work lets any malicious website exploit the bugs and install malware on users’ computers.

The core idea behind the “server-free” design is to keep users’ messages from ever touching the cloud

given that the messages are encrypted, what is the advantage that you perceive in using “the cloud” (servers) only for signaling rather than transmitting the actual ciphertext through them? Wouldn’t your “cloud” servers see “just the metadata” either way?

It saves some costs for you, but it comes at the cost of requiring users to be online at the same time to exchange messages… is there some other advantage that you see?

a server-side check on the Play purchase token

ah, so it will be the kind of “free open source software” which can only be used via Google Play 🙄

Separate forks aren’t interoperable

that’s another thing you should inform potential users of explicitly, if you want to be honest.

i won’t comment on your tor-to-cloudflare-to-google design because i haven’t looked at it and don’t expect i’ll make time to anytime soon.

I don’t think I can avoid cloud services entirely

Lots of similar things are able to avoid cloud services entirely; your perceived need to use them is driven by your so-called “server-free” design which isn’t really free of servers at all because, as the saying goes, “there is no cloud, just other people’s computers”.

You could also use Google’s push notifications but make them optional, btw. Making the protocol have a hard dependency on that is a choice you are making.

when the two peers are within Bluetooth range

having users’ devices transmit fixed identifiers while moving around is terrible for privacy / great for surveillance, and firmly in the category of things which i not only do not recommend but implore people to not build. please don’t.

I’m now focused on defining a solid architecture rather than working on my landing page

But your landing page is still up, and still making unsubstantiated claims and encouraging users to trust in (aka rely on) a thing which is totally half baked. You are still peddling snake oil. You should fix that.

The App is not for sale anyway at the moment, if and when I will eventually try to sell it, I was thinking about a monthly subscription, that would cover the cloud services costs plus some revenue.

I see, now we’re getting down to it :)

A few questions on that front:

1. Did you disclose to your beta users (and the general public you’re asking for help here from) that they/we are doing volunteer work for what you intend to be a for-profit endeavor?
2. How do you plan to limit access to your cloud services so only subscribers can use them?
3. If someone wants to fork the software (assuming you’re planning to keep it under a free software license) presumably users of the fork will not be able to communicate with the users who are paying you, since the whole thing fundamentally requires the cloud infra you’re paying for? Or, if you actually want forks to be interoperable, how do you expect that to work?

you say this is “now documented” but you actually also mean now implemented, don’t you?

I just looked at github and i see that until this commit one hour ago (four hours after i asked) you were actually calling db.collection(“users”).document(peer.userId).get() to read a publicKey from Firebase

Yep, true

thank you for your (belated) honesty on this :)

So genuinely, thank you for your time and feedback, of course I respect the decision, not going to re-post

thank you and you’re welcome