FEP-1cbd: Event Attendance and Attendee Collections

Standards Fediverse Enhancement Proposals
,
1

It been some time: in the 2026 FOSDEM it has been decided to move attendance out of FEP-8a8e. Here is the first draft, that also tries to solve all issues that have been pointed out meanwhile.

FEP-1cbd: Event Attendance and Attendee Collections

Summary

Events are all about people, people coming together, people being there. There are many ways in which events are organized, and many ways in which we share expectations about who is going to come or who has been invited. This document provides guidance on handling attendees in the context of a digital social network. The goal is to minimize the number of expectations broken and to avoid abusive behavior.

[!NOTE] Non-goals: This FEP does not cover attendance status, such as not attending or possibly attending. It also does not specify a mechanism for publicly exposing candidates on a waiting list. Furthermore, bringing guests in an attendance is also not covered.

Requirements and wording

This FEP leans on the word ‘attend’ rather than ‘participate’, as ‘attend’ has a broader meaning that encompasses ‘participate’, which tends to emphasize active involvement.

The FEP is not tied to the Event object, but primary designed for its use-case. Thus in the following event refers to all objects that might implement attendance.

In the following, the actor’s own activity, that is the Accept of an Invite or the Join, as described in section “Flow” below is called the attendance activity.

Properties that have no context prefix are to be interpreted as being in the https://www.w3.org/ns/activitystreams context.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in RFC-2119.

Not managing attendees in ActivityPub

For an event, the primary goal of a social application might be to communicate about it. At the same time, managing its attendees in the same place might not be wanted.

  • Not managing attendees at all: If an event does not manage attendees at all this MUST be indicated by using the joinMode property and set it to none.
  • Managing attendees externally: If an application does not handle attendees of an event via ActivityPub, but knows of an external URL which handles the attendee management joinMode MUST be set to external. In that case also externalParticipationUrl SHOULD be set.

Managing attendees

[!NOTE] The following sections are inspired by FEP-7aa9, FEP-044f and the interaction controls of GoToSocial.

Flow of attendance

This section is non-normative

There are two general flows for becoming an event attendee in today’s ActivityPub implementations.

  1. Invite: An Invite with an event as the object is sent to invited Actors. The invited person becomes an attendee by responding with an Accept activity.

  2. Join: An event is discovered, e.g. when receiving a Create or Announce for it. An interested attendee sends a Join activity to the owner of the event, specifying the event as object. The owner responds with an Accept activity.

Signaling the policy to attend an Event via ActivityPub

Each event MUST advertise an interactionPolicy with a canAttend sub-policy. This sub-policy may contain the following properties:

  1. automaticApproval: an array of Actor and Collection of Actor objects from whom interactions are expected to be automatically approved
  2. manualApproval: an array of Actor and Collection of Actor objects from whom interactions are subject to manual review
  3. requiredAudience an array of Actor and Collection of Actor objects which reflect the required target audience of the interaction.

Note that the policy is entirely advisory. It SHOULD be used to provide user interface hints such as enabling a “Join” button or explaining why an event cannot be joined, but it MUST NOT be used to verify whether a join is valid. If this policy is missing or has no requiredAudience set, the minimum required audience falls back and SHOULD expected to be the actor in the attributedTo of the object that gets attended.

{
  "@context": [
    "https://w3id.org/fep/1cbd",
    "https://gotosocial.org/ns",
    "https://www.w3.org/ns/activitystreams"
  ],
  "interactionPolicy": {
    "canAttend": {
      "automaticApproval": "https://example.com/users/alice/followers",
      "manualApproval": ["as:Public"],
      "requiredAudience": ["as:Public"]
    }
  },
  "type": "Event",
  "id": "https://example.com/events/1",
  "attributedTo": "https://example.com/users/alice",
  "to": "https://www.w3.org/ns/activitystreams#Public",
  "startTime": "2014-12-31T23:00:00+01:00",
  "name": "Party"
}

Signaling and proofing attendance

The attendance activity SHOULD include an AttendanceAuthorization as its result. It MUST do so if the attendee’s actor and the event do not share the same origin.

The attendance activity MUST be addressed at least to the requiredAudience of the event’s canAttend policy, or to the actor in attributedTo if there is none. It MAY be addressed to a wider audience, for example the attendee’s followers or Public.

The AttendanceAuthorization MUST be dereferenceable by every actor in the audience of the attendance activity. This way, everyone who is shown an attendee can verify that the attendee consented to being listed.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://gotosocial.org/ns",
    "https://w3id.org/fep/1cbd"
  ],
  "type": "AttendanceAuthorization",
  "id": "https://example.org/users/bob/stamps/1024",
  "interactingObject": "https://remote.example/events/new-years-party",
  "interactionTarget": "https://example.org/users/bob"
}

Maximum attendance capacity

In case an event has a maximum number of potential attendees this SHOULD indicated via maximumAttendeeCapacity.

Remaining attendee capacity SHOULD be shown via an remainingAttendeeCapacity on the event.

[!WARNING] Using the `totalItems` count of the attendees collection might not take into account future extensions like an attendance being able to bring guests.

Attendees Collection

The list of all attendees of an event SHOULD be given via an attendees property. This contains an AttendeesCollection.

The individual items in the AttendeesCollection are of the type Attendance which is a subtype of Object. The collection, especially it’s items, MUST be filtered in accordance to the delivered audience.

Attendance objects

An Attendance object

  • MUST have the attendingObject property set. That is the id (URI) of the actual object that is attending.
  • where the attending object is an actor and an proof-stamp is available MUST also include the attendanceAuthorization property, which is the URI of the approval object.
  • MUST share the same audience with the activity that indicated the attendance and an optional attendance authorization.
  • MAY include an published property containing the date and time at which the object was added to the collection.
{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/fep/1cbd"
  ],
  "type": "AttendeesCollection",
  "id": "https://example.org/events/new-years-party/attendees",
  "totalItems": 2,
  "items": [
    {
      "type": "Attendance",
      "id": "https://example.org/events/new-years-party/attendees/7",
      "attendingObject": "https://remote.example/users/bob",
      "attendanceAuthorization": "https://remote.example/stamps/1024",
      "published": "2026-11-01T10:00:00Z"
    },
    {
      "type": "Attendance",
      "id": "https://example.org/events/new-years-party/attendees/8",
      "attendingObject": "https://example.org/users/carol",
      "published": "2026-11-02T08:30:00Z"
    }
  ]
}

Behaviour and side-effects

An update of an event MUST be delivered to all items of an AttendeesCollection where the attendingObject is an actor.

Items MUST be added to the attendees collection when

  • an actors that sent a Join activity targeting the event has been answered with an Accept.
  • The actors that responded to an Invite activity (where the event is specified in the object property) from the events owner or attributed organizers with an corresponding Accept activity.
  • Attendances are added via non-ActivityPub mechanisms, e.g. when an application allows for attendees to register by e-mail. In that case using the vocabulary of https://schema.org/ is RECOMMENDED.

Actor’s MUST be able to undo becoming an attendee of an event. In that case

  • the actor MUST issue an Undo activity of the activity that issued becomming an attendee.
  • the actor MUST issue an Delete activity with the AttendanceAuthorization as object if it exists.
  • the owner of the event MUST remove the actor from the attendees collection.

Federating changes and opportunistic updating

This section is non-normative.

When an Attendee is added to or removed from the attendees collection, the host of the event MAY send an Add or Remove activity.

Since a server can never know exactly who has discovered an event, it can only guess who to notify. A reasonable heuristic is to send these activities to the attributed organizers, the actors in the attendees collection, and the followers of the attributedTo actor, but never to anyone outside the audience allowed to see the entry.

No heuristic is perfect, so implementations are encouraged to re-fetch the attendees collection from time to time. Receivers should treat Add and Remove as hints, accept them only from the event’s host, and consider the host’s collection authoritative.

Waiting List

If an Actor cannot become an attendee, because the event is full, the request SHOULD be responded with a Reject activity, unless the application implements a waiting list feature. In this case, the response SHOULD be a TentativeReject where the result contains a dereferenceable WaitingListItem.

Its waitingListPosition is the 1-based number of people ahead of the actor plus one, as of the time the item was served. It is informational only: it MAY change when other entries leave or are promoted, and it MUST NOT be treated as a guarantee of admission.

{
  "@context": [
    "https://schema.org",
    "https://w3id.org/fep/1cbd",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "WaitingListItem",
  "id": "https://example.com/event/1/waiting-list/4",
  "object": "https://example.com/actor/1",
  "target": "https://example.com/event/1",
  "waitingListPosition": 3
}

Verification

The AttendanceAuthorization obtained through the result of attending activity serves as an “approval stamp”, an object that can be used to verify that approval to be included in an attendee collection was given.

An AttendanceAuthorization MUST include the following properties:

  • type: The type of object, MUST be AttendanceAuthorization
  • id: URI that uniquely identifies this object
  • interactingObject: The event that is attended.
  • interactionTarget: The actor that attended.
{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://gotosocial.org/ns",
    "https://w3id.org/fep/1cbd"
  ],
  "id": "https://other.example.com/users/bob/stamps/1024",
  "type": "AttendanceAuthorization",
  "interactingObject": "https://fedi.example.com/events/party",
  "interactionTarget": "https://other.example.com/users/bob"
}

When processing a AttendeesCollection from a remote server the AttendanceAuthorization of every Attendance where the attending actor does not share the remote servers host MUST be validated. If it is missing, cannot be resolved, or the hosting service does not match the actor’s the item MUST be ignored or removed from the collection before it is being displayed to users.

Appendix

The following sections are non-normative

This section only holds considerationg, or ideas for future FEPs and implementations.

Appendix A: Related specifications

Other specifications like

have been considered, but those seem to focus on private/business meeting contexts rather than public events. That is why little of their vocabulary is used.

Appendix B: Attendance Mode

To signal whether the events attendance is offline, online or mixed the property eventAttendanceMode should be considered. Utilizing a single location property in the attending activity, the Attendance and AttandanceAuthorization might be an option. Indicating the maximum capacity might be done via maximumPhysicalAttendeeCapacity or maximumVirtualAttendeeCapacity.

Appendix C: Waiting list prompotion

When promoting an attendee from waiting list there are multiple flows possible, e.g.

  • Automatic promotion.
  • Sending an Invite to the attendee candidate with an endTime specified.

References

Copyright

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.

Events Interoperability: Validation, minimum requirements, common extensions
2

This FEP has the same problem as FEP-044f, FEP-7aa9 and other similar proposals: misused activity names. Accept and Reject belong to the "Follow" flow, and the proposed activities are indistinguishable from them. Also, Invite conflicts with prior usage in FEP-bebd: Follow Invites.

Consider changing the names:

- Invite -> InviteAttendee
- Accept -> AcceptInviteAttendee
- Reject -> RejectInviteAttendee
- Join -> JoinEvent
- etc