A client simply isn't enough. If I needed to collect lists manually, I have better "devices" (see: applications) to do so.
What nested NIP-51 lists would allow for is enabling entire protocol to have organized, managed lists.
Let's say I build a client for "managing friend lists," well, I've really just built a "list managing client."
This is basically a hindrance for any application that wishes to have modular list organization.
Nostr needs to manage lists natively.
What do you think about nested communities?
That is in many ways the goal. It's a question of "which level of the protocol will control the lists of communities and, in turn, create nested lists of them."
As of now, one can create an application that nests NIP-51 lists. I believe there is value in doing so, but it's a question of how it benefits the application, or a question of what application you are trying to build (with nested lists).
I envision giving users the ability to create nested lists of communities that can scale to become national or global communities. It's a question of how, though.
