Oddbean new post about login | logout I've come to the conclusion that Nip-52 Calendars should probably just be their own npubs. Can someone tell me why this may be stupid before I waste a bunch of time, thanks 🙃
Each calendar has its own d tag, so i guess creating new npubs is more for whether you want to follow calendars of an individual, or those prepared by an org where key ownership may be passed along?
This would replace the need to the calendar kind entierly. Calendars will just be the pubkeys that create the events. Seems like a more straitforward way to delegate roles since selective premissions can be given to the calendar pubkey via a bunker
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).
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 https://github.com/nostr-protocol/nips/pull/875
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.
I think you could do both, without overloading kind 0. You'd publish a product-specific metadata event, and a fallback profile that includes a link to somewhere you can view the full listing. I don't think that would mess anything up, and it would get you the fallback you're looking for.
Fallback profile, mhm, could works. But are you still talking about a keypair for every product?
Where would I store all the private keys for my calendars? Could we derive them from a seed or a master private key?
What if I want to subscribe to a person’s calendar? How would I navigate from that person’s pubkey to a calendar pubkey?
Ok, @zach just convinced me in person that this might be a good idea. The person can still be a calendar if it’s going to be only one person and a single calendar. But you could also have a dedicated pubkey for a calendar. Clients can subscribe to calendar event kinds rather than need to first subscribe to a calendar list, then to the calendar events within that list. It simplifies the number of queries you need to make to get a list of calendar events. And also, clients can still opt into supporting calendar lists if they wanted to.