rsvp

From IndieWeb
(Redirected from multirsvp)


An RSVP is a reply to an event that says whether the sender is attending, is not attending, might attend, or is merely interested.

  • See rsvps for how to display received RSVPs on your event posts!
Looking for a quick way to RSVP to the next IndieWeb event? See:

Why

Why implement RSVP posts?

Own your RSVPs! It’s empowering being able to RSVP (especially yes or maybe) from your own site to the indie event posts!

Share your RSVPs with friends. For public events that you'd like your friends to attend, post RSVPs publicly on your own site. When your friends see that you're going or might go, it helps encourage them to also attend.

Encourage friends to go even if you cannot. Why implement and post a RSVP no? A public RSVP no is a good way to share and promote an event you wish you could go to but can't make it to.

Why POSSE RSVPs? Because the sharing / encouraging aspect of publishing makes sense beyond the simple RSVP answers, it also makes sense to POSSE all your RSVPs as you would any other reply or note (e.g. to Twitter etc.) beyond just responding to the event.

How to

How-tos for RSVP posts are very similar to the how-tos for reply posts so we won't duplicate common info here.

How to publish

How to publish an RSVP:

Use a tool that supports RSVP posts! E.g.

How to RSVP with WordPress

If you use WordPress:

  1. Make sure you have webmention functionality set up in WordPress
  2. Choose from ONE of the following:
    • Use the "RSVP" javascript bookmarklet in the IndieWeb PressThis bookmarklet. Once installed and activated, the bookmarklets can be found in the admin menu under "Tools". Go to the page you want to RSVP to and click the bookmarklet in your browser to create an RSVP post.
    • Use Post Kinds Plugin to post an RSVP post. Use the Post Kinds Plugin which includes RSVP functionality. Set the Post Kind as RSVP, add the URL & Title of Event into the Post Properties box, and set the RSVP Property to whether you are attending or not.
    • Add minimal HTML to a post. Create a traditional post and use HTML as described below.

How to RSVP with Micro.blog

If you use micro.blog:

  1. Add an HTML link to your blog post with the class "u-in-reply-to".
  2. Add a span or data tag similar to the "How to RSVP with HTML" instructions below, using class "p-rsvp".
  3. When the post is published, Micro.blog will notice the reply URL and send the Webmention for you.

See this post from Manton: Micro.blog RSVPs with Webmention for more details.

How to RSVP with Known

If you use Known:

As of the 0.99 release, Known includes an "Events" plugin by default. Once signed into your Known site, you may activate the Events plugin under the "Site Configuration" menu. Navigate to Plugins, scroll down to find the Events plugin, and click to enable the plugin.

Once enabled, the action bar at top of the content area of your Known website should include an icon entitled "RSVP." Click the icon, and follow the instructions to send an RSVP. Once the RSVP post is created, Known will automatically send a Webmention to the supplied website address.

How to RSVP with HTML

Or if you're using another tool (like your own CMS) then:

1. Create a reply post and use the h-entry p-rsvp property to specify your RSVP status.

Here's a minimal RSVP post example: 

<div class="h-entry">
  <p class="p-summary">
    <a href="https://example.com" class="p-author h-card">Your Name</a>
    RSVPs <span class="p-rsvp">yes</span> 
    to <a href="https://events.indieweb.org/example" class="u-in-reply-to">Event Name</a>
  </p>
</div>

Replace example.com with your site, your name, the event URL, and the event name.

Notes:

  • Possible RSVP values for the p-rsvp: yes, no, maybe, interested
  • If your site already adds the h-entry class, then you will need to leave out the wrapping <div class="h-entry">
  • If your site already adds your author information, then you will need to leave out the link wrapping your name with class="p-author h-card"
  • See authorship for more options to indicate your author information, including your photo


2. Send a Webmention to the event post as you would for a reply to any post. (Sending your First Webmention from Scratch by Aaron Parecki is a good tutorial for those doing this for the first time without using other software.)

3. You should include author information in your RSVP post so the event knows who is attending (and then send another Webmention so the event page gets the update).

See reply#Make_a_comment for more general details on posting replies.

You can also use the data element to express the meaning behind the literal p-rsvp value while providing your own visible human readable language:

  • <data class="p-rsvp" value="yes">I'll be there!</data>

Multi RSVP

If there are multiple copies of a single event (e.g. POSSE copies, or reposts), or multiple sessions for an event, you can post a multi-RSVP, a single RSVP post that replies simultaneously to multiple event URLs.

Publish a multi-RSVP just as it says above, and add in-reply-to markup for each of the events, similar to how a multi-reply does so to multiple posts.

The difference is:

  • A multi-RSVP must link to multiple event posts only when they all represent the same real world event, or multiple sessions for the same event, e.g. a multi-day event with different URLs for each day.
  • A plain multi-reply may be replying to multiple different posts, that just happened to be related by topic or thread.

NEEDED: (a complete multi-RSVP markup example would be nice too)

Update an RSVP

Similarly, update your RSVP and send another webmention.

See reply#Update_a_comment for more general details on updating replies.

Delete an RSVP

Similarly, delete your RSVP, send another webmention, and be prepared to return 410 GONE for your RSVP permalink.

See reply#Delete_a_comment for more general details on deleting replies.

Accept an RSVP

RSVPs are sent to event posts, which should recognize that this type of response is a special RSVP response, and can use that to increment attending/not attending counters for example.

When you receive a webmention from a URL that is a reply (has an in-reply-to URL that is the event URL), also check if the entry contains an rsvp property.

IndieWeb Examples

In datetime order of implementation (earliest first)

Aaron Parecki

Aaron Parecki has implemented RSVP posts in p3k deployed on his site aaronparecki.com:

RSVP posts are marked up with the p-rsvp property from the microformats2 h-entry plus proposal.

Example:

Multi-RSVPs published since 2014-09-08. E.g.

autosuggest

If a p3k user is creating a reply to a URL, p3k:

  • parses the reply URL
  • looks for an h-event
  • if it finds one,
    • changes the type from reply to an rsvp
    • prompts the user to select yes/no/maybe/other

Nick Doty

Nick Doty implemented RSVP notes on his site npdoty.com (since YYYY-MM-DD?)

Example:

Tantek

Tantek Çelik has implemented RSVP reply notes in Falcon deployed on his site tantek.com as of 2013-264, and support for all RSVP values in Falcon as of 2017-016!

RSVP posts' reply-contexts are marked up with the p-rsvp property from the microformats2 h-entry plus proposal.

Examples:

Multi-RSVPs published since 2014-09-12. E.g.

  • all RSVPs have minimal reply-context which, in addition to RSVP yes/no/maybe/interested, just shows URL(s) of event(s) being replied to

gRegor Morrill

gRegor Morrill Has manually posted at least one rsvp on gregorlove.com as of 2014-06-26:

As of 2017-06-07, showing RSVP responses on events:

I also RSVP to events on sites that don't support webmentions or microformats, like meetup.com:

Jeena

Jeena Paradies implemented RSVP notes on his site jeena.net since 2016-??-??

Example:

Tim

Tom Arnold implemented RSVP notes on his site www.webrocker.de since 2016-04-16

Example:

Ryan Rix

Ryan Rix (rrix) is able to publish RSVPs through Arcology since 2016-04-23 by attaching a p-rsvp property to any reply. This is syndicated out to non-indie events using Bridgy. E.g.

Shane Becker

Shane Becker manually RSVPed from an Article to IndieWeb Summit 2016 on 2016-05-02.

Scott Gruber

Manually RSVPed from a Note to IndieWeb Summit 2016 on 2016-05-23.

Example:

Sebastiaan Andeweg

Sebastiaan Andeweg posted his first event on 2017-01-06 (an indie event for HWC 2017-01-11) and replied to it with an RSVP post a few hours later.

Martijn van der Ven

Martijn van der Ven has been RSVPing since YYYY-MM-DD? when confirming he was going to the first HWC of 2017 in the Netherlands. Example:

Eddie Hinkle

Eddie Hinkle has been RSVPing since 2017-03-11 when confirming he was going to his first HWC in Baltimore, MD.

Doug Beal

dougbeal has been RSVPing since 2017-05-09 when confirming going to IndieWeb Summit 2017 in Portland

https://dougbeal.com/kind/rsvp/

Example:

fluffy

fluffy has been RSVPing since confirming attendance of IndieWeb Summit 2019 in Portland, implemented using custom headers implemented in a Publ template.

Jamie Tanna

  Jamie Tanna has been RSPVing since 2019-05-13.

From 2019-07-27 Jamie has created an iCalendar feed for his RSVPs.

Past Examples

Ben Werdmuller

Ben Werdmüller implemented RSVP posts in idno in 2013, however sometime later benwerd's RSVPs appears to have lost their p-rsvp markup.

RSVP posts are marked up with the p-rsvp property from the microformats2 h-entry plus proposal.

Example:

Bret Comnes

Bret Comnes implemented RSVP posts on his site bret.io:

RSVP posts are marked up with the p-rsvp property from the microformats2 h-entry plus proposal.

Example:

Kyle Mahan

⚠️ Kyle's site is now unfortunately a zombie site, so links have been replaced with archived versions

Kyle Mahan has posted RSVPs on his site since 2014-04-08. RSVP posts are just regular replies with a hand-authored p-rsvp property. Examples:

Brainstorming

RSVP buttons

An RSVP post starts with some UI to create it, typically in the context of a specific event.

RSVP Interested Going

A reader could recognize a public event post, and present buttons for the user to RSVP (e.g. via micropub with their own site).

Good start with minimal likely options: 

[ Interested ] [ Going ]

Clicking either button would publish the respective RSVP to the user's site via micropub, and at a minimum could then:

  • Show confirmation: replace the buttons with static UI text that says 
    ✓ Interested
    or 
    ✓ Going
    depending on whichever the user chose. This state would not be stored anywhere except the current state of the browser.

RSVP simple updates

A reader that implemented the above [ Interested ] [ Going ] buttons could add just a tiny bit of browser-only code that allowed for undo and updates, as follows:

Start with minimal likely options again: 

[ Interested ] [ Going ]

But this time, if the user clicks a button, only that button turns into static text, e.g.:

If the user clicks Interested: 

✓ Interested  [ Going ]

If the user clicks Going: 

[ Interested ] ✓ Going

If the user clicks on the static text with checkmark ✓, then delete the RSVP and show: 

[ Interested ] [ Going ]

Similarly, if the user clicks on another button after clicking one, then update the RSVP accordingly and switch the display to that button being static checkmark UI text.

RSVP buttons with state

If a reader can keep track of the posts it has made on behalf of the user (keep a cache of the user's RSVP post permalink), then it could update the buttons accordingly (instead of just showing static UI text).

If they chose "Interested", show a button drop down 

[ ✓ Interested v ]

which when clicked shows: 

[   Going          ]
[ ✓ Interested     ]
[ --------------   ]
[   Not Interested ]

If they chose "Going", show a button drop down 

[ ✓ Going v ]

which when clicked 

[ ✓ Going     ]
[   Maybe     ]
[ ----------  ]
[   Not Going ]

And if they click any of those, the show Going as above, and:

If they chose "Not Interested", delete the RSVP post and show (like before) 

[ Interested ] [ Going ]

If they chose "Maybe", show a button drop down 

[ ✓ Maybe v ]

which when clicked 

[   Going     ]
[ ✓ Maybe     ]
[ ----------  ]
[   Not Going ]

If they chose "Not Going", update the RSVP post and show a button drop down 

[ ✓ Not Going v ]

which when clicked 

[   Going     ]
[   Maybe     ]
[ ----------  ]
[ ✓ Not Going ]

And again, when selected, update the RSVP post and show the updated button/dropdown.

RSVP Going Maybe Cannot

For private events and invitations, a reader could instead display: 

[ Going ] [ Maybe ] [ Can't Go ]

Invitations to a private event typically have an expectation (from the host) of a stronger indication of intent of the invitee. If you receive an explicit invite to a private event, it's more likely that the host wants an actual yes/no response vs a silent ignore.

Some more reasoning (why the other options are less necessary for private events)

  • "interested" is there to be able to let others know of your potential interest in the event, but makes less sense on a private event since a private event doesn't need the "boost" of promoting it to a larger network.
  • "ignore". More likely to need the "ignore" button for public events since it's a lot easier to be "invited" to those because of the way Facebook encourages sharing events.

Text Design

Similar to like brainstorming, it's useful to explore how to best represent RSVP posts as a notification (e.g. to the author of the event (and the invitation) that the RSVP is responding to), text only (e.g. SMS authoring/output or POSSEing to text only destinations), inline hypertext and markup for that.

(stub)

E.g. some p-rsvp value/prose equivalent possibilities to consider, as the start of a plain text reply

  • yes - "going to " (implemented in #Tantek's RSVPs).
    • "attending " for an RSVP published during the event. (implemented in #Tantek's RSVPs, Tantek Çelik research: 2 of 3 past uses (once a year 2010-2012) of "attending …" in notes were RSVPs, and third was an implied RSVP).
    • "went to " for an RSVP published after the event's end time or has otherwise ended. (implemented in #Tantek's RSVPs)
    • "hosting " for an RSVP to an event that you're actually hosting (implemented in #Tantek's RSVPs)
    • "hosted " for an RSVP published after an event's end time that you hosted (implemented in #Tantek’s RSVPs)
    • "co-organizing " for an RSVP to an event that you're co-organizing, but perhaps not hosting (implemented in #Tantek's RSVPs)
    • more possible variants: "co-hosting", "organizing"
    • "signed up for " for an RSVP to an event that includes some form of active partipation (e.g. a trail race) (implemented in #Tantek's RSVPs).
    • "rsvp yes" gRegor Morrill is experimenting with, see below
  • maybe - "might go to " (implemented in #Tantek's RSVPs).
  • no - "not going to " (implemented in #Tantek's RSVPs).
    • "missing " - as an alias of "not going to " that reflects more of an implied desire to have gone. (implemented in #Tantek's RSVPs).
  • interested - "considering tonight's ", "considering today's ", and "considering going to ", all of which provide enough specific context to imply an event (implemented in #Tantek's RSVPs)
    • non-explicit-RSVP real-world example of "insterested " at start of a note that does reflect this semantic: http://tantek.com/2011/040/t4/long-now-live-longer-think-who-going (only example found of "considering " text pattern match on his site that applies to an event)
    • Rejected: "interested in " - seems too generic, never felt like using it in practice

Remote variants? Only for some level of actual participation (yes, maybe).

  • yes - "remotely attending "
  • maybe - "might remotely attend " (implemented in #Tantek's RSVPs).

gRegor Morrill: I was thinking about this and wrote an idea to parse plain text Twitter replies since they're sent to me via Bridgy. I'm experimenting with this for 2019-12-11 HWC (see tweet). Added text above, inline.

Remote Participation

If an event has a remote-participation option (no idea how to represent that other than prose), then it makes sense to allow people to RSVP as a remote participant.

This is useful for at least two reasons (use-cases), a remote RSVP ...

  • helps the event organizer plan for making sure the remote-participation setup is working
  • implies the organizer need not worry about any food/drink/seating in-person for that RSVP

Real world examples:

  • #Tantek's RSVPs for a couple of real world examples of prose publishing of remote RSVPs.
  • #Doug_Beal's RSVPs for yes (remote) example

Driving use-case:

Possible approaches:

  • new property (seems heavy-weight)
    •   Jamie Tanna feels this is a better option than extending the RSVP property and adding logic to all clients in terms of what it supports. It means clients need to support a new property instead of a breaking change for existing properties
  • new RSVP property value, e.g.
    • "yes-remote" - would likely require everyone (including English publishers) to use data element, perhaps a good thing to encourage cross-language consistency in markup?
  • expand RSVP property grammar, space separated set of values like class/rel, add "remote"
    • e.g. "yes remote" (or "remote yes", equivalent)
    • also "maybe remote" (not sure if anyone has published this yet)

What value could be used to?

It is necessary to differentiate yes between remote and onsite, especially considering the second reason given above. Someone participating remotely will not be taking a seat and may not always count towards the total of guests allowed.

Would it be useful to extend the possible values from yes, no, maybe, interested to yes, no, maybe, interested, remote yes, remote no, remote maybe, remote interested?

  • with these double values, does the order matter? Should consumers pickup yes remote too? This makes consuming harder.
  • Sebastiaan Andeweg: remote no does not need it's own value, for no is 'no'. I'm not sure about remote maybe and remote interested, but if it turns out you don't need them, just remote (and implying 'remote yes') might be just enough.
    • -0 on remote no. If an event explicitly allows / encourages remote participation, a remote no could make sense as an update to a remote yes or remote interested previous RSVP, though it's not clear that just plain no wouldn't work, or rather, what additional meaning / usefulness does remote no provide over no? I'd lean toward minimizing possible values to those that have actual necessary use-cases not covered by existing values. - Tantek Çelik 13:59, 2 May 2018 (PDT)
  • dash instead of space? remote participation is so different than in-person participation that it may make sense to use explicit new dash separated values for them like: remote-yes and remote-maybe ( Tantek Çelik has used remote maybe in prose) indicating actual intent or possibility of using remote participation tools. It's not clear how remote-interested is any different than interested (neither implies anything about participation), see above for why remote-no is likely unnecessary. - Tantek Çelik 14:03, 2 May 2018 (PDT)
  • David Shanske believes remote yes is redundant. For a yes remotely, just remote makes sense. No is no. There may be a case for a maybe or interested version of remote in future, but suggest that remote itself should come first.
Remote value examples

POSSE

How and where should RSVP posts be POSSEd?

Event-aware destinations to consider:

  • Facebook - lots of events are posted on FB

Problematic event-aware destinations:

  • Google+ - another silo that has explicit event posts, but has some challenges:
    • G+ API doesn't expose events

POSSE to Twitter

Twitter - can we compress the details of an RSVP post into 280 characters or less? (256 to leave room for event permalink URL).

  • Is there an event POSSE tweet to @-reply to from your RSVP POSSE tweet?
  • If not, how do we abbreviate what/when/where "fields"? E.g. just like event#POSSE:
    • What: summary... (ellipsed)
    • Where: @-alias of venue (how do we do venue lookup on Twitter? Perhaps use Foursquare to lookup the venue and see if their venue entry has a Twitter for the venue?
    • When: YYYY-MM-DD HH:MM (seems quite long, what's the best way to compress a datetime in a human readable way?)
    • CC: @-names (of folks to explicitly notify, like an invitation)
    • Should such fields be explicitly labeled e.g. with "What: / Where:" etc. with linebreaks between them?
    • Or should we figure out a plain text event serialization format since things like an @-named venue already reads well "at venue"? (see picoformats for prior work/research on this)
  • IndieWeb Examples:

Backfeed from Twitter

While this may be more appropriate on RSVPs#Brainstorming, keeping here since it is part of the same design dependency as POSSEing to Twitter — human readable plain text RSVP posts.

RSVPing with others

Many event systems (e.g. Evite) provide the ability for invitees to RSVP with an optional additional number of people they will bring to an event, AKA a "plus one" or "+1" or more.

It would be good to figure out a way to:

  • post an RSVP for yourself and some number of additional attendees (you plan to bring with you)
  • post an RSVP and explicitly list who else you plan to bring with you, in essence RSVPing on their behalf (which they themselves may syndicate-in from your RSVP post to their own site)
  • define how an event organizer’s site can receive this information to keep track of and possibly display:
    • the total number of attendees
    • who is planning to attend the event

Whether or not an event has explicit capacity, the ability to indicate a "+1" optionally with their name is helpful both to folks publishing RSVPs, and folks hosting events to get a count of and who will attend for event planning purposes (food, seating, other constraints etc.)

Capacity and Ticketing

TODO( Kevin Marks, Ryan Barrett): merge into event#How_to_limit_capacity

If event capacity is limited, the event host may not know at the time of responding to the RSVP whether you are allowed in (get a ticket) or not (waitlisted). It can supply a URL to answer this later in the RSVP 202 response. However this protocol could be extended to cover the ticketing case too.

  • Return the ticket/waitlist url in the RSVP response.
  • when the capacity issue is resolved, update the ticket url information so that the unauthenticated page includes a h-entry that states 'you have 2 tickets' 'you are waitlisted' etc.
  • send a webmention back to the RSVP post so that this response shows up OR poll the webmention status URL
  • we could define new markup for this stage so it can be automatically handled

Attendees can also RSVP for multiple people, ie request multiple tickets, by posting multiple RSVPs, one per ticket. CMSes can automate this with custom RSVP UIs that generate and send an RSVP post per ticket.

During the event, there are a couple possible ways for host(s) to verify attendees. If you want to use traditional tickets, when the RSVP poster goes to the ticket link, they can authenticate in with indieauth to get the actual ticket proof, which may be printable, a QR code to display on the phone, or just a page you show to the doorkeeper.

A more modern, IndieWeb way is to forego tickets entirely, digital or otherwise. If the host has followed the process above, they end up with a list of RSVPs and domains for those RSVPs. The host can then set up a page on their site that accepts IndieAuth logins. When an attendee arrives, they IndieAuth into that page with their domain, the host checks the domain against their RSVP list, and lets them in (along with any guests).

Calendar integration

It could be useful for RSVP 'yes' posts to appear in your calendar.

FAQ

are rsvp-values case-sensitive?

No. Per the h-entry specification, the values for p-rsvp are Case-insensitive values, normalized to lowercase., so yes, Yes or yEs are all valid and equivalent.

Silo Examples

Facebook

Facebook has fairly widespread support of RSVP posts and RSVP-specific webactions on event posts.

Many details about Facebook's RSVP posts and buttons (including screenshots and wireframes) are captured here:

Sessions

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=rsvp&oldid=96810#Multi_RSVP"