facebook: v2.0 api no longer allows lookup by username

[snarfed]

...or at least, that's what we think so far. irc discussion. i'm still trying to find an explicit confirmation in their docs. the upgrade guide and platform changelog say the username field was removed from user objects in responses, but nothing about looking up by username.

the problem is that for users with usernames, FB redirects their posts to URLs that use their username instead of their id, e.g. https://www.facebook.com/snarfed.org/posts/10100929680893833 . you can look up and write to some FB posts (like that one) by bare post id, /10100929680893833, but not others, e.g. https://www.facebook.com/ben.werdmuller/posts/10101055597765779 vs /10101055597765779. we don't yet know what causes the difference.

the latter ones work if you prefix the user id, e.g. USERID_POSTID. (username prefix doesn't work.) so we'd need to do that for publish to like/comment on/share them. however, we can't get the user id, so we're hosed. :(

thanks to @kylewm for raising and pinpointing this.

[kylewm]

Some dead ends...

• /me/friends only contains other friends that have authorized the application in question (aside: kind of interesting to see which friends have done this for the API Explorer, mine were an FB employee, a political science researcher, and some general nerds)
• /me/taggable_friends returns a full friends list but with "tokens" only usable for tagging, instead of their IDs
• an unauthenticated call to https://graph.api.com/ben.werdmuller gives his global unique ID, but obviously not the app-scoped one we need.

[snarfed]

here's a radical proposal: switch from the current POSSE model to PESOS. it would take a lot of work, but it would bring a lot of benefits.

...man oh man i wish i had the bandwidth right now to actually implement it!

[kylewm]

So I think I've found a reliable (for now) way to find someone's app scoped user id, but I still can't find a way to access those posts via the API.

An unversioned, unauthenticated call to https://graph.facebook.com/stephanie.rodgers.980 gives their global user ID, then an unversioned, authenticated call to https://graph.facebook.com/4705326 gives a link to https://www.facebook.com/app_scoped_user_id/10100593893240028/

So, I have the user ID now: 10100593893240028. I had hoped that this would mean I could get {user_id}_{post_id} now, but no!

/v2.2/10100593893240028_10100777887638778 /v2.2/10100777887638778

both fail with the same error message.

{
  "error": {
    "message": "Unsupported get request. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api",
    "type": "GraphMethodException",
    "code": 100
  }
}

[snarfed]

so infuriating, huh? regardless, interesting, nice find.

i assume both calls are using the v1 api, since the URLs are unversioned. https://developers.facebook.com/docs/graph-api/reference/v2.1/user/ids_for_business might give us a v2.x alternative for the second part, but I suspect there's still no 2.x way to look up by username. sigh.

[snarfed]

@kylewm and i have been discussing euthanizing facebook liking and commenting entirely. :(

i'm going to collect all the options here, no matter how crazy:

• give up and turn off support for commenting and liking
• post an SO question, include all of our research so far, and attach a big fat bounty
• find a personal connection at facebook and ply them for information
• detect the cases that won't work and report a nice error message saying we can't. not ideal, but maybe ok if those cases are pretty predictable.
• scrape the global (non-app-scoped) user id from the profile page. interestingly, this works for both public and private profiles. an unauthenticated fetch of https://www.facebook.com/snarfed.org (public profile) includes 6 instances of 212038. an unauthenticated fetch of https://www.facebook.com/andigalpern (private profile) still includes one instance of her global user id. i expect the residual global user ids will gradually disappear from the html in both cases, though.
• scrape the object id from the post's html. e.g. right now, an unauthenticated fetch of https://www.facebook.com/andigalpern/posts/678121182314631 doesn't have the object id 100003502653187_678121182314631 exactly, but it does have a number of instances with colon instead of underscore, 100003502653187:678121182314631.

[kylewm]

scrape the global (non-app-scoped) user id from the profile page. e.g. right now, an unauthenticated fetch of https://www.facebook.com/snarfed.org includes 6 instances of 212038. i expect those will gradually disappear, but still.

This wouldn't help us would it? The global user ID doesn't seem to refer to anything inside the API (unless that person has signed up for bridgy prior to the switch to the new API).

[kylewm]

And I think we should definitely post a question to SO either way... for posterity if nothing else. I'll donate 500 karma points or whatever to the bounty :)

[snarfed]

i think we can still use the global user id, or at least get somewhere with it.

first, if i get a bridgy access token in the explorer and look up a global user id, e.g. https://developers.facebook.com/tools/explorer?method=GET&path=100000224384191 , that at least works. second, we just need a user id to attach to the object id to make a composite id that we can comment or like against, right? it seems like it should work. i know, fb api, yeah, right...but i'll try.

[kylewm]

let me know if you have better luck than i did... with user id 1740230476, app scoped id 4494578659463, and post id 10200383182099046, all 3 variations fail :(

/v2.2/10200383182099046 /v2.2/1740230476_10200383182099046 /v2.2/4494578659463_10200383182099046

[snarfed]

here's a bunch more research and observations. this is basically just fodder for an eventual stack overflow question; no really new information or conclusions, sadly.

a couple notes: the graph explorer links here use access tokens that include read_stream. other permissions too, but i think that's the critical one. i'm also going to be using users who haven't installed bridgy, which i think is important...? who knows. :/

• baseline: /v1.0/gina.rossman.50 and /v2.2/gina.rossman.50 both error (#803) Cannot query users by their username. fine.
• gina's global user id is 100000224384191. (and i have technically now violated her privacy. :P) interestingly, /v1.0/100000224384191 and /v2.2/100000224384191 give the same result, including app-scoped id, which isn't available until 2.x. if i switch to a bridgy access token, /v1.0/100000224384191 gives a 1.0-looking user object: lots of profile info, no app-scoped id. so the graph explorer app evidently has v1.0 support disabled. ok. good to know. i'll use bridgy's app in v1.0 graph explorer URLs from here on.
• on to an example post. i'm going to use a simple one: https://www.facebook.com/evan.prodromou/posts/10153023417510505 . key characteristics are that it's public, it's not a share of another post, and most importantly it has no photo(s), which add extra ids and URLs for the individual photo(s) and photo set. evan's profile is also public, ie https://www.facebook.com/evan.prodromou doesn't show the generic This content is currently unavailable like e.g. https://www.facebook.com/barrett.vanessa
• trying the bare post id from that URL, /v1.0/10153023417510505 and /v2.2/10153023417510505 both give the Unsupported get request (code 100) error.
• evan's global user id is 525575504. attaching that as a prefix, /v1.0/525575504_10153023417510505 and /v2.2/525575504_10153023417510505 still both give the same Unsupported get request error. same with /v2.2/10152350676805505_10153023417510505 , which uses his app-scoped user id.
• /v2.2/525575504/posts returns nothing, but /v1.0/525575504/posts returns only two recent posts, this like and this reshare. not sure why only those two, even though has plenty of other recent public posts. the like is fetchable via its id field in both api versions, e.g. /v1.0/525575504_10153045879215505 and /v2.2/10152350676805505_10153045879215505, but both API versions return the Unsupported get request error when fetching the post via its id field, e.g. /v1.0/525575504_351575675029953 and /v2.2/10152350676805505_351575675029953
• trying another public post, this one with pictures: https://www.facebook.com/andigalpern/posts/678121182314631 . /v1.0/100003502653187_678121182314631, /v2.2/100003502653187_678121182314631, and /v2.2/499657186827699_678121182314631 all error.
• /v1.0/100003502653187/posts only includes one post, a like...which makes me think i'm missing an oauth scope, since she has plenty of other public posts, including the example. hrmph.

[kylewm]

SO question posted! http://stackoverflow.com/questions/28337331/facebook-graph-api-find-graph-object-from-post-url

[snarfed]

yay, thank you! fingers crossed!

[snarfed]

we've sadly concluded that our research here is correct, and the way forward is to shut down bridgy publish support for facebook likes and comments. sad day in indiewebland. :/

props and thanks to @kylewm for his help with this!

[julien51]

This is so sad :(

[kylewm]

@julien51 definitely a bummer, but just to be clear facebook backfeed and facebook publish for notes and articles both still work and show no signs of stopping :) there was some confusion about that in the channel yesterday.

[julien51]

Ha! Indeed. But still, it upsets me when APIs are changed/removed unilaterally, but I guess there is a reason for using protocols, rather than APIs!

[petermolnar]

If it helps, I'm using this to import comments/likes, but I do it by post: https://github.com/petermolnar/keyring-reactions-importer/blob/master/importers/keyring-reactions-facebook.php

For me, it worked, but there are glitches.

[snarfed]

thanks @petermolnar! fortunately this bug only killed bridgy publish for FB. backfeed is still working fine.

[kylewm]

hi @petermolnar thanks from me too :) it looks like you're using the /v2.2/USERID_POSTID format to find posts from syndication links. there's two problems that break this approach for bridgy:

1. When replying to a random post on Facebook (e.g. to someone who does not use bridgy), we cannot (by design) find the other user's app-scoped ID
2. USERID_POSTID doesn't work reliably, some post types or some users have a different format that is harder to guess

[snarfed]

re #2, here's an example of code we use to try different id formats and merge the results (!) (:sob:): snarfed/granary@15b633e222e65205df33781d939cdcd20382fa39

[petermolnar]

1. When replying to a random post on Facebook (e.g. to someone who does not use bridgy), we cannot (by design) find the other user's app-scoped ID

I wasn't aware of this earlier but I've read the conversation since. This is genuine madness from Facebook.

1. USERID_POSTID doesn't work reliably, some post types or some users have a different format that is harder to guess

I've noticed that, especially with pretty old entries, like 2009.

To be honest, I'm very close to the point to leave the whole sh*t behind, including Twitter with their ridiculously restricted API.

[snarfed]

huh. here's something interesting in the 2.4 API changelog (search for Declarative Fields):

To try to improve performance on mobile networks, Nodes and Edges in v2.4 requires that you explicitly request the field(s) you need for your GET requests. For example, GET /v2.4/me/feed no longer includes likes and comments by default, but GET /v2.4/me/feed?fields=comments,likes will return the data. For more details see the docs on how to request specific fields.

they've supported the fields param for a while, but afaik it was always optional for all edges before 2.4. bridgy uses 2.2, so it's probably not the root cause of us seeing partial objects...but who knows. plus we'll have to do it eventually anyway!