Skip to content

Consider OpenMeet groups as shared community layer instead of building our own #11

@zhiganov

Description

@zhiganov

Discovery

OpenMeet already has a full group management system with:

  • Group CRUD (create, join, leave, manage)
  • "Groups you organize" / "Groups you're part of" on their dashboard
  • ATProto DID-based membership (group-did-follow)
  • API endpoints (src/group/group.controller.ts)

This is essentially what community-admin V1 is designed to build — community registration, membership, organizer roles.

Impact on roadmap

Before building community-admin's own community/membership system (V1), we should evaluate:

  1. Can OpenMeet groups serve as the community layer? If users create groups on OpenMeet, can Avails/scenius-digest/my-community read those groups via API?
  2. What's missing? OpenMeet groups likely don't have Telegram channel mappings, event source configs (Luma/guild.host), or link collection topics. Those are Citizen Infra-specific concerns.
  3. Hybrid approach? OpenMeet handles identity + membership + events. Community-admin adds the Citizen Infra-specific config (Telegram, link digests, event sources) on top of OpenMeet groups.

Possible architecture

OpenMeet Groups (ATProto-native)
  = identity, membership, events, RSVPs
  
community-admin (Citizen Infra layer)
  = Telegram config (group_id, topics, output_channel)
  = Link digest config (which topics to monitor)
  = Event source config (Luma, guild.host)
  = references OpenMeet group by DID/slug

This would mean community-admin is a thin config layer on top of OpenMeet groups, not a standalone community system.

Action items

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions