Provide follower info in user API?

[shesek]

It would be great if you could add information regarding the users' followers to the GET /user/lookup API endpoint (useful for us at Bitrated for the integration we recently added). Cheers!

[shesek]

I'm scraping it from the HTML for now (hope that's okay?). In case anyone finds that useful:

request = require 'superagent'
cheerio = require 'cheerio'
iferr   = require 'iferr'

FOLLOWER_SELECTOR = '#profile-tracking-section > .row:first-child > .kb-main-card > .row:first-child > .trackers-col h4'
FOLLOWER_REGEX    = /Followers \((\d+)\)/

# hack, this is not available via the API yet
# https://github.com/keybase/keybase-issues/issues/2862
load_follower_count = (kb_user, cb) ->
  request (get_url kb_user), iferr cb, (res) ->
    return cb new Error 'expecting 200 OK' unless res.status is 200
    $ = cheerio.load res.text
    cb null, +$(FOLLOWER_SELECTOR).text()?.match(FOLLOWER_REGEX)?[1]

get_url = (username) -> "https://keybase.io/#{ encodeURIComponent username }"

[malgorithms]

this is undocumented, so there is a small chance we may change it without warning, but I think you'll find it way faster than cheerio'ing a big ass page:

https://keybase.io/_/api/1.0/user/card.json?username=chris

If you're ok with a small risk someone on the team changes it without warning, go for it. As for possible changes, I notice that the mtime isn't a unix timestamp, which we usually use for timestamps in our JSON....so, uh, don't assume that'll stay the same.

[shesek]

Awesome, thanks! :-) This is definitely better than parsing HTML, which is far more likely to change in a way that breaks my parser (especially since the best selector I could come up with involves nth-child(-like) pseudo-classes...).

[coldwaterq]

I am trying to find the actual following and followers users. Instead of calling HTTP over and over I am trying to use the "keybase list-followers" and "keybase list-following", but that doesn't have a "gas" like the keybase chat api does so I am affraid I may be making to many requests. Is there a friendlier way I could implement this?