Gitea: 조직, 저장소 및 사용자를 위한 연합

연합 리포지토리를 지원하기에 충분할 것입니다.

@kolaente 연합 기능은 사용자에게 명시적으로 의미를 부여합니다. 저장소를 공유하려면 미러 기능을 사용해야 합니다. 그러나 프로젝트 관리자가 다른 git 인스턴스의 사용자를 추가하는 것은 매우 편리합니다.

#184도 참조하십시오(이것과 중복됩니까?)

@strk 종류, 하지만 나는 이것이 더 나아간다고 생각합니다.

@strk 일종의. 그러나 이 문제에는 pull 요청뿐만 아니라 조직을 위한 연합 기능의 완전한 통합이 포함됩니다.

원격 사용자의 권한을 의미합니까?
"연합"을 여러 다른 작은 단위로 나누는 것이 유용하다고 생각합니다.
구현하거나 단일 티켓이 너무 커질 수 있습니다.

@strk 나는 이것을 많은 티켓으로 나누는 아이디어에 동의합니다. 이 티켓은 사용자 연합 티켓일 수 있지 않습니까? 그러나 다른 플랫폼의 사용자에 대한 인증은 원하지 않습니다. 다른 사용자를 추가할 수 있는 기능을 원합니다. 사용자는 사용자의 Gitea 인스턴스에서 초대를 받습니다. 그는 자신의 인스턴스에서 저장소 또는 조직에 액세스합니다.

페더레이션의 누군가에게 권한을 부여하려면 다음을 수행할 수 있어야 합니다.
그 사람을 식별합니다(전체 주소). 당신이 언급한 owncloud 나는
owncloud가 "@"를 식별자로 사용하지만 무엇을
그것을 위해 사용하는 프로토콜. Friendica/GNUSocial 및 기타 OStatus 구현
연맹은 "@"를 통해 다른 것에 매핑
Webfinger 표준(다른
프로토콜). 다른 커뮤니티(IndieWeb 커뮤니티, indieweb.org 참조)는 다음을 사용합니다.
OpenID 버전 2.0까지 사용되므로 사람을 식별하기 위한 웹 주소.
새로운 OpenID(OpenID-Connect)는 Webfinger를 다시 사용합니다.

webfinger 표준이 좋은 해결책이 될 수 있다고 생각합니다. 하지만 사용자의 git 이메일과도 충돌할 수 있다고 생각합니다.

갈등은 어디에 있습니까?

오히려 Webfinger에 대해 싫어하는 것은 제어가 필요하다는 것입니다.
도메인 루트(OpenID URL이 없는).

"어떤 표준을 선택하고 싶습니까?"와 관련하여 W3C의 사회 연합 작업 그룹에서 현재 완료 중인 ActivityPub 을 알려드리고 싶습니다. 이를 구현하는(또는 현재 작업 중인) 일부 프로젝트는 pump.io, Mastodon 및 MediaGoblin입니다.

그들은 고정된 .well-known 경로에 대한 아이디어를 싫어하기 때문에 WebFinger를 사용하지 않지만 상호 운용성에 대한 아이디어가 있습니다.

이 기능은 진정한 게임 체인저가 될 것입니다. keybase.io는 최근에 클라이언트 측 암호화 git과 함께 나왔는데, 그것도 흥미롭습니다.

ActivityPub 이 이제 완료되었음을 지적하고 싶습니다.

AP에 대한 지원을 추가하면 Gitea가 Mastodon, PeerTube, NextCloud 및 HubZilla와 같은 점점 더 많은 연합 서버와 호환되어 GitLab과의 탁월한 차별화 요소는 물론 범위가 상당히 넓어집니다.
또한 대부분은 AP가 탈중앙화 방식으로 허용하는 커뮤니티 풀 리퀘스트 워크플로를 위해 여기에 있기 때문에 오픈 소스 프로젝트를 위한 최고의 호스팅으로서 GitHub를 폐위시킬 가능성이 있습니다. 자유 소프트웨어 커뮤니티의 상당 부분.

어쨌든, 제 희망은 이것이 구현되기를 바랍니다. 혁명적인 잠재력을 가지고 있습니다!

이미 채팅 내에서 언급했듯이, ActivityPub in go는 go와 같은 정적 언어로 하기 어렵기 때문에 PITA입니다.

@tboerger 흥미롭습니다. ActivityPub 사양은 상속이 많은 OO이지만 구조체 임베딩을 사용하여 Go에서 모델링하는 것이 가능해야 하지만 내가 아는 한 Rust에는 serde 같은 것이 없습니다(https://docs.serde. rs/serde_json/value/index.html), 작업을 상당히 단순화하지만 Go에서 ActivityPub을 구현 하기 위한 약간의 노력 이 있습니다. 이는 이미 json-ld 구문 분석을 구현했을 뿐만 아니라 ActivityStreams의 핵심 어휘를 정의합니다.

여기서 어떤 특정한 성가심을 생각하고 있습니까?

@MatejLach 또 다른 프로젝트 https://github.com/go-fed/activity

gogs 저장소의 관련 제안:
https://github.com/gogs/gogs/issues/4437

Gitlab의 저장소에서:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

안녕! 여기에 ActivityPub 공동 편집자가 있습니다. 지금은 꽤 바쁘지만 이런 일이 일어나기를 바랍니다... 질문이 필요하면 언제든지 저에게 핑을 보내거나 irc.w3.org의 #social에서 질문하세요.

@jas99가 언급한 https://github.com/go-fed/activity 라이브러리와 관련된 질문/우려/코멘트가 있는 경우 Mastodon에서 저에게 연락하는 것을 주저하지 마십시오. 나는 분명히 결정의 결과에 기득권이 있지만 go+ActivityPub 교차로에서 일한 경험에 대한 솔직한 정보를 기꺼이 제공하고 싶습니다. 나는 Go에서 ActivityPub을 구현하는 것이 가파른 절벽이라는 @tboerger 의 말에 동의합니다.

index 라는 새 저장소를 만들고 새 도메인 index.gitea.io를 설정하여 그렇게 할 수 있을까요?

인덱스 서버가 필요한 이유는 무엇입니까? @lunny

ActivityPub 프로토콜의 일반적인 구현에 대해 논의하는 다른 프로젝트를 가질 수 있다면 정말 좋을 것입니다(즉, 동사에 대해 동일한 확장 사용 등). 이를 통해 페더레이션이 원활하게 논의할 수 있는 다양한 소셜 미디어 플랫폼의 사용자처럼 gitea, gogs 및 gitlab 사용자가 원활하게 함께 작업할 수 있습니다.

이곳이 아닐까요? -> https://github.com/git-federation/gitpub

@jaywink 좋은 생각입니다!

이것은 놀라운 것입니다! @JonasFranzDEV가 제안한 것처럼 Nextcloud (/Owncloud)는 이것이 이상적인 구현과 어떻게 작동할 수 있는지에 대한 완벽한 예라고 생각합니다.

Nextcloud를 사용하면 다른 인스턴스의 사용자와 폴더를 공유하려는 경우 쉽게 공유 폴더를 두 인스턴스에 걸쳐 설정할 수 있습니다.

내 Gitea 인스턴스에서 호스팅되는 리포지토리에 대해 그렇게 할 수 있다면 다른 연합 인스턴스의 사용자에게 리포지토리에 대한 액세스 권한을 부여하면 해당 리포지토리가 문제 등과 상호 작용할 수 있는 완전한 기능으로 Gitea 인터페이스에 표시됩니다( 이 리포지토리가 다른 인스턴스에서 호스팅되었다는 UI), 꽤 놀랍습니다.

Gitea와 다른 오픈 소스 자체 호스팅 프로젝트(예: GitLab CE) 간에 공유 표준을 채택하기 위해 논의 중인 목표는 확실히 의미가 있으며, 이것이 채택되어 Gitea, Gogs, GitLab 등의 연합을 허용한다면 좋을 것입니다. 비공개 프로젝트를 위해 GitHub에서 마이그레이션하는 것은 큰 손실 없이 간단하지만 공개 오픈 소스 프로젝트의 경우 GitHub의 큰 이점이 커뮤니티라는 점을 인정해야 합니다. GitHub에서 실제로 많은 프로젝트를 발견했습니다. 인기 있는 프로젝트를 연합할 수 있는 방법이 있다면 사용자 활동 피드(즉, 다른 인스턴스에서 친구를 팔로우하고 활동을 팔로우할 수 있고 프로젝트를 좋아하고 개인 정보 설정을 고려하는 등)가 가능하다면 훌륭할 것입니다.

연합 풀 리퀘스트는 이에 대한 훌륭한 첫 단계가 될 것이며(#184) 현재 가장 중요한 누락 기능일 것입니다.

여기 마지막 댓글 이후 11개월.. 아직 계획이 있는지 궁금합니다.

예보다 합의된 어떤 종류의 표준이 있을 때

현재 논의는 위조된 프로젝트의 일부로 진행 중이므로 더 자세히 알고 싶다면 다음을 따르십시오: https://github.com/forgefed/forgefed

@lafriks 가 언급했듯이 일단 합의된 표준이 있으면 다양한 프로젝트에서 이를 구현할 수 있습니다.

위조된 프로젝트의 올바른 URL은 이제 https://notabug.org/peers/forgefed 입니다.

github이 현재 전체 국가에서 ppl 계정을 제거하고 있다는 점을 고려하면 이것이 지금 가장 중요해야 할 것 같습니다.

ForgeFed에는 이제 토론 포럼 도 있습니다. Gitea의 누군가를 참여시키는 것이 좋습니다.

이것에 대해 +1. 로컬 자체 호스팅 인스턴스에서 작업하지만 그 선택으로 인해 격리되지 않는 것이 진정으로 두 세계의 최고가 될 것입니다.

ForgeFed 작업 그룹 은 의견을 제공할 현재 위조의 개발자가 절실히 필요합니다. https://talk.feneas.org/t/working-group-instructions/196

Microsoft가 Github에서 대규모 마이그레이션을 시작하기 전에는 이것이 킬러 기능이 아니었을 것입니다... 이제 그렇습니다. 내가 연구하고 있는 OS 프로젝트에 대한 저장소의 수가 점점 줄어들고 있습니다. 현재 Github에 있습니다(여기에 미러링될 수도 있음).

나는 Github 커밋 히스토리가 이력서처럼 읽을 수 있고 소프트웨어 세계가 커리어 모바일인 이유 중 하나는 사람이 귀중한 기술을 스스로 가르칠 수 있고 쉽게 시연할 수 있기 때문이라고 읽었습니다(공개 github 히스토리). 더 나은 수입 등을 받을 자격이 있습니다. 기여 기록이 수십 개의 개인 서버에 분산되어 있으면 훨씬 덜 가시적이거나 유용하지 않습니다.

또한 이러한 서버 중 하나가 언제든지 다운될 수 있으며 기록의 해당 부분은 이제 사라졌습니다. 연합 리포지토리의 적절한 구현은 내가 수십 개의 인스턴스(내 인스턴스에서)에 대한 수십 개의 프로젝트에 참여할 수 있음을 의미하며 모두 중단되더라도 여전히 내 '연합 git 프로필'을 보유하게 됩니다.

ForgeFed 로드맵에 연결(작업할 사람들을 위한 자금 지원):

https://notabug.org/peers/forgefed/issues/87

아마도 간단한 구현을 위해 gitea는 로컬 저장소 파일을 호스팅하는 백그라운드에서 ipfs 노드를 실행할 수 있습니다( ipns 를 사용하여 저장소의 최신 버전을 가리킴). 그런 다음 다른 gitea 인스턴스를 찾고 ipns 해시 및 예비 데이터(별, 이름)를 얻기 위해 간단한 가십 프로토콜을 구현할 수 있습니다.
ipfs를 사용하면 한 인스턴스의 사용자가 다른 인스턴스의 리포지토리를 보거나 분기하려는 경우 해당 리포지토리의 일부를 호스팅하는 데 기여하고 네트워크 전체에서 리포지토리에 더 빠르게 액세스할 수 있다는 이점이 있습니다.

ipfs/ipns를 사용하면 별표 표시된 리포지토리, 풀 요청, 바이오 등과 같은 사용자 데이터를 배포하는 데 사용할 수도 있습니다. 각 노드는 인스턴스가 관심을 갖는 다른 네트워크의 사용자에 대한 이름 및 ipns 해시만 저장하며 요청하는 것은 간단합니다. 알 수 없는 사용자의 프로필 데이터.

ipfs에는 이미 go 구현 이 있으며 예를 들어 이와 같은 검색을 사용할 수 있습니다.

여기에는 피어 투 피어 스토리지에 대한 요구 사항이 없습니다. 귀하가 설명하는 내용은 당면한 문제와 관련이 없거나 필요하지 않은 것 같습니다. Git 스토리지 형식 및 전송 프로토콜에서 벗어나는 데 관심이 없다고 생각합니다. 여기에 이점이 있는 경우 별도의 문제를 열어야 할 수도 있습니다(저는 확실히 그렇지 않습니다).

여기에는 피어 투 피어 스토리지에 대한 요구 사항이 없습니다.

gitea는 리포지토리의 P2P 공유를 통해 큰 이점을 얻을 수 있으므로 인스턴스가 다운되는 경우 인기 있는 리포지토리가 중복될 수 있습니다. 누군가 자신의 인스턴스에 리포지토리를 미러링할 수 있지만 커밋할 중앙 위치가 없으면 프로젝트 개발이 단편화됩니다. git 프로토콜이 IPFS에 계층화된 경우 단일 인스턴스에서 프로젝트를 분기할 때 중복 제거를 허용하므로 전체 복사본을 저장할 필요가 없습니다.

당신이 설명하는 것은 필요하지 않거나 당면한 문제와 관련이 없는 것 같습니다.

페더레이션이 매우 유용한 이유(그리고 사람들이 페더레이션을 원하는 이유)는 인스턴스 간에 협업이 가능하기 때문입니다. IPNS(InterPlanetary Name System)는 특정 데이터(예: 저장소 및 개인 프로필)를 업데이트할 권한이 있는 사용자를 식별하는 데 사용할 수 있기 때문에 OpenID와 동일한 동작을 합니다. IPNS 주소는 해당 사용자를 특정 인스턴스에 연결할 필요 없이 다른 인스턴스에서 사용자를 고유하게 식별할 수 있습니다. 예를 들어 보겠습니다.
Alice는 aliceland.net에서 gitea 인스턴스를 자체 호스팅하고 있습니다.
Alice가 새 계정을 만들 때 gitea는 빈 프로필을 만들고 IPFS에서 호스팅한 다음 해당 프로필을 가리키는 고유한 IPNS 주소를 생성합니다. Alice가 새 저장소를 만들거나 어떤 식으로든 프로필을 업데이트할 때마다 gitea는 (뒤에서) 새 IPFS 레코드를 만들고 이전 레코드를 고정 해제하고 Alice의 IPNS 주소를 여기에 다시 할당합니다.
이제 Bob이 bobland.net의 저장소 미러에서 aliceland.net으로 병합 요청을 제출하려고 한다고 가정해 보겠습니다.
Bob이 원래 Alice의 저장소를 bobland.net에 포크할 때 Alice 저장소의 IPNS와 그가 분기한 커밋의 IPFS 위치를 기록했습니다.
Bob이 병합 요청을 열려고 할 때 그는 메시지를 작성하고 bobland.net은 IPFS 블록에 다음 항목을 넣습니다.

• 밥의 IPNS 사용자 주소
• Bob이 가져오려는 커밋의 IPFS 주소
• 수정해야 하는 Alice의 저장소에 있는 커밋의 IPFS 주소
• 병합 요청에 대한 Bob의 메시지 및 제목
• Bob의 개인 IPNS 프로필 키로 데이터 서명

그런 다음 Bobland.net은 IPFS 주소를 aliceland.net으로 보내어 이를 완전히 무시하거나 주소를 구문 분석하고 커밋을 확인하고 주석 스레드(모든 주석을 가리키는)에 대한 IPNS 주소를 생성한 다음 알릴 수 있습니다. Alice는 Bobland.net 인스턴스의 Bob이라는 사람이 IPFS를 통해 3개의 커밋에 대한 병합 요청을 보냈습니다. 주석은 또한 IPFS를 통해 호스팅되고 IPNS 주소를 통해 액세스할 수 있습니다.
변경 가능한 데이터(예: 주석 스레드)에 대해 IPNS를 사용하고 변경 불가능한 데이터(예: 주석 및 커밋)에 대해 IPFS를 사용하는 이 패턴은 대부분의 인스턴스 간 연합에 적용될 수 있습니다.

Git 스토리지 형식 및 전송 프로토콜에서 벗어나는 데 관심이 없다고 생각합니다.

연합에 대한 이 접근 방식은 Git 형식에서 멀어질 필요가 없습니다. Git은 단순히 계층화되어 ifps에 저장될 수 있습니다 (중복 제거도 활용함). Git의 Merkle Tree 시스템은 반드시 IPFS와 통합될 필요는 없으며(멋지긴 하지만) git 전송 프로토콜은 여전히 ​​동일할 것입니다. IPFS는 인스턴스 간의 통신을 조정하기만 하면 됩니다.

그냥 별도의 문제를 열 ​​수 있습니까? 이것은 특정한 것에 관한 것이며 ForgeFed는 이미 프로토콜에 대해 작업하고 있습니다. 더 나은 아직, 그들과 함께 가져옵니다.

"ipfs/filecoin/blockchain은 어떻습니까?"와 같은 주석으로 문제를 쌓는 것은 무례한 것처럼 보입니다.

+1

GitLab은 이 기능에 대해서도 논의하고 있습니다: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

나는 참고로 며칠 전에 gitea dev discord에 대해 핑을 보았고, go-fed v1이 완료되고 문서화되면서 ForgeFed 뒤에 있는 사람들에게 사전에 연락하려고 했습니다. 인스턴스를 얻는 것이 좋을 것입니다. 비록 작은 노력은 아니지만 ActivityPub에 연합된 gitea의. 나는 gitea 사람들이 다른 우선순위 atm으로 바쁘다고 생각합니다. 불행히도 저는 ForgeFed 직원을 확보하는 데 성공하지 못했습니다. :(

APConf2020에서 나온 ActivityPub 커뮤니티의 우리 중 일부는 gitea 인스턴스에서 풀뿌리 경량 문서 프로세스를 실험하고 있으며 아직 연합할 수 없다는 것이 이상하게 느껴집니다.

Git은 이미 탈중앙화 미러링에 필요한 모든 기능을 가지고 있습니다. 유일한 기능은 이를 조정하는 데 필요한 기능뿐입니다. 이것이 바로 ForgeFed가 하는 일입니다. IPFS는 여기에 있을 필요가 없으며 메인넷 출시가 얼마나 비참하게 진행되었는지 고려할 때 Protocol Labs의 다른 프로젝트와 긴밀하게 연결되는 것이 안전한지 확신할 수 없습니다.

기존 이니셔티브에 대해 협력하는 데 관심이 있습니다. 작업 그룹을 함께 구성하려고 합니다. 추가 토론을 위해 이 Matrix 채널을 제안할 수 있습니다. #n oteworthy:tincan.community