rsvp

From IndieWeb
Jump to: navigation, search

💌


An RSVP is a type of post that is a reply to an event post.

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, and via Bridgy Publish to Facebook events as well!

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 RSVPs are very similar to the how tos for replies so we won't duplicate common info here.

Publish an RSVP

Post a reply and use the h-entry p-rsvp property to post the RSVP status, e.g. inside your reply:

  • <span class="p-rsvp">no</span> - however this assumes that you want "no" in your readable text. Otherwise 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>

Possible RSVP values: yes, no, maybe, interested

Send a webmention to the event post as you would for a reply to any post.

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

You can copy and paste this into a post, and replace the example URL with the URL of the event you're RSVPing to. If your blog software already wraps your posts with h-entry, then you can copy only the inside text.

<div class="h-entry">
 RSVP <span class="p-rsvp">yes</span> 
 to <a href="http://example.com/event" class="u-in-reply-to">IndieWeb Example Event</a>
</div>

Here's another example with explicit author name and icon, in case your site or blog does not already provide that on the page.

<div class="h-entry">
 <a class="p-author h-card" href="http://mysite.example.org">
   <img alt="" src="http://mysite.example.org/icon.jpg"/>
   Supercool Indiewebauthor</a>: 
 RSVP <span class="p-rsvp">yes</span> 
 to <a href="http://example.com/event" class="u-in-reply-to">IndieWeb Example Event</a>
</div>


Contents

Multi RSVP

If there are multiple copies of a single event (e.g. POSSE copies, or reposts), 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.
  • 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)

Bret Comnes

Bret Comnes has 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:

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:

Example:

Tantek

Tantek Çelik has implemented RSVP reply notes in Falcon deployed on his site tantek.com as of 2013-264.

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.

Kyle Mahan

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.

gRegor Morrill

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

Jeena

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

Example:

Tim

Template:webrocker implemented RSVP notes on his site www.webrocker.de since 2016-04-16

Example:


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:

Ryan Rix

Ryan Rix (rrix) is able to publish RSVPs through Arcology since 2013-04-13 by attaching a P-RSVP property to any reply. This is syndicated out to non-indie events using Bridgy.

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:

  • yes - "going to" (implemented in #Tantek's RSVPs).
  • maybe - "might go to"
  • no - "not going to" (implemented in #Tantek's RSVPs).
  • interested - "interested in"
  • tracking - "tracking"

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

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

POSSE

How and where should RSVP posts be POSSEd?

Event-aware destinations to consider:

  • Facebook - lots of events are posted on FB
    • Bridgy Publish supports POSSEing RSVPs to Facebook Events!
    • Tantek Çelik is posting RSVPs using Falcon on tantek.com and automatically POSSEing them to Facebook using Bridgy. See examples above.
  • Plancast - event-specific silo
    • No explicit Bridgy Publish issue for POSSEing an indie RSVP to a Plancast event as no one has posted one yet.

Problematic event-aware destinations:

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

Other destinations:

  • Twitter - can we compress the details of an RSVP post into 140 characters or less? (117 to leave room for event permalink URL, 116 for https).
    • 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:

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).

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:

See also

Retrieved from "https://indieweb.org/rsvp"
Personal tools
Namespaces
Variants
Actions
Recent & Upcoming
Resources
Toolbox