Request for comments on my pull request for NIP-52: Calendar Events. It’ll enable developers to build calendar apps, meetup apps, and conference apps upon the same primitives. It’s my first NIP — welcoming any and all feedback. Thanks in advance! nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p nostr:npub1ejxswthae3nkljavznmv66p9ahp4wmj4adux525htmsrff4qym9sz2t3tv nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1nxy56ame2gfnfj6fjylzxwq7r94phvgwt037mmvwr60qsqlaseksswlnxl
Discussion
Great!
Does this have recurring events?
Oh, I completely forgot about recurring events. Let me think about how to add it to the NIP.
This, if done wrong, will render it a source of endless misery for generations
so no pressure 😹⚡🤙💜
When you introduce recurring events, you also need to handle cancellations of instances, cancellations of ranges of instances, and modifications to instances. The problem with rhe vcard specification is this aspect seems to be ambiguous enough to have caused confusion across implementations.
Im not proposing you add recurances, only that it should be addressed. You might decide to simply specify there are no recurring event types and all calendar events must be specified as separate objects.
👀
I upvoted
👀
👏👏👏
nostr:npub1t0nyg64g5vwprva52wlcmt7fkdr07v5dr7s35raq9g0xgc0k4xcsedjgqv
“Any user may RSVP, even if they were not tagged on the calendar event. Clients MAY choose to prompt the calendar event creator to invite the user who RSVP'd. Clients also MAY choose to ignore these RSVPs.”
good or bad ideas?
Left a bunch of comments
Looks good in general, I do wonder if there isn’t a more nostr-specific flow that we’re not seeing it; the current data model feels very much like porting the known calendar UX to nostr
That might be fine, but perhaps there’s something we are missing; have you implemented this already? I find that when I write the app I usually discover the nostr-enabled use cases more easily
Thanks! Yeah, I very much so used Google Calendar and the iCalendar spec as inspiration, so it’s possible there’s Nostr flows that I haven’t optimized for. I’m in the process of implementing against this proposal for the nostr:npub1c0nfstrlj0jy8kvl953v84hudwnpgad0zx709z0ey7nmjp0llegslzg243 web app via NDK, so we’ll see how this plays out.
looks cool.
Maybe find a way to include payment for an event too, as nostr events can be zapped too.
And you can verify proof of payment according to NIP57
Building.
Every.
Damn.
Day.
this is nostr
Wow Terry! Nice work! This is a great NIP idea and would be a wonderful feature.
Man I gotta tell you, I couldn't code "hello world" if my life depended on it, so I'm not sure why such a technical announcement sounds so freaking exciting to such a layman but, yes. Just.. yes my dude. Great job.
Too modest. Anyone can code if you spent enough time with it.
It’s exciting because we’re rebuilding the internet at the most foundational levels and it impacts everyone!
👀
This is looking good.
I say move forward with the first basic feature and see what you learn and maybe it becomes clear how to implement more advanced features after you get your feet wet with singular calendar events.