I once tried to make groups as npubs, nostr:nprofile1qyvhwumn8ghj76r0v3kxymmy9ehx7um5wgcjucm0d5hszrnhwden5te0dehhxtnvdakz7qg3waehxw309ahx7um5wgh8w6twv5hszymhwden5te0wp6hyurvv4cxzeewv4ej7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uq3camnwvaz7tmrdphhyatn9ekkj6m9v35kcem9wghxxmmd9uq3camnwvaz7tmrda6kuarjd9jhxtnxd9shg6npvchxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqypaaaaa7ytwcuk05vq8qgj498gw0jadfm37j0h6cxw780kmcffvq2875gre proposed products as npubs, someone proposed forms as npubs, and (in my opinion) none of them really was a good fit. Stuff that's domain specific should be domain specific (even if there is a key tied to the alternative metadata event).
Discussion
The thought is that the Calendar npub will be the one that creates all of thier events. Then if you want to allow multiple event admins to edit, you can just set up multi-access to the calendar pubkey through a bunker.
That's very similar to what I did for private groups
Group Chats are the best way to bootstrap all of this indeed.
I'm still considering it :)
I think npub makes sense in some contexts because it acts as a kind of backward-compatible gateway to the “object.” In fact, all clients can display a standard profile. But if the metadata is specifically labeled, as in my proposal, clients that support it can show an appropriate view. Querying relays is also possible and easy.
I agree that this seems suboptimal from the point of view of traditional data modeling, but it has enormous advantages if we talk about discoverability and interoperability, which are (at least the first) a fairly critical point in Nostr.
Of course, we talk about npub when you need an entity that has some sort of autonomy and is not necessarily tied to an owner.