Let's move to somewhere outside of GitHub about forgefed HOT 4 CLOSED

We tried using our accounts from each of our own individually self-hosted Gitlab / Gogs / Gitea to collaborate on a repo belonging to a totally different self-hosted server. All without having to register on that other server.

We can solve this problem before completing this project. Unfortunately, solving this problem completes this project. So we can't solve the problem before completing this project.

Sorry that I don't have any serious insight here, but I do appreciate you giving me the freedom to play with the hypocrisy / irony / chicken-and-egg problem a little bit in this lighthearted response.

I realize there's the serious question of "why not X" for X != Github. I am not aware of any serious discussion that happened on this topic.

from forgefed.

I came here to file an issue about handling the federated identity management problem (and noting how difficult that is without authenticated access to email addresses as a federated identifier), but given @cjslep's response above, I think this issue can serve that purpose :)

The first paragraph in the "How it works" section of https://docs.gitlab.com/ee/user/project/import/github.html gives the gist of the problem: in order for repos to map identities correctly, users currently either have to make their email addresses on each service public, or else authenticate with the importing service before the import happens.

Neither GitLab nor anyone else currently models the notion of an "unclaimed pseudonym" to track activity where a user ID on a remote service is known, but that remote identity isn't yet mapped to a local identity in a way that verifies that the same human is plausibly in control of both accounts.

from forgefed.

@ncoghlan I vouch for filing your issue as a separate one. This one is just nonconstructive.

from forgefed.

Will handle this with #5 discussion. Close for now.

from forgefed.