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.