[NIP 53 Addendum] - Add Interactive Rooms, Meetings, and Live Presence.

[bitkarrot]

This is a proposal to add Interactive Rooms and Meetings, and Live presence to NIP-53.

• Kind 30312 (Interactive Rooms)
• Kind 30313 (Meetings)
• Kind 10312 (Room Presence)

These Kinds would apply to interactive audio/video platforms such as Hivetalk version 2.0 (not public yet) and Nostr Nests.

See original discussion on gist

@vitorpamplona @hzrd149 @fiatjaf @v0l

[vitorpamplona]

Looks great! How many implementations do we have?

[staab]

A few things:

• I don't understand the difference between an interactive room and a conference room
• A lot of the moderation stuff reminds me of NIP 72, which is dead/dying (for reasons other than the data format). You might consider omitting admin/host stuff from this NIP and rely on something like NIP 29 to manage permissions (which handle nested rooms, read/write permissions, etc) if it fits your use case.
• Events already exist in NIP 52. Adding new kinds isn't necessarily a bad thing, and probably makes sense in this context, but see if you can use the same conventions as NIP 52 (start vs starts for example).

[bitkarrot]

Looks great! How many implementations do we have?

We are in process with hivetalk beta (not public), with how it is defined currently as is, and a small tweak to nests. I believe @hzrd149 is looking into doing it for nostrudel, so when its in, that would make 3.

[derekross]

• Events already exist in NIP 52. Adding new kinds isn't necessarily a bad thing, and probably makes sense in this context, but see if you can use the same conventions as NIP 52 (start vs starts for example).

Events in NIP-53 (start and stop times) at this current time already exist. I don't believe this changes that aspect of the event.

[jeremyd]

• I don't understand the difference between an interactive room and a conference room

?? naming confusion, is why the name is like this.. the word "event" is too overloaded in nostr nip draft world.

• A lot of the moderation stuff reminds me of NIP 72, which is dead/dying (for reasons other than the data format). You might consider omitting admin/host stuff from this NIP and rely on something like NIP 29 to manage permissions (which handle nested rooms, read/write permissions, etc) if it fits your use case.

NIP29 can't really help with this, do we expect all streaming platforms to use NIP29 groups? probably not.. The event's important fields are the owner/moderators. This signals to the nostr application who is 'in-charge' in a simple, straight forward way. Nostr apps can leverage any permissions solution they want, whether it's a NIP29 group or some other method.

• Events already exist in NIP 52. Adding new kinds isn't necessarily a bad thing, and probably makes sense in this context, but see if you can use the same conventions as NIP 52 (start vs starts for example).

Looked at NIP52, I guess the question you're asking is do we keep the same convention as exists now in NIP53 or modify the tag name to match NIP52. Backwards compat might lean toward keeping the same tag name as before (which is what this draft does).

[staab]

naming confusion, is why the name is like this.. the word "event" is too overloaded in nostr nip draft world.

I would just suggest adding an explanation to each that explains the use case for two separate kinds.

NIP29 can't really help with this

NIP 29 is a confusing term, but what I mean is using the host relay to implement moderation via AUTH or whatever other policies it wants to do. It has its own tradeoffs, but doing everything client side is complex and quite rigid, which can lead to the inability to fix things down the road.

Backwards compat

Gotcha, didn't realize this was already in production. Don't mind me.