Group Communication and Participation Sessions
EarthCoop groups provide a shared communication/feed surface for members, but participation is controlled by the current group, role, session and domain rules. A member being able to see a group does not mean they automatically have the right to post in every context.
Group communication
Current group services support live group activity and event publication. Communication belongs to the group context and is connected to the member's canonical group role.
The exact controls shown in the interface can evolve. This guide therefore documents the stable participation contract rather than treating old UI details—such as a fixed reaction set, exact attachment limits, one transport protocol, or one search/filter layout—as permanent product guarantees.
Roles and posting rights
Posting and participation rights depend on the member's current role and the group's active participation state.
- Active members can participate according to the current group rules at the relevant local/base level.
- Observer membership does not automatically create a direct posting right in every higher-level group.
- Inspector and Manager responsibilities include the leader-level access defined by the current group/session contract.
- Temporary Active can enable limited participation where the current rules permit it, but this role is not equivalent to Active for systemic-election eligibility.
- Guest access, where used, remains limited by the applicable membership/product flow.
Participation sessions
EarthCoop also has a formal group-session model. A session can be scheduled, started, active, and ended. Starting a new session closes/replaces any earlier active session for that group and resets temporary participation state that must not leak from one meeting into another.
During an active session, temporary write permission can be granted under the session participation rules. That permission is intentionally temporary.
When the session ends:
- the session becomes ended;
- temporary participation permissions for non-leader members are cleared;
- pending participation requests are resolved/expired by the session boundary;
- leader access remains based on the member's actual role rather than a temporary session flag.
This prevents a one-meeting participation grant from silently becoming a permanent role change.
Higher-level observation and participation
For system groups, higher-level membership may be observational. Where a member needs to participate in a structured higher-level meeting, the current session/participation mechanism can govern that temporary access without converting the member's canonical Observer role into Active membership.
That distinction is important for governance integrity: temporary speaking/writing access is not the same as official role or election eligibility.
Group events and updates
Session state changes are published to the group event/feed infrastructure. This supports synchronized group activity without making documentation promises about one specific client transport implementation.
The product may use different delivery mechanisms as the web/mobile architecture evolves. The stable contract is the event/state change, not a promise that every client always uses a particular WebSocket or polling implementation.
Najm Hoda and meeting records
Current session services can trigger Najm Hoda meeting-minutes draft generation when sessions end. A generated draft is an assistance artifact, not an autonomous legal decision or a replacement for the group's official decision record.
Moderation and additional UI features
Message moderation, attachments, replies, reactions, search, pinning, audio and other feed features should be documented as current only when their current UI/service contract has been separately verified. Older documentation included many precise limits and interface steps that were not all re-established by this audit, so those claims are intentionally not repeated here.
This conservative wording is deliberate: EarthCoop documentation should describe verified behavior, not preserve a precise legacy UI claim merely because it appeared in an earlier guide.