backfeed person tags (especially on photos) to the original posts

[tantek]

On typical photo silos that you can POSSE to (Facebook, Flickr), in addition to liking & commenting your friends can tag people they know in those posts.

On Instagram, you can add person-tags to your photos after the fact as well as during posting.

Bridgy should backfeed these silo person-tagging interactions just as it backfeeds comments for reasons that are helpful to the publisher particularly for photos:

https://indiewebcamp.com/photo#backfeed_person_tags

Originally requested: http://indiewebcamp.com/irc/2015-09-01#t1441140760078

Bridgy can do this by creating synthetic tag-reply posts (similar to reply posts), with "tag-of" markup and person-tag "u-category h-card" markup as documented here:

https://indiewebcamp.com/tag-reply
https://indiewebcamp.com/person-tag

And then send a webmention back to the original post like the existing Bridgy backfeed support.

[tantek]

If it's possible for Bridgy to figure out silo profile userid -> indieweb URL for each person-tag, that would be even better. A couple of thoughts:

• Bridgy could use its own database of Auth'd in users from those silos to determine what their indieweb site it
• Bridgy could do rel=me discovery on the silo profile to figure out their indieweb site (and perhaps cache that?)

This would be above and beyond just supporting backfeeding of person-tags, hence separate comment.

It might also be reasonable to put all the burden (freedom of choice) of converting a silo profile URL (e.g. FB/Flickr profile) to the indieweb equivalent. Capturing both possibilities here for consideration.

[snarfed]

👍 thanks for filing!

re discovering indieweb urls, you pretty much covered it. twitter, google+, and instagram actually all let you fetch anyone's profile via API, so we'd only have to do rel=me discovery for facebook. (not sure about flickr.)

[snarfed]

current silo support::

• Facebook: yes
  , via /photo/tags (needs testing) and tagging_user.
• Flickr: yes, via photos.people.getList etc.
• Twitter: no. photo people tags aren't exposed in the API (as of Aug 2019).
• 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.

[snarfed]

one interesting wrinkle here is that we'd want to distinguish between the user's own tags and tags created by other people. ideally we would only backfeed the latter.

... except i suspect the APIs may not differentiate between them. I'll find out.

[snarfed]

yay, Facebook tells us, but i haven't yet found a way to determine a tag's creator in Flickr, either in photos.people.getList or nearby. @kylewm can you confirm?

[kylewm]

I think you're right, I don't see a way to see who created a tag in the Flickr API

[kylewm]

approaching from another direction you could poll flickr.people.getPhotosOf and backfeed any new photo of a person that comes from another account.

[snarfed]

https://indiewebcamp.com/tag-reply doesn't have any indieweb examples. it's possible that no one consumes u-tag-of yet.

[tantek]

@snarfed re:

we'd want to distinguish between the user's own tags and tags created by other people. ideally we would only backfeed the latter.

I think I disagree. Even if you @-reply to your own tweet, you get backfed the @-reply.

Similarly, if you person-tag your own POSSE copy of a photo, you should get backfed the tag-reply.

no one consumes u-tag-of yet.

Unfortunately not. I'm not sure how to bootstrap this as a publisher.

[tantek]

Added sentence in the issue description about being able to add person-tags to your Instagram photos after the fact, as another case where you would want the person-tags backfed to your original photo post.

[tantek]

Slight issue name tweak to indicate specific scope of backfeeding to posts

[snarfed]

Looking at this again. Flickr's API now gives us each tag's author, which helps.

@tantek, I was unclear earlier (above) when I wanted to distinguish tags from the photo's author vs from other people. My actual motivation was to distinguish the original tags published with the photo, which (I expect) we shouldn't backfeed, from tags added later, which we should. Sadly I don't see a way to do that in the API.