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

Comments

Projects
None yet
5 participants
@snarfed
Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Contributor

aaronpk commented Jul 23, 2015

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

@aaronpk

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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 snarfed added new silo and removed listen publish labels Nov 2, 2015

@snarfed

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

snarfed commented Jan 2, 2016

starting to think about this again...

@snarfed

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

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

This comment has been minimized.

Owner

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

This comment has been minimized.

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

EdwardHinkle commented Feb 9, 2018

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

@miklb

This comment has been minimized.

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

This comment has been minimized.

Owner

snarfed commented Feb 10, 2018

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

@snarfed

This comment has been minimized.

Owner

snarfed commented Feb 13, 2018

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

@tantek

This comment has been minimized.

Contributor

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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