Schedule Adjustment with NIP-52

[studiokaiji]

NIP-52 specifications work well for events that have already been scheduled.

However, in reality, there are many situations where the schedule is not clearly decided and the schedule is decided based on the convenience of the participants (meetings, meal plans, etc.).

Therefore, I think that NIP-52 should be able to adjust the schedule.I suggest Adjust Schedule Event and Adjust Schedule Event RSVP.

Adjust Schedule Event does not have start and end tags. Instead, there is a tag called dates. It records the value of the date or timestamp connected from the beginning to the end with ~. There may be more than one value, which will be used as a suggestion for the date.

Adjust Schedule Event RSVP acts as a response to an Adjust Schedule Event. The Adjust Schedule Event identifier is recorded in the a tag, and attendance to the l tag is recorded for each value recorded in the dates tag, so there may be multiple values for the l tag.

Finally, the organizer aggregates these events, decides to hold the event on a date and time when the most users can attend, and creates a Calendar Event.

I'm currently designing an application that uses these events. I will add more information once the detailed event specifications are decided.

Thank you.

[staab]

Calendar events are already replaceable, so it seems like you could watch for changes and RSVP based on e tag? It would require relays serving all versions of an event like Will and Semisol mentioned, but I don't think this needs new kinds.

[studiokaiji]

Calendar events are already replaceable, so it seems like you could watch for changes and RSVP based on e tag? It would require relays serving all versions of an event like Will and Semisol mentioned, but I don't think this needs new kinds.

Is there a suitable way for an organizer to suggest multiple potential dates?

[staab]

I think that was out of scope for the current spec, but maybe you could create multiple draft events, and use a calendar to discuss them. The thing about interoperability is the spec has to gracefully degrade, so adding every possible feature isn't good.

[studiokaiji]

I think that was out of scope for the current spec, but maybe you could create multiple draft events, and use a calendar to discuss them. The thing about interoperability is the spec has to gracefully degrade, so adding every possible feature isn't good.

I think it's a good idea to use drafts of Calendar events for scheduling. In that case, you will need a new kind like kind: 30024 for kind: 30023, but the specification will not become any more complicated.

[studiokaiji]

Create a new kind as shown below.

• Draft Date-Based Calendar Event: 31926
• Draft Time-Based Calendar Event: 31927
• Draft Calendar: 31928

Regarding Calendar Event RSVP, we think that there is no need to create a new kind as it is an event that is handled incidentally to these events.

[studiokaiji]

It might be useful to have a kind that aggregates RSVPs for Calendar Events. (Like Calendar for Calendar Event) This kind allows you to efficiently obtain Calendar RSVPkind: 31925. Since RSVP events are created as many as the number of events defined in the Calendar, I believe that such a mechanism should exist. However, I don't know if this should be applied to non-Draft Calendar Events.

[ocknamo]

It might be useful to have a kind that aggregates RSVPs for Calendar Events. (Like Calendar for Calendar Event)

Calendar creators can create calendar event calendars. Also, since this is like a classification, it probably doesn't necessarily need to exist. On the other hand, RSVP can be created by anyone, so it means that "kind:31925" is created by the RSVP creator at the same time, right?

In my opinion, unless the presence of the "kind: 31925" event is guaranteed, client processing becomes inefficient as the client has to search for RSVPs that don't have it set. Also, it is difficult to guarantee the existence of events in relays.

[studiokaiji]

Calendar creators can create calendar event calendars. Also, since this is like a classification, it probably doesn't necessarily need to exist.

I'm thinking of it as an event created by participants, but you're right that it's not required.

In my opinion, unless the presence of the "kind: 31925" event is guaranteed, client processing becomes inefficient as the client has to search for RSVPs that don't have it set.

As for the RSVP event itself, even if the actual kind: 31925 event does not exist, it is possible to search efficiently as long as you have the ID, so I don't think there is a problem. It's no different from a normal Calendar event.

[ocknamo]

@studiokaiji Thanks, I think my understanding has improved somewhat. I thought that having two methods of collecting client RSVP would complicate the problem, but maybe I'm overthinking it. :smiley: