P2Panda and the super-peer curse

Recently was suggested to me that https://p2panda.org/ was a great protocol and that maybe Nostr wouldn't be necessary if we could just use that. After making the blind remark that p2p doesn't work I was pointed to https://github.com/p2panda/aquadoggo which acts as a "node" in some ways similar to a "relay", and it all looks somewhat well, cool, maybe they're into something:

Then I realized that Aquadoggo isn't really a relay, it is more like an "app server". There are still no relays in the Nostr sense in p2panda, the base of communication is still p2p between "nodes", and, as Aquadoggo's readme say, it could be run both as a client and as a server. In other words, we could easily have an "Nostr Aquadoggo" that abstracts all communication with relays, relay selection, event and tag parsing and signatures then stores filtered, ordered, indexed data locally: it is just a Nostr client.

That you can put one of these in a server doesn't change that fact that it will be still a client -- and that underlings behind it consuming its API will be controlled, censored, mislead and tricked. This design that requires trust in one single server from a dumb client in exchange for massaged, sorted, filtered, ordered data is seen not only in p2panda, but it's also a fundamental part of the design in many of the supposed decentralized protocols out there, including Bluesky, Farcaster and Pubky. It has also found its way even into RSS, with feed aggregators, and into IRC with bouncers. It can also be seen being experimented with inside Nostr, with ZBD Social, Primal, Ditto, Satlantis and others I forgot, and even behind the ideas of some pseudo-relays like Bostr and filter.nostr.wine (although I'm not sure). Notably, though, this design is not a part of SSB or Mastodon and these two weren't ever corrupted by it as far as I know.

In any case, should we accept that such architecture will eventually find its way into Nostr and completely dominate it? If I believed the answer was "yes" I would immediately declare Nostr a failed experiment, but I don't. As the main author of one such experiment (ZBD Social), I still think this architecture isn't necessarily bad as long as it's limited and restricted to certain circumstances, but it does pose a risk of Nostr becoming almost as bad as Bluesky, so the path has to be threaded carefully.

Ultimately, though, what all these protocols are trying to achieve by injecting these dangerous super-peers into their architecture is the reliability that pure p2p cannot provide, along with filtering and discovery features. And Nostr's multi-relay architecture, as cumbersome and weird as it is, represents a very different approach to solving the same problems, one that none of these other protocols can even begin to consider emulating, and I believe we have to accept that, embrace it and lean on it more.

We can go there by having whitelisted relays as communities, relays that enforce group rules automatically, relays that provide fulltext search, relays that provide AI-based personalized custom feeds, relays that filter out reply spam or harassment (or enforce blocks at the server-side), relays that restrict reads to a certain selected group, relays that perform curation and make valuable content reemerge from the abyss of the ongoing stream; and of course clients that surface all these different types of relays and their features.

Why is this complex madness better than the super-peer architecture? Because, well, even though custom relays give us all these cool weird features, The basic Nostr feature of being able to follow anyone you want and not giving a super-peer the power to break that link between follower and followed, i.e. the outbox model, is still the most basic function of relays.