Skip to content

Instantly share code, notes, and snippets.

@brennanMKE

brennanMKE/README.md

Created October 2, 2023 22:37
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save brennanMKE/67cc9b6d74f31f1606e093431390e637 to your computer and use it in GitHub Desktop.
Save brennanMKE/67cc9b6d74f31f1606e093431390e637 to your computer and use it in GitHub Desktop.
Download ZIP
Groups with ActivityPub
Raw
README.md

Groups with ActivityPub

Prompt:

I'd like to create a groups implementation using ActivityPub which allows members to join groups to share posts only members of the group can see and reply to. I also want to support photo albums and events with RSVP lists. Can this be implemented within the ActivityPub protocol using Activity Streams and Actors?

Response:

Yes, you can implement this functionality using the ActivityPub protocol with Activity Streams and Actors. The protocol is highly flexible and supports a wide variety of use cases, including the ones you've mentioned. Let's break down the process for each of the features you've listed:

  1. Groups Implementation:

    • Actors: Groups can be modeled as Actors, similar to how individual users are modeled. An Actor for a group might have its own inbox, outbox, followers, and following collections.

    • Joining: To join a group, a user's Actor sends a Join activity to the group's inbox. The group can then add this user to its followers collection, representing the group's membership.

    • Posting to Groups: When a user posts to a group, they can send a Create activity with their content to the group's inbox. The group's server can then relay this post to all members (followers) of the group.

  2. Visibility to Group Members:

    • Audience Targeting: When a post is created for the group, you can use the to field in the Activity Streams object to specify the intended audience. If the post should only be visible to group members, set the to field to the group's Actor ID.

  3. Photo Albums:

    • Collection: You can model a photo album as a Collection in Activity Streams. Each photo can be an Image object within this collection.

    • Creation & Addition: When a user uploads a photo to the album, send a Create activity for the Image and then an Add activity to insert the Image into the album's Collection.

  4. Events with RSVP:

    • Events: Model events as Event objects in Activity Streams. Attributes like location, start time, end time, etc., can be a part of this object.

    • RSVP: Activity Streams has an Accept and Reject type which can be used for RSVPing. When a user wants to RSVP to an event, they send an Accept or Reject activity targeted at the Event object. The server managing the event can then maintain a list of attendees or those who declined.

Some implementation notes:

  • ActivityPub's flexibility means there are often multiple ways to model or achieve certain functionality. You might need to adapt the above suggestions to your specific requirements and constraints.

  • Privacy is a significant concern. Ensure that the servers handling these activities respect the intended audiences. For example, when a post is meant only for group members, ensure it's not broadcasted to non-members or public inboxes.

  • Consider using existing ActivityPub server software as a starting point and then extending them to support your features. This approach can save you time and ensure compatibility with the wider ActivityPub ecosystem.

  • Thoroughly test your implementation for any edge cases and ensure it's interoperable with other ActivityPub implementations. There are test suites and tools available in the community to assist with this.

By combining the flexible structures provided by Activity Streams with the federated messaging capabilities of ActivityPub, you should be able to realize the functionality you've described.

Prompt

For these groups I want to assign admins and moderators. I assume these also would be actors in the ActivityPub specification. Any member of a group should be able to flag anything on the Activity Stream for admins and moderators to act on. How would they have the ability to respond to user reported flags and act on them by hiding or removing the activity? How would members of the group be muted for a limited time? And how would members of a group be removed by admins or moderators?

Response

Absolutely! Admins and moderators can indeed be represented as specific types of actors, or they could be standard user actors with additional privileges assigned within the system you're building. Here's a proposed approach to implement the functionalities you mentioned:

  1. Admins and Moderators:

    • Actors: You don't necessarily need to create a separate type of actor for admins and moderators. Instead, within your group's data model, you can maintain lists of actor IDs with administrative or moderation privileges.

    • Privileges: Depending on your application, you might have different levels of privileges, like "admin", "moderator", etc. When an activity is directed to a group (e.g., a post, flag, etc.), the server processing that activity can check the privileges of the originating actor and decide how to proceed.

  2. Flagging Activities:

    • Report Activity: You can create a custom activity, say Report, which members can use to flag any content in the activity stream. The Report activity could have a reference to the offending activity and an optional note explaining the issue.

    • Review Queue: When a Report activity is received, it can be placed in a "review queue" that's accessible only to admins and moderators. They can review these flagged items and decide what action to take.

  3. Acting on Flagged Activities:

    • Hide Activity: If a moderator decides to hide a flagged activity, they can send an Undo activity for the original Create activity. This will signal to servers (and by extension, clients) that the original content should no longer be displayed. However, note that not all servers or clients might respect this, so your server should also enforce this hiding when serving content.

    • Remove Activity: A stronger action would be to delete the activity entirely. This can be signaled with a Delete activity. Again, be mindful of the federated nature of ActivityPub, where not all servers might act on or respect this.

  4. Muting Members:

    • Mute Activity: You can define a custom activity, say Mute, which a moderator or admin can send targeting a member's actor. The Mute activity could have a duration field specifying how long the mute lasts.

    • Server-side Enforcement: Upon receiving a Mute activity, the server should make a note not to process or propagate activities from the muted actor for the specified duration.

  5. Removing Members:

    • Leave Activity: To remove a member, an admin or moderator can send a Leave activity on behalf of the user, essentially indicating that the user has left the group.

    • Block Activity: For a more forceful removal, consider using a Block activity from the group to the user. This indicates that the group no longer wishes to interact with this user. The server should then stop processing activities from this user directed at the group.

Remember:

  • The federated nature of ActivityPub means that while you can control behavior on your server, you can't always control how other servers or clients behave. It's essential to handle edge cases and potentially non-compliant actors gracefully.

  • The flexibility of ActivityPub allows you to define custom activities, so if the standard set of activities doesn't meet your needs, you can always extend it. However, be mindful of interoperability if you plan to interact with other ActivityPub implementations.

  • Ensure that any moderation actions are transparent, fair, and in line with the guidelines or terms of service for your platform. This will help in building trust within your user community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment