Draft for NIP-73 meetup communities

[BrightonBTC]

This is a draft proposal for Meetup style location based communities.

For a working example this is currently implemented at https://www.inmytown.social/ (https://github.com/BrightonBTC/inmytown.social).

The idea is to have communities similar to those on Meetup .com, and introduces 3 new kinds to achieve this. One for community creation, One for community metadata, and one for community follow lists. The rest of the functionality is provided by existing NIPs. NIP-52 for location and time based meetup events, NIP-28 for community chat, and NIP-51 person lists to manage membership.

[BrightonBTC]

I'm aware that using list events was discussed and rejected in the NIP-72 proposal due to the large size of those kinds of communities. Meetup communities don't suffer from that same issue. On meetup larger communities tend to be only a few hundred members, with only a few that stand out and go up in to the thousands, so I'm of the opinion that it's an appropriate approach to use here.

[vitorpamplona]

This feels closer to NIP53-Live Activities (which also includes chats and calendar-based schedules) than to NIP-72

PS: Live Activities are not for Live Streams only, it's for any event that can be broadcasted as "happening now" in people's clients.

[BrightonBTC]

This feels closer to NIP53-Live Activities (which also includes chats and calendar-based schedules) than to NIP-72

PS: Live Activities are not for Live Streams only, it's for any event that can be broadcasted as "happening now" in people's clients.

Oh, OK I'll check that out. I had thought that was for live streams only.

[BrightonBTC]

This feels closer to NIP53-Live Activities (which also includes chats and calendar-based schedules) than to NIP-72

PS: Live Activities are not for Live Streams only, it's for any event that can be broadcasted as "happening now" in people's clients.

Did you mean closer to NIP-53 than NIP-52 ?

I'm not sure I agree. Calendar events feel more appropriate here to me. If I sign up to a meetup group on meetup.com or similar then I'm not too interested in what's "happening now", I want to see upcoming events, be able to add them to my calendar, and be able to send an RSVP.

[staab]

I would really like to try to avoid re-specifying all functionality in different NIPs. Community name, moderation, and privacy should all be separate things that can be combined, and there should be a way to use any event in context of a community. I like the k tag suggestion in #753 as a way of generically doing anything in context of a community.

[staab]

alt might be a more standard way to do this

[AsaiToshiya]

What is the reason for separating creation and metadata? I think just kind: 30037 is enough like NIP-53 and NIP-72. Other events can refer to it with a tag.

[BrightonBTC]

What is the reason for separating creation and metadata? I think just kind: 30037 is enough like NIP-53 and NIP-72. Other events can refer to it with a tag.

I had considered that approach but decided against it for a couple of reasons, primarily because I wanted to be able to know and display the creation date of communities. Having a creation event makes that simple.

[AsaiToshiya]

Thanks for your answer. It makes sense, but you can also use published_at tag in NIP-23 for the creation date.

[BrightonBTC]

Thanks for your answer. It makes sense, but you can also use published_at tag in NIP-23 for the creation date.

Yeah, you're right, it could go as a separate tag as with NIP-23. My one concern here - and I suppose it also applies to NIP-23 - is that it's more open to manipulation. ie. it would be trivial for a community organiser to back date their creation date in an attempt to boost credibility (I know that creation dates on events also can't be 100% trusted but IIRC most relays at least check they fall within some reasonable time frame).

I'm not overly concerned about any of this though and am happy to change it if there's some general consensus it's a better approach.