Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add GitHub support #333

Closed
snarfed opened this issue Jan 3, 2015 · 23 comments
Closed

add GitHub support #333

snarfed opened this issue Jan 3, 2015 · 23 comments
Labels

Comments

@snarfed
Copy link
Owner

@snarfed snarfed commented Jan 3, 2015

...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
Copy link
Owner Author

@snarfed snarfed commented Jan 3, 2015

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

@aaronpk
Copy link
Contributor

@aaronpk aaronpk commented Jul 23, 2015

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

@aaronpk
Copy link
Contributor

@aaronpk aaronpk commented Jul 23, 2015

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
Copy link
Contributor

@tantek tantek commented Jul 23, 2015

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
Copy link
Owner Author

@snarfed snarfed commented Dec 8, 2015

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
Copy link
Owner Author

@snarfed snarfed commented Jan 2, 2016

starting to think about this again...

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jan 17, 2018

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

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jan 17, 2018

some of what we need is in the v4 API:

some is currently only in v3:

some i didn't see anywhere:

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jan 17, 2018

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
Copy link
Owner Author

@snarfed snarfed commented Jan 17, 2018

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
Copy link

@EdwardHinkle EdwardHinkle commented Jan 30, 2018

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

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Jan 30, 2018

@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
Copy link

@EdwardHinkle EdwardHinkle commented Jan 30, 2018

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
Copy link
Owner Author

@snarfed snarfed commented Jan 31, 2018

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
Copy link
Owner Author

@snarfed snarfed commented Jan 31, 2018

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 added a commit to snarfed/oauth-dropins that referenced this issue Feb 3, 2018
@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 7, 2018

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
Copy link

@EdwardHinkle EdwardHinkle commented Feb 9, 2018

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

@miklb
Copy link

@miklb miklb commented Feb 9, 2018

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
Copy link
Owner Author

@snarfed snarfed commented Feb 10, 2018

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

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 13, 2018

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

@tantek
Copy link
Contributor

@tantek tantek commented Feb 20, 2018

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
Copy link
Owner Author

@snarfed snarfed commented Feb 22, 2018

^ 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."

github_bridgy_org_auth

@snarfed
Copy link
Owner Author

@snarfed snarfed commented Feb 22, 2018

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants