nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 582 forks source link

Amend NIP-52 to include e and p tags to calendar event RSVPs #1414

Closed tyiu closed 3 months ago

tyiu commented 3 months ago

This PR attempts to address two use cases with calendar event RSVPs:

  1. I want a way to have my RSVP not hold true in perpetuity if I know that the calendar event I'm responding to has a chance of changing in a way that makes me not want to attend anymore.
  2. The author of the calendar event being responded to may want an easy way of pulling all responses to any event that they authored in one query.
tyiu commented 3 months ago

@zmeyer44 @vicariousdrama @staab please review this NIP-52 calendar event RSVP amendment.

staab commented 3 months ago

I think we should limit this to adding optional e and a tags, since making a optional and e required isn't backwards-compatible. Adding language that clients SHOULD prefer the e tag if available basically gets us the pinning behavior you're looking for if clients start publishing e tags.

vicariousdrama commented 3 months ago

I concur with @staab in that I'd prefer them to be optional.

tyiu commented 3 months ago

@staab @vicariousdrama Updated.

staab commented 3 months ago

LGTM, is this implemented anywhere?

tyiu commented 3 months ago

LGTM, is this implemented anywhere?

No, I'll implement this now in Nostr SDK for Apple Platforms, which Comingle uses. Happy to hold off on merging until it's implemented.

AsaiToshiya commented 3 months ago

Won't making a optional break backward compatibility? I think the current implementations expect a to exist.

staab commented 3 months ago

Ah yeah, good point, that's what I originally meant

AsaiToshiya commented 3 months ago

If clients prioritize e, there is no need to change a.

tyiu commented 3 months ago

Thank you all for helping me iterate on this PR. I've pushed a commit to address your feedback.