Replying to Avatar Laeserin

Well, we'll have two of the biggest calendar clients. If we agreed on a new event type or some changes to one, with a NEP (Nostr Extension Proposal, i.e. a spec that's a spin-off to NIP-52), then it becomes part of the protocol. Especially as we have a relay dev on the team, and we could then prove two clients and a relay are compatible with it.

We are also missing some capabilities, in the current NIP, like we'd need more focus on time-zones (as we're planning meetups on different continents and the display is really confusing, otherwise), and we need the ability to link a set of events together into a series (like different appointments during a 3-day conference or meetup: demo session, hackathon, dinner out, etc.), with the series belonging to the calendar. Integrating polling is important, too.

We also need co-hosting. We were talking about maybe having a multi-sig event format, or something containing a sort of id-array, also for issuing confirmation-of-attendance certificates while there, by performing some task that can only be done while standing near each other. Until now, we've been using badges, but not everyone wants them and many clients don't display them. We need some normalization on the "location" tag, so that the places named in different clients sorta match-up, and we can refer to regions and not just specific towns. I'm also missing the ability to generate an ical file, for people who want to save the meeting to their "normie" calendar; that might require additional tags/fields.

But, whatever, I'm probably boring you. None of this is something that's a problem with "Nostr", it's a problem with the NIP being too limited because there haven't been enough people using it to build real products and hold real events. So, let's just change that and get the spec straightened out. The calendar stuff has been half-asleep for too long, even though it's an obvious Core NIP. It's the only NIP that involves humans interacting in real time and meatspace. Different ballgame.

We'll have our people call your people. πŸ˜‰

πŸ‘€

Reply to this note

Please Login to reply.

Discussion

Yo, nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf is #Comingle down with a calendar shake-up?

Let’s goooo. I agree the Nostr calendar stuff has been half-asleep and it’s partially my fault for taking on too many priorities. Your write up makes sense to me in general.

Yup, it will!

But the spec is indeed not there yet.

I don't see co-hosting as an calendar event issue. It's a co-managing a #communikey issue.

If you can:

- delegate the nostr:npub1purpleye8gzrzss99nzqqnemtf7g8xxj8p950nkyknnuqzycuh5qnazkzp key signing

- specify more than one "host" / "organizer" npub

- have external logic work out events "by geographical zone"

Then what's the issue? I need more precise criticism, I think.

Well, we'd want that tech for the affirmations, so that two people could somehow sign the same event, saying that they'd met in person at XYZ event. Otherwise, you'd need a proposal event and a confirmation event, which is inefficient, or a wrapper, which is messy.

And co-hosting events can be generated by our shared nostr:nprofile1qyt8wumn8ghj7emjv4jkuum0w4kzuumsv93k2tcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7qpqpurpleye8gzrzss99nzqqnemtf7g8xxj8p950nkyknnuqzycuh5qd8v2p2 npub, but you don't actually know which of us wrote that (which is sometimes a feature, since we don't want to personalize everything). Would be neat, if the community npub generated the event containing the list of hosts, and each host signed it.

Also, would just be nifty, to find out if it's possible to have a multisig Nostr event. πŸ˜… Like, that would be cool, right?