A federation of forges makes no sense if everything gets centralized again in the hands of the people operating Tangled (sure, someone else could run an alternative AppView, but then if you are only on the alternative you are invisible to anyone who is only on Tangled).
Unfortunately this paper doesn't live up to its goal of being a cheap attack on Nostr.
The fact is that clients do verify signatures from events received from servers, that is in the protocol specification and should be obvious to anyone mildly honest.
The entire assumption of the paper is that clients don't do that and it is void. Yes, they did find a couple of clients 2 years ago that didn't verify signatures -- so much for a vulnerability in the protocol. I guess they wanted Nostr to have a code police arresting client developers who didn't finish their implementation?
Aside from that the attacks they demonstrated depend on a bunch of other absurd circumstances (like you have to manually and voluntarily type the URL of the attacker server in order to be attacked) but it's not even worth talking about them since the basic assumption is so completely false already.
The encrypted messages stuff is not even a core part of Nostr anyway, Nostr is a broadcasting protocol for public or semi-public content. Encryption can be added on top and there are multiple ways and proposals for how to do it, including an implementation of MLS and other methods and I personally mostly do not care about any.
I wish the paper authors were more honest and republished their work with the title: "the dangers of trusting a cryptographic signature without verifying it", but I imagine that it would have been too obvious and worthless if it was phrased like that.
There is no blockchain, only basic cryptographic signatures on each message. And users are not tied to any servers, they can read from multiple or write to multiple. They can (locally) aggregate data from many servers or connect to a specific server, same for publishing, it's very flexible and different clients choose to do it in different ways and expose different interfaces to users.
Yes, that makes sense and that can be used later by relays and clients in order to decide whether to store or display notes from identities. In fact that's a pretty good idea.
You only read from the relays you want, relays have all the tools in the world to reject spam, therefore the solution is just to have clients that help the user enforce selecting only what they deem as "safe" relays in order to read replies from.
This is cool but P2P doesn't work. Iroh also relies on "relays" in a sense. Nostr makes that explicit and gives relays identities so they can freely enact policies instead of having to hack that in weird ways.
That's a misconception: you don't "use" relays (in the sense that you don't have to have a static list of relays you always use), you write to relays. When reading you connect to the relays of whatever the people you want to read from.
Some apps indeed use this method of selecting a static set of relays, and if that was the protocol you would be correct about centralization or bloat, but this is legacy from a naïve unfinished early implementation, most apps do the correct thing now and the rest is transitioning.
You have demonstrated you have no idea of what Drivechain is, you probably never spent the time to learn how it works, and yet you feel entitled to call it "idiotic".
I get it, it's fine to not want to learn things, but that comes with the burden of not being allowed to comment on it.
Apparently you have not carefully read my criticism of the big block proposal above. I've included some numbers. A proper response would have to address those. But thank you for trying.