SWAT0

From IndieWeb
(Redirected from swat0)
Jump to: navigation, search

SWAT0 is an abbreviation for The Social Web Acid Test level 0 and is a user-feature interoperability test for social web functionality defined on 2010-07-18 at FSWS2010.

See:

Contents

Video

Video of SWAT0 being demonstrated:

Summary

The SWAT0 test can be rephrased in IndieWeb terminology, referring to people's own websites rather than "social network" services.

  1. With his phone, Ben Roberts takes a photo of Aaron Parecki, tags him in the photo, and posts it to his site.
  2. Aaron Parecki gets a notification that he's been tagged in a photo.
  3. Kyle Mahan, who is subscribed to Ben Roberts, sees the photo in his reader UI.
  4. Kyle Mahan posts a reply to the photo from this UI, the reply is posted to his site.
  5. Ben Roberts and Aaron Parecki receive notifications that Kyle Mahan has commented on the photo.

mapping to indieweb

The following indieweb mapping of the SWAT0 steps and user flow was demonstrated on 2015-07-12:

  1. With his phone, Ben Roberts takes a photo of Aaron Parecki, tags him in the photo (by person-tagging with http://aaronparecki.com/) , and posts it to his site (which sends a webmention to aaronparecki.com)
  2. Aaron Parecki gets a person-tag mention (a specific form of person mention) notification that he's been tagged in a photo (because his watch buzzes when he is webmentioned), because Ben Roberts's website linked to aaronpk's site with a class of "u-category h-card".
  3. Kyle Mahan, who follows Ben Roberts, sees the photo in his reader. His reader being Woodwind which is pinged by Ben Roberts's PuSH support.
  4. Kyle Mahan, still using Woodwind, posts a reply to the photo on his site. (using micropub)
  5. Ben Roberts receives a notification that Kyle Mahan has commented on the photo, via webmention to Ben Roberts's site about the new comment, which his server sends back to his client device (laptop browser) as a push notification
  6. Aaron Parecki receives a notification of the new comment on a photo he's tagged in:
    1. because Ben Roberts's server, having received the comment, does salmention sending and thus resends a person-tag webmention to Aaron Parecki
    2. then Aaron Parecki's server receives the person-tag webmention and does salmention receiving processing, notices the new comment on the source of the webmention, generates a push notification to aaronpk's client device (phone) that Kyle Mahan has commented on the photo Aaron Parecki is tagged in.

* Note: On 2015-07-12 Kevin Marks commented on Ben Roberts photo nearly the same time (likely before) as Kyle Mahan, also using Woodwind, but signed-in using his Known install on known.kevinmarks.com. However, kylewm is noted in the example above since he wrote all the software he used (Woodwind and Red Wind). (selfdogfood tie-break).

implementation requirements

For the above to work, each of the three participants has some implementation requirements for their indieweb site/service.

Players A, B, C as identified by the tweetable summary:

A must support

  • taking and posting a photo post, with person-tags, or separately person-tagging the photo right after posting, and sending webmentions to all links in that post
  • receiving webmentions from reply posts, and showing them as comments, properly marked up
  • sending a push notification from their server to their client for any webmention
  • salmention sending, that is when their post receives a webmention, they must resend webmentions to any in-reply-to posts and anybody person-tagged (or better, anyone person-mentioned) in their posts

B must support

  • receiving homepage webmentions
  • receiving person-tag mentions in particular
  • passing along received webmentions as specific push notifications to their client device, e.g. that they've been "tagged in a post" and (implied) type of post too, e.g. "tagged in a photo".
  • salmention receiving, that is when receiving a webmention, they must notice the new "comment" on the source of the webmention, and
  • generate a push notification to their client device that someone has commented on the photo they are tagged in.

C must support

  • having a reader with an integrated commenting UI, either directly as part of their site, or as a Micropub client support built into the reader
  • sending a webmention from their site for a reply post to the in-reply-to post

Silo SWAT0

Silo SWAT0 is a variant where one or two people (but not all three) participate entirely inside a silo. The other participant(s) interact with the silo participants via POSSE, backfeed, and silo feed proxies and converters.

SWAT0 revolves around a single post and its responses and notifications, so silo SWAT0 requires that post to exist inside the silo. If A (Ben) is the silo-native participant, the photo post will be published first (and only) inside the silo. If A is a non-silo participant, they must either POSSE or PESOS the photo post.

(The requirements and design for multi-silo SWAT0 are left as an exercise for the reader.)

Here are the requirements for each participant to be outside the silo:

A must support

B must support

C must support


Silo API support

Here's the current status of the major silos' API support for the more unusual features, as of 2015-11-14. Common indieweb silo features like POSSE and backfeeding responses are omitted.

Based on the data below, it looks like Facebook and Flickr could do silo SWAT0, but Twitter, Instagram, and Google+ can't.

POSSE person tags

(originally published here)

backfeed person tags

  • Facebook: yes, via `/photo/tags` (needs testing).
  • Flickr: yes, via `photos.people.getList` etc.
  • Twitter: no. photo people tags aren't exposed in the API.
  • Google+: no. G+ doesn't have person tags distinct from mentions. Google Photos probably does, but it's mostly a separate product now.
  • Instagram: no.

(originally published here)


backfeed mentions

(originally published here)


backfeed responses to person tags or mentions

Mostly the same as the last two items.

  • Twitter: yes for mentions, via search; no for photo people tags, they're not exposed in the API.
  • Google+: kind of for mentions, via search. details in #523. no for tags.
  • Flickr: yes, via `people.getPhotosOf` etc.
  • Facebook: yes for tags, no for mentions.
  • Instagram: no.

(originally published here)

IndieWeb Examples

2015-07-12 B A K

On 2015-07-12 two overlapping sets of IndieWeb community members simultaneously demonstrated SWAT0 as documented that night in:

Players A, B, C (caveats if any in parenthesesl)


2015-11-16/18 Silo SWAT0 on Facebook: R B K

On 2015-07-16 and 2015-11-18, Ryan Barrett, Ben Werdmüller, and Kyle Mahan demonstrated silo SWAT0 on Facebook. A and C were indieweb, B was Facebook-only. Documented in:

Players A, B, C (caveats if any in parenthesesl)


2016-07-29 dobrado SWAT0

Malcolm Blaney made a video demonstrating SWAT0 roles A, B and C using 3 sites all running dobrado.

Misconceptions

Common misconceptions about SWAT0 (have happened often enough to document)

I pass SWAT0

No one individual can "pass" SWAT0, the test requires three different individuals.

Instead: state specifically which role(s) A, B, and/or C, that you are able to perform with your site.

My site or service passes SWAT0

No one site or service can "pass" SWAT0, the test requires at least two (preferably three) different sites or services.

users are on at least 2 (ideally 3) different services

Instead: state specifically which role(s) A, B, and/or C, that user(s) on your site or service can perform. E.g. "my site/software/service can perform SWAT0 roles A,B, and C"

My project passes SWAT0

No one project can "pass" SWAT0, the test requires at least two (preferably three) different codebases:

users are on at least 2 (ideally 3) different services each of which is built with a different code base
(emphasis added)

Instead: state specifically which role(s) A, B, and/or C, that user(s) running your project can perform.

Background

Past iterations, fixes:

fixed

In the development of the indieweb mapping of SWAT0, the following were figured out and/or fixed:

  • How to handle receiving a salmention - when you receive a webmention in-reply-to your post or person-mentioning you, your server must read not only the source post's authored properties, but also any responses like comments (or likes or reposts) that may be children of that post!
  • How/when to send a salmention - when there's any response to your post, you resend webmentions to any post your post is in-reply-to, as well as anyone person-tagged in your post.
  • How to people-tag someone in a photo. Merely linking in a comment/caption to someone is just a mention, not a people-tag (i.e. the difference between @-mentioning someone in an Instagram comment/caption vs. actually tagging the person at a 2D point in the photo with their (…) "Tag People" UI).
    • Flickr supports tagging people in photos without marking a 2D point in the photo. So I'm not sold on requiring a 2D point as part of tagging people in a photo. Aaron Parecki 10:34, 23 September 2014 (PDT)
    • Still to be improved: area-tagging a person-tag - but not needed for SWAT0
  • How does someone receiving a homepage webmention tell the difference between a mere mention (e.g. in a comment/caption) vs. actually being tagged (optionally at a specific point/rect) in a photo post? I.e. we know how to distinguish between a post-mention/reply/RSVP - and hypothetically homepage-mention/invitation. Possibly by detecting that the source's link to your target is on "u-category" or a "u-url" inside a "u-category h-card"?

history

In 2010, not long after the original SWAT0 challenge, the following protocol flow was figured out based on the proposed standards of the time: Activitystreams (Atom/XML), PuSH, Salmon, and Webfinger

SWAT1 brainstorming

A SWAT1 was never specified, however several SWAT1 use cases were proposed for consideration of what could go into a SWAT1.

See Also

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