SWAT0 is an abbreviation for The Social Web Acid Test level 0, a user-feature interoperability test for social web functionality defined on 2010-07-18 at FSWS2010, and most recently demonstrated passing with IndieWeb examples live at IndieWebCamp 2015.
- description of SWAT0 on W3.org.
- Tweet version: http://tantek.com/2015/029/t1/swat0-posts-tags-mobile-photo-comment and 
Video of SWAT0 being demonstrated:
The SWAT0 test can be rephrased in IndieWeb terminology, referring to people's own websites rather than "social network" services.
- With his phone, Ben Roberts takes a photo of Aaron Parecki, tags him in the photo, and posts it to his site.
- Aaron Parecki gets a notification that he's been tagged in a photo.
- Kyle Mahan, who is subscribed to Ben Roberts, sees the photo in his reader UI.
- Kyle Mahan posts a reply to the photo from this UI, the reply is posted to his site.
- 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:
- 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)
- 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".
- 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.
- Kyle Mahan, still using Woodwind, posts a reply to the photo on his site. (using micropub)
- 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
- Aaron Parecki receives a notification of the new comment on a photo he's tagged in:
- because Ben Roberts's server, having received the comment, does salmention sending and thus resends a person-tag webmention to Aaron Parecki
- 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). (eat what you cook tie-break).
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 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. It was first demonstrated on 2015-11-16 (full writeup with screenshots).
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
- backfeed person tag to a front page (like a homepage)
- backfeed responses to person tags
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.
- Facebook: yes. POST to `/user/feed` and set the `tags` param to a comma separated list of FB user ids. needs the `user_friends` permission and maybe the Taggable Friends API. Details.
- Flickr: yes. using the `photos.people.add` endpoint. we'd need to do #432 (publish support) first though.
- Twitter: no. they're called photo or people tags. nothing in the uploading media or `statuses/update` docs, doc searches, or forum searches or posts.
- Instagram: no, since the API is mostly read only. you can't post pictures or tags.
- Google+: no, since the API is read only.
- 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.
- Twitter: yes, via search. we already do this to walk reply chains.
- Google+: kind of. i tried `activities/search` for finding the _+Trisha Weir_ mention in this post. it didn't work with `"+Trisha Weir"`, `+Trisha Weir`, `https://plus.google.com/+TrishaWeir`, or `https://plus.google.com/106299364027673376307`, but it did work with `"Trisha Weir"`. that query will technically return posts that just have people's names without mentioning them, which means we'll get some false positives, but maybe in practice that's ok. not sure.
- Flickr: no. Flickr only has people tags (#488), not mentions.
- Facebook: no. Not via notifications: They can only be read for pages, not for users. A number of other endpoints look promising, but don't pan out. Google doesn't find much either. and FB removed search from the API in v2.0 (see #456).
- Instagram: no. search is just for location, not text query.
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.
The following are indieweb examples of passing SWAT0 according to all the requirements, including, especially the requirement to use three different sites running three different projects.
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:
- Congratulations first indieweb SWAT0 demo! and
- User flow and permalinks from IndieWeb SWAT0 achievement.
- Video: Live demo of #SWAT0 at IndieWebCamp 2015 (93 seconds)
Players A, B, C (caveats if any in parenthesesl)
- Ben Roberts, Aaron Parecki, Kevin Marks (using a secondary site of his)
- Ben Roberts, Aaron Parecki, Kyle Mahan
If you an get one or more roles working with your projects/site, but are unable to demonstrate it interoperating with two other different projects and sites, then add yourself here (including which roles you can support).
While not considered "passing" SWAT0 (even if you can do all three roles), you should still add yourself here (yyyy-mm-dd shortname roles-you-can-do) if you think you could pass with two other projects/sites, and try to connect with two of the folks listed above to do a demo together.
2016-07-29 dobrado A B C
Malcolm Blaney made a video demonstrating SWAT0 roles A, B and C using 3 sites all running dobrado.
Mixed Silo IndieWeb Examples
2015-11-16/18 Silo SWAT0 on Facebook: R B K
On 2015-11-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:
- Silo SWAT0 on Facebook (with step by step screenshots)
Players A, B, C (caveats if any in parenthesesl)
- 2015-11-16: Snoopy Barrett (driven by Ryan Barrett), Ryan Barrett, Kyle Mahan
- 2015-11-18: Ryan Barrett, Ben Werdmüller, Kyle Mahan
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
Instead: state specifically which role(s) A, B, and/or C, that user(s) running your project can perform.
Past iterations, fixes:
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"?
- This is described on person_mention#How_to_distinguish_person_mentions
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
A SWAT1 was never specified, however several SWAT1 use cases were proposed for consideration of what could go into a SWAT1.