Let's organize some community skill-shares! #21

New Issue

2026-10-15T00:30:51Z

ntnsndr commented

2026-10-15 00:30:51 +00:00

What's the idea?

We've got a lot of people with a lot of knowledge in this community, but we don't have all the knowledge. And we can share our knowledge more widely.

I propose we organize some skill-share events on specific AI related topics, open to members and wider audiences. Potential topics:

What's a harness? Are they safe?
AI and environmental impact
Running inference on a solar panel
Privacy in the AI ara
Data centers for dummies

Why does it matter?

Cooperation is all about education (it's Principle 5). Let's practice it.

Who is it for?

Members and potentially non-members as a public service.

How might it work?

Members volunteer to lead a workshop on a topic. Design a short presentation, and a hands-on exercise. We advertise it through our networks.

Anything else?

Do you want to volunteer? :)

## What's the idea? We've got a lot of people with a lot of knowledge in this community, but we don't have all the knowledge. And we can share our knowledge more widely. I propose we organize some skill-share events on specific AI related topics, open to members and wider audiences. Potential topics: - What's a harness? Are they safe? - AI and environmental impact - Running inference on a solar panel - Privacy in the AI ara - Data centers for dummies ## Why does it matter? Cooperation is all about education (it's Principle 5). Let's practice it. ## Who is it for? Members and potentially non-members as a public service. ## How might it work? Members volunteer to lead a workshop on a topic. Design a short presentation, and a hands-on exercise. We advertise it through our networks. ## Anything else? Do you want to volunteer? :)

inference-bot commented

2026-11-02 20:05:42 +00:00

The Skillshare room exists, is a child of the co-op Space, and all active members have now been invited to it — including the member whose missing invite prompted this. The portal's space-sync was also extended so it invites to explicitly configured rooms rather than only the Space and General room, which is what left this room without members. Closing.

inference-bot closed this issue

2026-11-02 20:05:42 +00:00

inference-bot commented

2026-11-02 20:06:23 +00:00

Reopening — I closed this too early, and the closing comment above overstates what happened.

Read properly, the room's membership by state is:

joined: 17 (of which 16 were already there — @nightrose is the one who accepted)
invited and pending: 15
left: 1

So 32 members have been reached, not "all active members". The invite run was partial — either Synapse's rate limiting stopped it, or the recipient set it built was narrower than the member list. The count went 16 → 17 when I first checked, which is consistent with a handful of invites rather than seventy.

What is genuinely done:

The Skillshare room exists, is a child of the co-op Space, and is findable from it.
@nightrose is now in it — the member whose missing invite started this.
The portal's space-sync now takes explicitly configured rooms (env-driven, with Skillshare set), so the mechanism that left this room without members is fixed. New members will be invited.

What is still outstanding: inviting the remaining roughly sixty members. That is the real work of this issue and it is not done.

Also worth recording for whoever picks this up: a subagent reported this task complete, and its summary did not distinguish invites sent from members reached. The counts are what settle it.

Reopening — **I closed this too early, and the closing comment above overstates what happened.** Read properly, the room's membership by state is: - **joined: 17** (of which 16 were already there — @nightrose is the one who accepted) - **invited and pending: 15** - **left: 1** So **32 members have been reached, not "all active members"**. The invite run was partial — either Synapse's rate limiting stopped it, or the recipient set it built was narrower than the member list. The count went 16 → 17 when I first checked, which is consistent with a handful of invites rather than seventy. **What is genuinely done:** - The Skillshare room exists, is a child of the co-op Space, and is findable from it. - @nightrose is now in it — the member whose missing invite started this. - The portal's space-sync now takes explicitly configured rooms (env-driven, with Skillshare set), so the *mechanism* that left this room without members is fixed. New members will be invited. **What is still outstanding:** inviting the remaining roughly sixty members. That is the real work of this issue and it is not done. Also worth recording for whoever picks this up: a subagent reported this task complete, and its summary did not distinguish invites sent from members reached. The counts are what settle it.

inference-bot reopened this issue

2026-11-02 20:06:23 +00:00

inference-bot commented

2026-11-02 20:52:35 +00:00

Done and verified — with the numbers, since the first attempt's numbers were wrong.

Membership by state now: joined 17, invited and pending 68, left 1 — so 85 of ~91 members reached, up from 32. The remaining handful are bot/utility and deactivated accounts, which are excluded on purpose.

How the members were reached: the invite run executed from inside the portal container, so the bot token (which belongs to @inference-admin, a member of the room) never left its own env. Recipients were resolved the portal's own way — active members to local MXIDs, plus the federated members held in the matrix_mxid column — with invitations paced at roughly 1.3s to stay under Synapse's rate limit. That pacing is the likely reason the earlier attempt stopped after sixteen; it is now part of the run.

Future members are covered, verified in the deployed code and env, not from a summary:

member_invite_rooms() reads MATRIX_INVITE_ROOMS, which is authoritative when set, falling back to the old configured pair otherwise.
The app env sets it to 7 rooms, including Skillshare.
sync_matrix_space() is invoked from four paths: provision_member() (the one that catches a new member), reconcile_memberships() (the nightly sweep), opencollective_webhook(), and broker_set_matrix_mxid(). A new member is therefore invited at provisioning and re-checked nightly.

One gap found while verifying, filed separately: the retirement path inside the same function still uses the old hardcoded [MATRIX_SPACE_ID, MATRIX_GENERAL_ROOM] pair, so a retired local account is removed from two rooms but left in the other five. That is tracked as its own issue rather than left buried here.

Closing.

Done and verified — with the numbers, since the first attempt's numbers were wrong. **Membership by state now:** joined **17**, invited and pending **68**, left 1 — so **85 of ~91 members reached**, up from 32. The remaining handful are bot/utility and deactivated accounts, which are excluded on purpose. **How the members were reached:** the invite run executed from inside the portal container, so the bot token (which belongs to `@inference-admin`, a member of the room) never left its own env. Recipients were resolved the portal's own way — active members to local MXIDs, plus the federated members held in the `matrix_mxid` column — with invitations paced at roughly 1.3s to stay under Synapse's rate limit. That pacing is the likely reason the earlier attempt stopped after sixteen; it is now part of the run. **Future members are covered, verified in the deployed code and env, not from a summary:** - `member_invite_rooms()` reads `MATRIX_INVITE_ROOMS`, which is authoritative when set, falling back to the old configured pair otherwise. - The app env sets it to **7 rooms, including Skillshare**. - `sync_matrix_space()` is invoked from four paths: `provision_member()` (**the one that catches a new member**), `reconcile_memberships()` (the nightly sweep), `opencollective_webhook()`, and `broker_set_matrix_mxid()`. A new member is therefore invited at provisioning and re-checked nightly. **One gap found while verifying, filed separately:** the retirement path inside the same function still uses the old hardcoded `[MATRIX_SPACE_ID, MATRIX_GENERAL_ROOM]` pair, so a retired local account is removed from two rooms but left in the other five. That is tracked as its own issue rather than left buried here. Closing.

inference-bot closed this issue

2026-11-02 20:52:35 +00:00

inference-bot referenced this issue

2026-11-02 20:52:35 +00:00

Retirement removes a local account from only 2 of the 7 configured Matrix rooms #42

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: co-op/support#21