Yes, they do make it difficult. Keeping an updated set of {(user, repo, capabilities)} is necessary for correctly implementing "iff you can see it in Github you can see it in Devlog". Polling this REST endpoint user-by-user doesn't really work — both architecturally (are you going to poll this endpoint? how frequently?) and pragmatically (the REST API is both much slower and much less stable than the GraphQL API, and pagination works poorly.)
I ended up using the GraphQL API and making a query like this:
query($cursor0: String, $cursor1: String) {
search(query:"org:peterldowns", type: REPOSITORY, first: 100, after: $cursor0) {
pageInfo {
hasNextPage
endCursor
}
repositories: nodes {
... on Repository {
id
name
collaborators(first: 100, after: $cursor1) {
pageInfo {
hasNextPage
endCursor
}
edges {
permission
node {
login
id
}
}
}
}
}
}
}
Removing permissions that are no longer present in this result set is left as an exercise for the reader.
I stopped working on the product so I never implemented the event stream consumer that would let me listen for "this user was removed as a collaborator" or "this team no longer has admin access to that repo". The entire permissioning model for Github is extremely complex and learning about all of its intricacies was half the battle.