add GitHub support

[snarfed]

...specifically, publish for POSSEing issues and issue comments and backfeed for issue comments. (anything else?)

of all the "add silo X" feature requests we have, this is the one i'd use, and use a lot. i don't expect to implement it anytime soon, but i'd love to use it!

(#326 - Instagram publish support for likes - is maybe the one other i'd use, but we already support IG backfeed, so it only half counts. :P)

[snarfed]

(for posterity, i currently back up my github issues with https://github.com/snarfed/misc/blob/master/export_github_issues.py )

[aaronpk]

Plain text posts could be POSSEd to github as a Gist!

[aaronpk]

I've done some experimental POSSE to GitHub, and have found the following patterns useful:

If no in-reply-to property, then create a gist.

If in-reply-to matches:

• /https:\/\/github\.com\/.+\/.+(?:\/issues)/: open a new issue. Use the "name" of the h-entry as the issue name. If no name present, try to construct one from the first sentence of the entry content.
• /https:\/\/github\.com\/.+\/.+\/issues\/\d+/: reply to an issue thread

[tantek]

Suggested title edit: Bridgy Publish to Github: note->gist, reply-> issues/ or issues/n

And let's create a separate issue for the Bridgy backfeed feature request - useful all on its own since people are already manually or otherwise POSSEing their own stuff to Github.

[snarfed]

if anyone's interested in tackling this, i've written up comprehensive instructions on how to add a new silo to bridgy. feel free to jump in!

[snarfed]

starting to think about this again...

[snarfed]

@tantek wants (plans?) this for himself this year: http://tantek.com/2018/015/t1/made-destination-figured-out-newwwyear

[snarfed]

some of what we need is in the v4 API:

• addComment
• addReaction, removeReaction
• addStar, removeStar
• fetch issues, comments, labels, reactions

some is currently only in v3:

• create issue (on the roadmap for v4)
• edit issue

some i didn't see anywhere:

• close/reopen an issue (on the roadmap for v4)

[snarfed]

particularly interesting: the v3 API has webhooks for many events we care about for backfeed! e.g. new issue comments. not for reactions though.

...except they're per repo, not per user. that may make this a non starter. :( i could have bridgy register a webhook on every repo the user owns, but even then, it would need to detect new repos regularly (maybe via another webhook? 😂 😭) and add itself to them too. ugh.

[snarfed]

big open question for backfeed: is a bridgy github account a repo? or a user? ie would it poll just a single repo for backfeed, or all of the user's repos? not sure either is obviously the right answer.

[EdwardHinkle]

For my use case, a bridgy github account would be a user. I would want responses on ALL my repos to backfeed

[snarfed]

@EdwardHinkle you'd probably want responses from outside your own repos too, right? eg if you file an issue on someone else's repo, and they reply.

[EdwardHinkle]

I hadn’t thought that through, but yes, that’s how I would want it to operate. Especially having been posting in the Microsub repo issues today, I can see having wanted to backfeed those

[snarfed]

one interesting question is whether there's a reasonable and scalable way to fetch all of a user's recent issues or comments, across all repos. maybe User.issues and/or .issueComments?

[snarfed]

yay, those seem to work. e.g. this gets the last 10 issues a user created, across all repos:

query { 
  viewer { 
    issues(last:10) {      
      edges {
        node {
          id url
        }
      }
    }
  }
}

issueComments and pullRequests get the last 10 comments and PRs, respectively.

issues on the users' repos aren't quite as straightforward. this query does it, but only for 100 repos. to look at more, we'd need to make multiple API calls.

query {
  viewer {
    repositories(last: 100) {
      edges {
        node {
          issues(last: 10) {
            edges {
              node {
                id
                url
              }
            }
          }
        }
      }
    }
  }
}

[snarfed]

thinking about the v4 API's 5000 points/hr rate limit now. i'm not sure, but afaict it seems to be per app, per user, which is problematic for scaling.

if i estimate a poll will cost ~22 points (more on that later), and i poll hourly, that sets a scaling celing of ~227 github accounts. beyond that, i have to start dropping poll frequency. :( maybe they expect to talk to individual apps once they get big and raise their limits individually? who knows.

[EdwardHinkle]

Let’s see if a reply to this thread works!

[miklb]

in #dev star/liking a repo was suggested to be added a Feature request. Would a separate issue be helpful? I would assume it would be similar to how silo.pub considers a like of repo URL. Or am I conflating two different things?

[snarfed]

@miklb that's it! no new issue needed, it's on the list.

[snarfed]

(circling back, i shipped starring support this past weekend.)

[tantek]

The “Authorize Bridgy” prompt page has a big green button that says to “Authorize snarfed” which seems a bit incongrous.

It would be better for branding/trust reasons if this prompt for Bridgy could use the github.com/bridgy organization, and thus show a button named “Authorize bridgy” instead.

(Originally published at: http://tantek.com/2018/050/t1/authorize-bridgy-prompt)

[snarfed]

^ fixed the auth prompt, thanks again @tantek for acquiring the @bridgy org! example prompt below. the real one has the real logo and omits "local."

[snarfed]

ok, first pass is pretty complete. publish to github supports issues, comments, reactions, and repo stars. backfeed supports comments and reactions. docs:

• https://brid.gy/about#which
• https://brid.gy/about#publish-types

there are still bugs to fix, and backfeed is best effort (and may be for the foreseeable future), but i think i'm comfortable closing this now. if anyone disagrees, feel free to holler.