I’ll circle back once I get to implementing “suggested follows” lists for “social onboarding” client.

I suspect implementing clients need lists “of this type” from users, and the NIP doesn’t support such specificity… maybe?

Lists are the foundation of organized information. Any property added to a list created a unique kind of a list. From what I gather there has always been a fear of NIP-51 becoming bloated. However personally I believe that NIP-51 will become the foundation for all of the Nostr ecosystem and the bloat will instead become regarded as valuable kinds of lists. We should embrace the work put in so far to determine the importance of other NIPs first. Lists are a complicated matter at the end of the day because they can be leveraged to any extent, in any context, at any level of the ecosystem. There is no one-size-fits-all kind of list. How lists are employed is a matter of how relays operate. So, I think we now have a framework for sharing and leveraging simple lists.

We can now move on to Listr, a protocol for sharing and creating unique kinds of lists. This would interoperate with Nostr.

We can move on to complex lists.

And we can move on to Graphstr.

Check out my other reply here:

nostr:nevent1qqs2eg4jesueskvzlumcrzw92ep03rd02mz48k73hp4pqx23rn6j2dqpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzq5yqnffla72eq3gn4pqdgzp2j269e403h8jrdkwjhy4gnnsfrutyqvzqqqqqqym956g9

Sorry, wrong note.

nostr:nevent1qqszet0vfjgzyfs5l364lypmxdyujrje8e7z8q4nk8vz4l3u4gkvhpcpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzq5yqnffla72eq3gn4pqdgzp2j269e403h8jrdkwjhy4gnnsfrutyqvzqqqqqqy6htptd