Events Interoperability: Validation, minimum requirements, common extensions

FEP-c7d3 is a work in progress, and it will probably move away from relying on attributedTo for authentication. But there might be other reasons to put a single actor there. For example, which actor should be in actor field of Offer activity? I think it should match Event.attributedTo.

I think signed Accept(Offer) activity can be used as a proof. You can attach a collection of those to your Event as Event.organizersAccepted, and everyone who views the Event will be able to verify that specified organizers are consenting.

Alternatively, Event.organizersAccepted may contain only activity IDs to be fetched. In this case Accept activities don’t need to be signed.

1 Like

Do i see that right, nobody really talked about addressCountry like that?

The spec says:

The country. Recommended to be in 2-letter ISO 3166-1 alpha-2 format, for example ā€œUSā€. For backward compatibility, a 3-letter ISO 3166-1 alpha-3 country code such as ā€œSGPā€ or a full country name such as ā€œSingaporeā€ can also be used.

I am of the opinion that this should also be mentioned in the fep !

1 Like

Rather than creating a new schema, this specification adopts the location property from Schema.org with some adjustments to better suite federated event handling

I noticed that you refer to schema-org location instead of as:location. Is that intentional?

It’s not. Thanks for pointing that out. I will rewrite it more clearly. What I meant to specify is that twithin he as:location properties from sc:location are used. Note that for example the eventStatus is now defined in the FEP directly, because of the missing Tentative status of the schema.org one.

1 Like

Hi, I’ve been following the FEP-8a8e effort with great interest. I’m pretty new to the implementing side of ActivityPub but consider myself knowledgeable in the problem space of regional calendar platforms.

In the past days after learning about FEP-8a8e I got two ideas stuck in my head that I’d like to work on, so I’m first asking for feedback:

Online validator for FEP-8a8e compliance on Event objects

A website that helps implementors to make their ActivityPub implementation compliant. Given an URL of an Event object you’d get

  • a user-facing visual presentation of the Event object
  • a raw JSON blob where each attribute is annotated with comments about standard compliance
  • general info about the standardisation effort, list of compliant implementations like Wordpress plugins etc.

Web component to render a FEP-8a8e Event object

Rendering good event tiles is surprisingly difficult, think e.g. multi-day events or edge cases for event locations. Maybe building Fediverse apps that display Events could be made easier for everybody by implementing a Web Component that

  • ingests compliant Event objects and validates them
  • is configurable to fit all kinds of display sizes and use cases. Think tiny thumbnails, event widgets in a timeline, screen-filling displays that also render content etc.
  • tries to be as unopiniatedā„¢ as possible

Applications that would utilise this Web Component could then make use of the ActivityPub client-to-server specification to fetch Events without the necessity to translate them into some special client-facing representation as e.g. Mobilizon does with its GraphQL API.


That being said I should note that I’m pretty much limited to work on weekends and would currently try to get into this with only one other friend.

Besides your general ideas on this, I’d like to know wether there are already plans to provide a reference validator for this standard? Validation with meaningful annotations would be vital for both these ideas and it would probably be best to not have to start from scratch here. As I’m generally interested in validating objects in the Web environment, I’d need an implementation that either targets JS or WASM.

Looking forward to read what you think, also feel free to contact me on @erictapen@chaos.social

3 Likes

Providing such a reference validator/display is indeed on my current to-do-list. Do you have made any efforts in this direction so far, or want to join the effort and help out? Regarding the web-component, I don’t have a strong opinion, but I guess I would have to see a real-world use-case first.

1 Like

Providing such a reference validator/display is indeed on my current to-do-list.

Happy to hear that :slight_smile:
I already put some effort into the validator, but I realised that I need to give the rule engine for the validation one more overhaul.

I just hastily published my current state here, with an online demo here. I prioritised showing the basic workflow over implementing any correct rules from the FEP, so the annotations it currently provides are useless.

There is little documentation about the code yet, but already quite the reliable test set. At the heart of the validator stands a list of rules, that each express certain requirements and also provide test cases for the validation. See this example for validating the timezone property:

  {
    name: "timezone attribute",
    validate: (self) => {
      if (self["timezone"] === null) {
        return {
          "timezone": {
            kind: "Violation",
            id: "NoTimezoneSet",
            text: "The timezone property is either null or doesn't exist",
            reference: null,
          },
        };
      } else if (typeof self["timezone"] !== "string") {
        return {
          "timezone": {
            kind: "Violation",
            id: "InvalidTimezone",
            text: `The timezone {self["timezone"]} is not a string`,
            reference:
              "https://codeberg.org/fediverse/fep/src/branch/main/fep/8a8e/fep-8a8e.md#time-zone",
          },
        };
      } else if (legalTimeZones.includes(self["timezone"])) {
        return {
          "timezone": {
            kind: "Warning",
            id: "InvalidTimezone",
            text: `The timezone {self["timezone"]} is not a valid timezone`,
            reference:
              "https://codeberg.org/fediverse/fep/src/branch/main/fep/8a8e/fep-8a8e.md#time-zone",
          },
        };
      } else {
        return {
          "timezone": {
            kind: "Correct",
            id: null,
            reference: null,
            text: "Valid timezone",
          },
        };
      }
    },
    tests: [{
      value: { timezone: null },
      result: { timezone: "NoTimezoneSet" },
    }, {
      value: {},
      result: { timezone: "InvalidTimezone" },
    }],
  },
1 Like

What about all day events like holidays, birthdays, etc. which probably should not be timezone-adjusted. AFAIK Friendica uses the dfrn:adjust field for this. Is there any plans to include handling of those in FEP-8a8e?

I made a note about all-day events after having a lovely and detailed exchange with people from friendica: #8 - FEP-8a8e: "All-Day"-Events - linos/fep - Codeberg.org

Note that there are also many other concrete issues that need to be addressed before the FEP can be finalized: Issues - linos/fep - Codeberg.org

There are two projects that are currently working on a rather feature complete FEP-8a8e support: Mobilizon and GatherPress ActivityPub. I expect more issues to come during implementation, but also in collaboration an the upcoming exchange we will solve them!

2 Likes

@kerstin Cool stuff! I added a task for a FEP-validator in my current NLnet grant (so me or even maybe you might have resources to work on this passionately). I will have a look at your project. I guess I might just contribute to it. But contributing would require you licensing the project under a FOSS license!

2 Likes

Just licensed it under AGPL :slight_smile:
Great news that there is funding, I might actually be interested to work on this starting next year!

2 Likes

I’m trying to determine what the minimal event is. The first example in FEP-8a8e is

{
  "@context": [
    "https://w3id.org/fep/8a8e",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "Event",
  "id": "https://example.org/foo",
  "name": "New years party",
  "startTime": "2014-12-31T23:00:00Z",
  "endTime": "2015-01-01T06:00:00Z",
  "organizers": null
}

Is this an Event that can be federated, e,g. should

{
  "@context": [
    "https://w3id.org/fep/8a8e",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "Create",
  "actor": "http://domain.example/actor/123",
  "id": "http://domain.example/activity/123",
  "to": ["http://other.example"],
  "cc": [],
  "object": {
    "type": "Event",
    "actor": "http://domain.example/events/123",
    "name": "New years party",
    "startTime": "2014-12-31T23:00:00Z",
    "endTime": "2015-01-01T06:00:00Z",
    "organizers": null
 }
}

be used to create an Event or would want expect an additional attributedTo property?

Is there something to pay attention to when federating events?

E.g. if I always federate next years (so now 2026) Winter Solstice’s celebration. Will that cause problems?

Please note that the disclosure of organizers will likely change: #5 - FEP-8a8e: Organizers disclosure - linos/fep - Codeberg.org

Using `attributedTo`, I’d recommend that because you want to be interoperable with as much applications in the Fediverse as possible!

What could be the potential misinterpretations, confusions for users? I guess e.g. a Mastodon users thinking that Actor is the ā€œownerā€ of the event. But I guess a Mastodon user not receiving such a event at all is even worse, because then attributedTo still has the meaning ā€œwho published this informationā€.

Btw: We have had a long discussion about not introducing an organizers collection in the first place and just using attributedTo… :wink:

Is there something to pay attention to when federating events?

E.g. if I always federate next years (so now 2026) Winter Solstice’s celebration. Will that cause problems?

I need more details :wink: I don’t know what general issues you might think of.

I identified several issues and potential improvements in the FEP. Lots of time with the help of others in amazing discussions, like the ones in person at FOSCON 2025 in Bozen, or by email with the Friendica folks. Thanks a lot to all of you!

Most of those issues are small. I invite everyone who is interested in this FEP taking a look at these and commenting your thoughts! I know reviewing the FEP from top till bottom is hard, because you likely will be overwhelmed, but maybe these tiny issues give you a good starting point! :yellow_heart: :purple_heart: :pink_heart:

1 Like

This is also strongly recommended by ActivityPub specification:

When a Create activity is posted, the actor of the activity SHOULD be copied onto the object’s attributedTo field.

– https://www.w3.org/TR/activitypub/#create-activity-outbox


And regarding our earlier discussion:

FEP-c7d3 was superseded by FEP-fe34. This newer FEP also recommends attributedTo because it indicates an owner, which is used for authorization:

https://codeberg.org/fediverse/fep/src/commit/70be4833e14e06c97529e6e6b816fac9328979cc/fep/fe34/fep-fe34.md#ownership

I think you can keep both organizers and attributedTo. The former will be a list or a collection, and the latter will be an actor that published a Create activity for an Event.

2 Likes

I’m just trying to figure out which fields are needed to create an event. For gancio, I need to add a location, but organizers was unnecessary.

Also if you mention the user the relay actor, creating the event fails for gancio.