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:
- 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?
- 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.
- 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
Discovery
OpenMeet already has a full group management system with:
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:
Possible architecture
This would mean community-admin is a thin config layer on top of OpenMeet groups, not a standalone community system.
Action items
Related