Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support better interactions with events #20407

Open
eest9 opened this issue Nov 11, 2022 · 3 comments
Open

Support better interactions with events #20407

eest9 opened this issue Nov 11, 2022 · 3 comments
Labels
activitypub Protocol-related changes, federation suggestion Feature suggestion

Comments

@eest9
Copy link

eest9 commented Nov 11, 2022

Pitch

  • Support Join or Leave activities for fetched event objects
  • Revoke the like activity for fetched event objects

Motivation

As made clear in #12166 Mastodon doesn't support Join or Leave activities for event objects. Since #12637 it displays events as status. But it only allows the same interactions, than with note objects. This causes issues because Users on instances don't get likes and since mastodon users don't join or leave events, remote users also do not get an estimate of users interested in participating at those events. For better interoperability within the fediverse I suggest replacing the Like-Button with a Join-/Leave-Button

@eest9 eest9 added the suggestion Feature suggestion label Nov 11, 2022
@ineffyble ineffyble added the activitypub Protocol-related changes, federation label Nov 11, 2022
@hach-que
Copy link

hach-que commented Jan 2, 2024

As someone who develops an event hosting platform, I'd also like to see better support for Event objects in Mastodon, such that users can RSVP inline to event objects.

I did some prototyping of what this UI could look like in the Mastodon web client:

firefox_vW3nsKBU5u.mp4

I believe this would mean that Mastodon would need to:

  • Support the "Invite" activity type, where the object is an Event
  • Issue "Accept", "TentativeAccept" and "Reject" status against the object when users click "Yes" / "Maybe" / "No"

I would also prefer it if:

  • The event object can specify whether it supports inline RSVP: some events required tickets to be purchased, and thus pressing "Yes" on Mastodon would not be enough to attend them. Having the alternative show a "Get tickets" button that links to a URL specified on the Event object would be a bonus, but as long as we can hide RSVP buttons when needed, then we can always fall back to just embedding an <a> tag in the content for a Get tickets link.
  • The event object can specify whether RSVP permits the "Maybe" option: some event organisers don't want tentative acceptance of an event and would like to be able to turn off "Maybe" as an option.

The benefit of Mastodon supporting accept/reject activities for events is that users don't need to go and create an account on a separate platform just to RSVP - they can RSVP directly with their Mastodon account on any Mastodon instance.

I'm willing to put in time to implement this on the code side, but given that it's a user facing change that has design implications, I need to make sure this is a change that would be accepted by upstream before work begins on it (i.e. there's no point building this functionality if is not going to get merged since that will mean most Mastodon instances will never have it available).

@Menrath
Copy link

Menrath commented Jan 13, 2024

@hach-que You might want to be interested how Rebase, a fork of plemora has drafted this, because the general UI is quite similar to Mastodons. These are screenshots from a test account I use myself.

image
image
image

@Menrath
Copy link

Menrath commented Jan 13, 2024

And I would not say that sending a Like to an event is a wrong thing to do. It's up to the receiver what to do with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
activitypub Protocol-related changes, federation suggestion Feature suggestion
Projects
None yet
Development

No branches or pull requests

4 participants