Events Interoperability: Validation, minimum requirements, common extensions

ActivityPub
1

This thread should give an overview and discuss how current ActivityPub implementations that work with the Event object type handle them.

  1. Validation of events
  2. Minimum set of required attributes
  3. Common set of extended attributes.
3 Likes
2

I started a list to collect what different fediverse applications do when importing/validating an incoming remote event via ActivityPub.

This document is still likely far from being complete and correct. I hope it can be a good starting point.

2 Likes
3

What seems important:

  • Common handling of what events might get listed, and how they can be searched.
  • Way to handle event categories: common defaults and new ones as categories are very helpful filters for a search.
  • Way to sync the participant-count.
  • Common way to control per-object reply policy.
  • location
    • what types of address within the location should be supported
    • indicate that the event is solely online (and provide URL then)
  • Banner image
    • Whats the preferred “place” for it
    • Support of toot:focalPoint?
  • joinMode
  • Timezone control
  • Should contentMap, summaryMap, nameMap etc. be supported?

Proposals which include already implemented solutions will follow, feel free to add yours!

4

It would be cool if we could integrate something like this into one of my support tables.

This would be something to address depending on the results of #109 - Pastures: More debug-like or more production-like? - helge/funfedidev - Codeberg.org

5

Thanks for bringing this up. It took me some time to understand but seems great! After FOSDEM/OFFDEM I will come back to this, and ask you if I should need some more guidance, I hope thats O.K.

2 Likes
6

I think this thread could be a starting point for our discussion:

location

what types of address within the location should be supported ? indicate that the event is solely online (and provide URL then):

gancio example:
{
	"location": {
		"type": "Place",
		"name": "Nashville USA",
		"address": "Houston, Harris County, Texas, 77028, United States",
		"latitude": 29.8242366,
		"longitude": -95.2845581
	}
}
mobilizon example:
{
	"location": {
		"address": {
			"addressCountry": "France",
			"addressLocality": "Bourgoin-Jallieu",
			"addressRegion": "Isère",
			"postalCode": "38300",
			"streetAddress": "30 Avenue Alexandre Flemming",
			"type": "PostalAddress"
		},
		"id": "https://mobilizon.fr/address/e96ef587-9e7b-44ee-b96b-475b241adf5c",
		"latitude": 45.597374,
		"longitude": 5.243424,
		"name": "30 Avenue Alexandre Flemming",
		"type": "Place"
	}

}

  • location data (location name? address, what format? gps coords?)
  • online only events (attachment type link? isOnline attribute as mobilizon?)
  • mixed on/offline events (what about isOnline attribute then?)

at least a location or an attachment link are mandatory?
what about if we want to organize an event of which we do not yet know the location?
should we introduce a locationStatus like ['ONLINE', 'UNKNOWN', 'MIXED', 'IRL']?

Banner image

Whats the preferred “place” for it?

could we use attachments with type Document / Banner ?

Support of toot:focalPoint?

probably not mandatory?

joinMode

not mandatory?

Timezone control

not mandatory?

Should contentMap, summaryMap, nameMap etc. be supported?

not mandatory?

Common handling of what events might get listed, and how they can be searched.

should we implement a “follower only” event? how does this make any sense with applicationActor?

categories

Way to handle event categories: common defaults and new ones as categories are very helpful filters for a search.

starting point:

2 Likes
7

other people have already done this work, Core Public Event Vocabulary and Event - Schema.org Type.

For example, with respect to the topic on the type of place: eventAttendanceMode - Schema.org Property

We should find a synthesis between what is specified there and some properties that already have a place in Activity Pub: for example for images I see that in schema.org format there is image attribute while in AP we already have attachment, I would stay on the latter.

1 Like
8

Friendica has implemented the events as well. See here for a list of fields we support:

2 Likes
9

Thanks for that! Do you maybe also know/can quickly point us to how Friendica validates incoming events?

10

There a also some schema proposals for event schedules here: Modelling Opportunity Data 2.0

1 Like
11

We simply store the values. There is not a lot f validation here.

12

Some questions:

What do you think about multiple locations and or logical locations as stated in the specification?

location:

Indicates one or more physical or logical locations associated with the object.

At first I thought one could get around by using a property like Mobilizons isOnline. But as it seems a valid use case that in the future one only wants to reveal an online-link or a physical location to accepted attendees this is not possible anymore.

At OFFDEM we discussed about also noting whether the event has a physical location (secret or just not known yet) which would also cover hybrid (on and offline) events.

Looking forward to hear your thoughts!

13

I agree, none of these should be mandatory.

14

@les The ActivityPub specification also has an image attribute https://www.w3.org/ns/activitystreams#image. The link Activity Vocabulary leads to the object type Image not the property image, take care.

Indicates an entity that describes an image for this object. Unlike the icon property, there are no aspect ratio or display size limitations assumed.

I think that this one suites the best for a banner image of an event, what do you think? (forgetting for a moment, that other ActivityPub implementations exist…, I don’t know if this is used anywhere in the wild yet.)

15

I created a first version of a FEP-8a8e: A common approach to using the Event object type

FEP: fep/fep/8a8e/fep-8a8e.md at fep-8a8e - linos/fep - Codeberg.org
Pull Request: #430 - WIP: Initial Draft of FEP-8a8e: A common approach to using the Event object type - fediverse/fep - Codeberg.org

See it as a proposal, I would be happy to hear some feedback here before removing the WIP flag on the pull request.

It has a few notes of things I am not sure of. Also I have to re-evaluate all MUSTs and SHOULDs cause I got lost a bit in the writing process.

About Duck-Typing vs Multi-Typing (introducing a new attribute vs adding a second type), we already had a small discussion: André Menrath: "Are there any Fediverse applications that have pr…" - graz.social

2 Likes
18

I started with replies in socialhub. but that is no good idea! So i switched to a Review, that should be easier to handle. i will delete my 3 posts in socialhub

1 Like
19

Minimal receivable event

Shouldn’t minimal event have an attributedTo property? I recommend adding it if interoperability with micro-blogging services is desirable (they can represent Event as a “post” authored by attributedTo).

20

attributedTo might indeed be a reasonable field to put the event’s organizers in.

Though it could also be used for more, I think the definition would also allow for it being for example a “parent” event (imagine a three day festival with various concerts).

I will add it to the spec along with some examples. But my first impression is that it should be a “SHOULD” and not mandatory.

@silverpill Do you have any idea how one could handle consent of the organizer (or multiple ones), at least if those are actors?

21

I think attributedTo actor should be located on the same server as Event, because this property is commonly used to specify an actor who created the object.
It would be better to use a different property for organizers (organizers?), especially if there may be more than one and if they may be located on different servers. You can ask for consent by sending Offer or Invite activities, which organizers will Accept or Reject (the side-effect of Accept could be an inclusion of Event in organizer’s events collection), though there are other options.

22

Not using as:attributedTo makes sense when having fep/fep/c7d3/fep-c7d3.md at main - fediverse/fep - Codeberg.org in mind, as it assumes the attributedTo being a single actor (the FEP could be even more clear in language on this, in my opinion).

I would really like to have more opinions on this, I am curious. I would rather prefer this FEP not to be incompatible with another one, but apart from that the as:attributedTo would have felt quite right to me, as it would already allow to also just include links to organizers that have no Fediverse actor yet too, without a new property.

How to “add” new organizers:
Thanks for pointing that out! The as:Offer activity might indeed be well suited to invite other actors to serve as an organizer. For as:Invite the language points more to an invitation for participation, but this could be made clear in the FEP.

So when accepting that as:Offer for being a co-organizer, I had the idea that the response could then provide a proof, calculated solely by the as:ID of the as:Event. Not using the whole object has the reason that an as:Event object might get updated quite frequently (participant counts etc.). @silverpill as you authored two FEPs targeting proofs I would really like to get your opinion on this, too! :slight_smile:

Amendment: I just discussed the as:Offer with @laurin, he suggested to indeed use a property organizer which is a as:Collection. So then the as:Offer is not directed at the as:Event itself, which may seem odd, but the as:Offer could be targeting the organizer Collection of the as:Event.

1 Like