swicg / swicg/groups

Define group rules and code of conduct

Open
#33 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

user story
Dominant language
HTML
Stars
8
Forks
1
PR merge metrics
No merged PRs in 30d

Description

"As a fediverse user, I want to see a group's rules before joining or posting, so I know what behavior is expected."

Groups often have a code of conduct that users have to agree to before joining or participating. We propose standardising how rules are represented on Group actors for federation.

Existing approaches:

  • Lemmy: Exposes community rules simply as a part of the summary text on the Group
  • Mastodon: Instance-level rules are an array of objects with id and text

Suggested representation:

A rules property, supporting translations via the existing ActivityPub contentMap pattern:

{
  "type": "Group",
  "id": "https://example.org/groups/1",
  "rules": [
    {
      "mediaType": "text/html",
      "name": "Be respectful",
      "nameMap": {"fr": "Soyez respectueux"},
      "content": "<em>No personal attacks</em> or harassment.",
      "contentMap": {"fr": "Pas d'attaques personnelles ou de harcèlement."}
    },
    {
      "mediaType": "text/plain",
      "name": "Stay on topic",
      "nameMap": {"fr": "Restez dans le sujet"},
      "content": "Keep discussions related to the group's topic.",
      "contentMap": {"fr": "Gardez les discussions liées au sujet du groupe."}
    }
  ]
}

Translation pattern:

  • name / content - Default language text (based on the community's primary language)
  • nameMap / contentMap - Language-tagged alternatives (standard ActivityPub pattern, W3C Activity Streams *Map properties)
  • Instances should display the user's preferred language if available, falling back to the default

Backwards compatibility:

  • Implementations not understanding rules or the rule attachments simply ignore them
  • Rules don't affect protocol behavior - they're informational only
  • Existing summary field can include a link to a page that display the rules for simpler implementations

Open questions:

  • Should we use attachment or the like (reusing existing AP vocabulary) vs dedicated rules property (cleaner but new)?
  • Should rules be orderable (numbered)? Could use an OrderedCollection or just rely on array order
  • Should rules have categories or severity levels?
  • Should Flag activities reference which rule was violated?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing ActivityPub Group vocabulary and the W3C Activity Streams natural-language *Map properties linked in the issue. Compare the Lemmy and Mastodon approaches, then resolve the attachment-versus-dedicated-property, ordering, and categorization questions. Done means the rules representation and compatibility behavior are specified clearly enough for implementations to follow.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.