Feature Proposal: Timestamp-Based Membership Revocation in Group Access Control

[gdorsi]

Summary

Introduce support for timestamp-based revocation in group membership management to enable both backdated and forward-dated removals. This feature enhances security and moderation capabilities by allowing group administrators to retroactively or preemptively manage write access to shared feeds.

---

Problem

In systems where group members have write access to shared feeds or documents, it is possible for a member to abuse their access (e.g., through spam or denial-of-service content). Currently, revoking access is forward-looking, which means any prior malicious activity remains part of the group history and continues to propagate to peers.

There is a need for:

1. Backdated revocation: Remove a user’s access as of a specified time, preventing past commits from being considered valid.
2. Forward-dated revocation: Schedule revocations in advance, enabling expiring invitations or temporary access.

---

Proposed Solution

Extend the Group.removeMember method to accept an optional since timestamp parameter:

group.removeMember(member, { since: timestamp });

• Backdated Revocation: When since is set to a time in the past (after the member joined), all commits made by the member after that time will be ignored during sync or document validation.

• Forward-Dated Revocation: When since is set to a time in the future, the member retains access until that time is reached.

---

Validation Rules

• The since timestamp must not precede the member's join time.

• If it does, two options are being considered:

  • Strict Mode: Reject the operation and return an error indicating the valid range, including the member’s join timestamp.
  • Lenient Mode: Automatically clamp the since value to the member’s join time to avoid unnecessary errors and reduce implementation complexity for users.

The preference between these modes remains a design decision; one approach favors explicit feedback, while the other prioritizes ergonomic defaults.

---

Additional Considerations

• In the future, authenticated sync mechanisms will make this approach more robust, reducing the potential for malicious manipulation.
• A convenience API could be introduced to simplify use:

const membership = member.getMembership(group);
group.removeMember(member, { since: membership.joinedAt });

This helps developers avoid managing timestamps manually.

[joeinnes]

Additional Consideration: we might need to look at how we handle CoValues which have updates which have causal dependencies on the content which gets revoked (e.g. CoTexts where legitimate operations depend on a position index which may change if we revoke spam updates).

It may be that revoked updates need to be kept in state for positioning/causality.

[zicklag]

It may be that revoked updates need to be kept in state for positioning/causality.

Alternatively I could imagine that commits depending causally on the revoked commits might just be discarded along with the revoked ones. It seems like the choice between what makes more sense is app / use-case dependent.