The original freenet design was replicating content as it was requested. You had no way of locating "all" the copies as they would get cached "along the way" elsewhere on the keyspace when you request them.
That property was useful both for improving availability AND censorship resistance: you could not attempt to "locate" where the blocks are without spreading them.
My naive understanding of the new design is that you can have contracts that are replicated... but they still cluster around the same place in the keyspace so any capable active adversary can actively deny access to content trivially. Did I misunderstand something here?
You're moving the debate here. The question was "How are the goals different?" from the project leader (who ought to know better), not whether moving them makes sense.
He has forked the project (to something that does not share the same goals so "fork" is arguable here), took the name, the cash and the goodwill.
We went from "we have enough donations/donators" to "how do we pay for the upcoming AWS bill?".
As someone who has been fairly active on the "old freenet", I have never cared about money nor funding... but I cannot help but notice that some has likely been misappropriated. Things like the SUMA award (https://web.archive.org/web/20150320201527/http://suma-award...) were awarded specifically for "protection against surveillance and censorship" that the "new freenet" does not even aim to provide.
"The board" of the non-profit seems to have been culled just before the decision. I don't know why, I wasn't on it. Maybe @agl can shime in (he was).
TLS1.0 introduced modularity via the concept of "extensions". It's everything but a minor evolution of the protocol.
One of the many things it brought is session tickets, enabling server-side session resumption without requiring servers to keep synced-up state. Another is Server Name Indication, enabling servers to use more than one certificate.
It would be great if Google supported rfc8414 and rfc7591. Right now most MUAs hardcode credentials instead of auto-discovering/registering/configuring them and decline to implement those standards "because the big boys don't support them". The practical result is that one cannot use oauth2 on their domain easily: the MUA needs to be told about which set of oAuth2 creds to use.
As one of the maintainers of Mailu, I'd say use Mailu!
Why? three main reasons: (a) security (as you have identified isolation matters, but that is not the only thing), (b) get the benefits of "battle-tested" setups and (c) features
On security: in its default config, Mailu scans emails for malicious macros via oletools (and optionally viruses via clamav). It also uses a hardened-malloc, Snuffleupagus (a security module for PHP), gates all PHP code behind an authentication wall (webmails), ... and does both DANE and MTA-STS validation to ensure your emails are delivered to the right place. The authentication stack handles "smart" rate-limiting: you get to limit the number of authentications with distinct credentials over a time-period (a misconfigured thick client won't trigger it), you have plenty of ways to avoid running into it (application tokens for thick clients, per-device cookies that give you a way out, whitelisting of "used" addresses, ...) and you also get to rate limit the number of sent emails (useful if a spammer gets their hands on the credentials of one of your users)
On the importance of "battle-testing" setups: well, there are plenty of non-subtle ways of breaking an email setup. Experience has shown that all the layers in the stack can be problematic... I can give you a bunch of examples of what we ran into recently if you want.
On features: your setup might be simpler but your users are missing out. Whether it's enhanced filtering (like with oletools), better indexing (full text search), indexing of attachments (with OCR! via Apache Tika), configuring server-side rules with managesieve or just "having an interface" to configure ooo, change their passwords, configure aliases or delegate permissions.
I have started spending time on Mailu because I don't like the bloat that comes with Mailcow. Give Mailu a shot; it is reasonably easy to debug when things go wrong (and not written in PHP :p).
That property was useful both for improving availability AND censorship resistance: you could not attempt to "locate" where the blocks are without spreading them.
My naive understanding of the new design is that you can have contracts that are replicated... but they still cluster around the same place in the keyspace so any capable active adversary can actively deny access to content trivially. Did I misunderstand something here?