Instance Federation: Visibility of remote Events

Gancio, Mobilizon and WordPress ActivityPub (along with the Event Extensions plugin) are currently working on well functioning instance follows between instances of them.

All three services already implemented FEP-2677 which should allow easily getting every activity from the other instance, especially as the application actor is used by all of them to announce. Edit: Gancio probably uses Create as it only has one ActivityPub actor.

As far as I understood, Mobilizon has some decision steps towards whether a remote event should be publicly listed. E.g. when the actor in attributedTo is of type Person it will not be listed. If it is a Group it will be. Things are not clearly documented, and I haven’t tested every possible scenario. An Issue exists to clarify this behaviour: Behaviour of which events of a followed instance are publicily listed (#1385) · Issues · Framasoft / Mobilizon · GitLab

My personal opinion: I understood this decision from the point of view that there are only Mobilizon instances following each other. But as others come into play this decision might lead to confusion.

Mastodon introduces two attributed to control this: discoverable and indexable. From the mastodon source code, because indexable is not yet documented yet:

discoverable: Your public posts and profile may be featured or recommended in various 
indexable: Your public posts may appear in search results on Mastodon. People who have interacted with your posts may be able to search them regardless.

In my opinion, regarding events I wonder if the separation between indexable and discoverable makes sense, too. In a Note all information lies within the content (controlled by indexable), but in an Event the information is split up into different fields: startTime, location, name, category, etc. Therefore I wonder if one should enforce the distinction of the two would mean that if indexable=false events would not be searchable my everything but startTime and endTime?

indexable was proposed and documented in FEP-5feb

Thanks for linking the FEP! The question that I still have is:

Let’s assume an event with

{
  ...,
  "type": "Event",
  "name": "Concert by the Be-Flats",
  "startTime": "2024-04-02T12:00:00Z"
  "category": "MUSIC"
  "discoverable": true,
  "indexable": false,
  ...
}

If the actor publishing this Event is followed by another instance (it’s application actor) how should this be treated?

Discoverable would mean the Event could most certainly be listed. If we assume yes, then the event might get listed in the remote+local event upcoming Events overview page, which is visible for everyone, even not logged in users.

But when now filtering for a specific startTime or category should it be excluded? What is actually meant by a search and what is not?

When searching for “Be-Flats” the meaning of indexable is clear to me.

Any ideas?

Discoverable would mean the Event could most certainly be listed.

In the case of Mastodon, the discoverable attribute applies to Actor profiles. Ex: should this profile be suggested to others.

So I’m not sure discoverable belongs on an event, I would refer to the object’s visibility for this.

Does it include the Public special collection?

[…] which is visible for everyone, even not logged in users

Again, this part is important, if the Event is not public it should not be shown on any public facing page.

But when now filtering for a specific startTime or category should it be excluded? What is actually meant by a search and what is not?

IMHO the intent of indexable and its relation to content is to safeguard against abusive search.

Respecting the intent, should be interpreted to mean any part that isn’t metadata such as the contents of name for example.

But, in the case of filtering a list of public events by category or start time, this may be enough of a distinction from Search.

Another way to look at it could be, what are the assumptions of instance to instance follows.
Does your instance Announce incoming activities to its followers? Is this a good proxy to whether these events should be listed?

Thanks for joining the discussion!

I see, it seems true that toot:discoverable is only used on actor profiles until now. But the definition, as far as I understand, does not limit it to Actor objects.

the intent of indexable and its relation to content is to safeguard against abusive search.

I agree. But I would still love to hear more opinions on this. While I haven’t yet come up with a good anti-example for startTime I can certainly imagine that the category has potential for abuse (e.g. LGBTQ :disappointed_relieved:).

Does it include the Public special collection?

Do you mean by that the public addressing? The events I had in mind should have this in common. Mobilizon is actually using this as a indicator for remote events whether so set it’s internal visibility to public or unlisted.

Does your instance Announce incoming activities to its followers? Is this a good proxy to whether these events should be listed?

What do you mean by incoming? Remote objects or newly created local ones?

Anyway, not sure I can answer that at the moment.

My Background

(I work on WordPress ActivityPub and being able to aggregate Events is not on our Agenda yet. But now that several other software applications are focusing on the federation of events, I think we should strive for a common approach in order to ensure trust and safety.)

Unfortunately, Mobilization has had some major issues in the past with which incoming objects the application actor has been announcing to it’s followers and which objects did show up in the public outbox.