Gitea: Federasi untuk organisasi, repositori, dan pengguna

Mungkin akan cukup untuk mendukung repositori federasi

@kolaente Fitur federasi secara eksplisit masuk akal bagi pengguna. Jika Anda ingin berbagi repositori, Anda harus menggunakan fitur mirror. Tetapi akan sangat nyaman bagi manajer proyek untuk menambahkan pengguna dari instance git lainnya.

Lihat juga #184 (apakah ini duplikatnya?)

@strk agak, tapi saya pikir ini lebih jauh

@strk Jenisnya. Tetapi masalah ini mencakup integrasi penuh fitur federasi untuk organisasi tidak hanya untuk permintaan tarik.

Maksud Anda untuk otorisasi pengguna jarak jauh?
Karena saya pikir itu berguna untuk membagi "federasi" di banyak kecil yang berbeda
hal-hal untuk diterapkan, atau satu tiket akan menjadi terlalu besar.

@strk Saya setuju dengan ide untuk membagi hal ini menjadi banyak tiket. Tiket ini mungkin tiket federasi pengguna bukan? Tetapi saya tidak ingin otentikasi untuk pengguna platform lain. Saya ingin kemampuan untuk menambahkan pengguna lain. Pengguna akan menerima undangan dari instance Gitea pengguna. Dia akan mengakses repositori atau organisasi dari instance-nya.

Memberikan izin kepada seseorang dalam sebuah federasi membutuhkan kemampuan untuk
mengidentifikasi seseorang itu (alamat global). Seperti yang Anda sebutkan owncloud I
pikir owncloud menggunakan "@" sebagai pengenal, tapi aku tidak tahu apa
protokol yang digunakannya untuk itu. Friendica/GNUSocial dan implementasi OStatus lainnya
federasi juga dapat menggunakan "@" memetakan ke sesuatu yang lain melalui
standar Webfinger (yang terbuka untuk memungkinkan untuk menentukan yang berbeda
protokol). Komunitas lain (yang IndieWeb, lihat indieweb.org) menggunakan
alamat web untuk mengidentifikasi orang, seperti yang digunakan dengan OpenID hingga versi 2.0.
OpenID baru (OpenID-Connect) menggunakan lagi Webfinger.

Saya pikir standar webfinger mungkin merupakan solusi yang baik. Tapi saya pikir itu juga bisa bertentangan dengan email git pengguna.

Dimana konfliknya?

Sebaliknya, apa yang saya tidak suka tentang Webfinger adalah bahwa ia membutuhkan kontrol
root domain (yang tidak Anda miliki dengan URL OpenID).

Mengenai "standar apa yang ingin kita pilih" Saya hanya ingin mengarahkan Anda ke ActivityPub yang saat ini sedang diselesaikan oleh kelompok kerja Federasi Sosial W3C. Beberapa proyek yang mengimplementasikannya (atau sedang mengerjakannya) adalah pump.io, Mastodon dan MediaGoblin.

Mereka tidak menggunakan WebFinger karena mereka tidak menyukai gagasan jalur tetap .terkenal, tetapi ada gagasan tentang interoperabilitas .

Fitur ini akan benar-benar menjadi pengubah permainan; keybase.io baru-baru ini keluar dengan git terenkripsi sisi klien, itu juga menarik.

Hanya ingin menunjukkan bahwa ActivityPub sekarang sudah selesai.

Menambahkan dukungan untuk AP akan membuat Gitea kompatibel dengan semakin banyak server federasi, seperti Mastodon, PeerTube, NextCloud dan HubZilla, memperluas jangkauannya secara signifikan, belum lagi pembeda yang menonjol terhadap GitLab.
Ini juga berpotensi menurunkan GitHub sebagai hosting masuk untuk proyek sumber terbuka, karena sebagian besar ada di sini untuk alur kerja permintaan tarik komunitas yang akan diizinkan oleh AP secara terdesentralisasi, meningkatkan privasi, dan menghilangkan satu titik kegagalan untuk persentase besar komunitas perangkat lunak bebas.

Bagaimanapun, harapan saya adalah ini diimplementasikan, memiliki potensi untuk menjadi revolusioner!

Seperti yang sudah dinyatakan dalam obrolan, ActivityPub in go adalah PITA karena sulit dilakukan dalam bahasa statis seperti go.

@tboerger Menarik. Spesifikasi ActivityPub adalah OO yang cukup banyak warisan, tetapi itu mungkin untuk dimodelkan di Go dengan penyematan struct, namun sejauh yang saya tahu, tidak ada yang seperti serde di Rust (https://docs.serde. rs/serde_json/value/index.html), yang cukup menyederhanakan banyak hal, namun ada beberapa upaya untuk mengimplementasikan ActivityPub di Go, yang mungkin merupakan awal yang baik karena tidak hanya mengimplementasikan json-ld parsing, tetapi juga mendefinisikan kosakata inti untuk ActivityStreams.

Gangguan spesifik apa yang Anda pikirkan di sini?

@MatejLach Proyek lain https://github.com/go-fed/activity

Proposal yang relevan di repositori gogs:
https://github.com/gogs/gogs/issues/4437

Di repositori Gitlab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

Hai! Editor bersama ActivityPub di sini. Saya cukup sibuk saat ini tetapi saya ingin melihat ini terjadi... jika Anda membutuhkan pertanyaan, silakan ping saya, atau tanyakan di #social di irc.w3.org

Harap jangan ragu untuk menghubungi saya di Mastodon untuk pertanyaan/masalah/komentar apa pun seputar https://github.com/go-fed/activity library yang disebutkan oleh @jas99 . Saya jelas memiliki kepentingan dalam hasil keputusan tersebut, tetapi dengan senang hati akan memberikan informasi jujur ​​tentang pengalaman saya bekerja di persimpangan go+ActivityPub. Saya setuju dengan @tboerger bahwa menerapkan ActivityPub in go adalah tebing curam.

Mungkin kita bisa membuat repositori baru bernama index dan menyiapkan domain baru index.gitea.io untuk melakukannya?

Mengapa kita membutuhkan server indeks? @lunny

Akan luar biasa jika kita bisa memiliki proyek berbeda yang membahas implementasi umum dari protokol ActivityPub (yaitu menggunakan ekstensi yang sama untuk kata kerja, dll). Ini akan memungkinkan pengguna gitea, gogs, dan gitlab untuk bekerja sama dengan lancar seperti halnya pengguna berbagai platform media sosial yang dapat didiskusikan oleh federasi dengan lancar.

Mungkinkah ini tempatnya? -> https://github.com/git-federation/gitpub

@jaywink ide bagus!

Ini akan luar biasa! Saya pikir Nextcloud (/ Owncloud) adalah contoh sempurna tentang bagaimana ini dapat bekerja dengan implementasi yang ideal, seperti yang disarankan @JonasFranzDEV .

Dengan Nextcloud, jika saya ingin berbagi folder dengan pengguna di instance lain, saya dapat dengan mudah melakukannya dan menyiapkan folder bersama di kedua instance.

Jika saya bisa melakukannya untuk repositori yang dihosting di instance Gitea saya, memberikan pengguna di instance federasi lain akses ke repo, dengan repo itu kemudian muncul di antarmuka Gitea mereka dengan kemampuan penuh untuk berinteraksi dengan masalah dll (dengan beberapa denotasi yang jelas di UI bahwa repo ini di-host pada contoh lain), itu akan sangat menakjubkan.

Tujuan yang dibahas untuk mengadopsi standar bersama antara Gitea dan proyek self-hosted open source lainnya (seperti GitLab CE) pasti masuk akal, dan akan sangat bagus jika ini diadopsi memungkinkan federasi antara Gitea, Gogs, GitLab, dll. Migrasi dari GitHub untuk proyek pribadi itu mudah tanpa kerugian apa pun, tetapi untuk proyek sumber terbuka publik, kita perlu mengakui bahwa manfaat besar GitHub adalah komunitas. Saya telah menemukan banyak proyek sebenarnya di GitHub. Jika ada beberapa cara untuk menggabungkan proyek-proyek populer, umpan aktivitas pengguna (yaitu dapat mengikuti teman di instance lain dan mengikuti aktivitas mereka, proyek yang disukai, dengan pengaturan privasi yang diperhitungkan, dll.) akan sangat baik - jika itu memungkinkan.

Permintaan tarik gabungan akan menjadi langkah awal yang bagus untuk hal ini (#184), dan kemungkinan merupakan fitur yang paling penting yang hilang saat ini.

11 bulan sejak komentar terakhir di sini.. Saya ingin tahu apakah masih ada rencana?

Ketika ada semacam standar yang disepakati daripada ya

Diskusi saat ini sedang berlangsung sebagai bagian dari proyek palsu, jadi ikuti terus jika Anda ingin tahu lebih banyak: https://github.com/forgefed/forgefed

Seperti yang disebutkan @lafriks , begitu ada standar yang disepakati, maka berbagai proyek dapat mengimplementasikannya.

URL yang benar untuk proyek palsu sekarang adalah https://notabug.org/peers/forgefed

Sepertinya ini harus menjadi sangat penting sekarang, mengingat github sekarang menghapus akun ppl dari seluruh negara.

ForgeFed juga sekarang memiliki forum diskusi . Akan sangat bagus untuk melibatkan seseorang dari Gitea.

+1 untuk ini. Bekerja dari instance yang dihosting sendiri secara lokal tetapi tidak diisolasi karena pilihan itu akan benar-benar menjadi yang terbaik dari kedua dunia.

Kelompok kerja ForgeFed akan sangat membutuhkan pengembang dari bengkel saat ini untuk memberikan komentar: https://talk.feneas.org/t/working-group-instructions/196

Saya hanya ingin menambahkan bahwa sebelum Microsoft mengilhami migrasi massal dari Github, ini tidak akan menjadi fitur pembunuh... SEKARANG. Semakin sedikit repo untuk proyek OS yang saya teliti ada di Github sekarang (MUNGKIN dicerminkan di sini).

Saya telah membaca bahwa riwayat komit Github dapat dibaca seperti cv dan bahwa salah satu alasan mengapa dunia perangkat lunak begitu karier seluler adalah bahwa seseorang dapat mengajarkan sendiri keterampilan yang berharga, dengan MUDAH MENUNJUKKANnya (riwayat github publik), dan dengan demikian memenuhi syarat untuk penghasilan yang lebih baik/dll. Jika riwayat kontribusi Anda tersebar di lusinan server pribadi, itu JAUH kurang terlihat/berguna.

Selain itu, salah satu dari server tersebut dapat turun kapan saja dan bagian dari riwayat Anda sekarang hilang. Implementasi yang tepat dari repositori federasi berarti bahwa saya dapat berpartisipasi dalam lusinan proyek pada lusinan instance (dari instance saya) dan jika SEMUA turun, saya masih memiliki 'profil git federasi' saya.

Menautkan ke peta jalan ForgeFed (ada dana untuk mereka yang akan mengerjakannya):

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

Mungkin, untuk implementasi sederhana, gitea dapat menjalankan simpul ipfs di latar belakang yang menghosting file repositori lokal (menggunakan ipns untuk menunjuk ke versi terbaru dari repositori). Kami kemudian dapat memiliki implementasi protokol gosip sederhana untuk menemukan instance gitea lain dan mendapatkan hash ipns & data awal (bintang, nama).
Manfaat menggunakan ipfs adalah ketika pengguna di satu instance ingin melihat atau mem-fork repositori di instance lain, itu akan berkontribusi untuk meng-hosting bagian dari repositori itu dan membuat akses repo lebih cepat untuk jaringan secara keseluruhan.

Menggunakan ipfs/ipns juga dapat digunakan untuk mendistribusikan data pengguna seperti repositori berbintang, permintaan tarik, bio, dll. setiap node hanya akan menyimpan nama & hash ipns untuk pengguna di jaringan lain yang dipedulikan oleh instance dan akan menjadi sepele untuk meminta data profil untuk pengguna yang tidak dikenal.

ipfs sudah memiliki implementasi go dan misalnya penemuan sesuatu seperti ini dapat digunakan.

Tidak ada persyaratan untuk penyimpanan peer-to-peer di sini, apa yang Anda gambarkan tampaknya tidak diperlukan atau bahkan terkait dengan masalah yang dihadapi. Saya tidak berpikir ada minat untuk pindah dari format penyimpanan Git dan protokol transfer. Mungkin Anda harus membuka masalah terpisah jika Anda melihat manfaat di sini (saya tentu saja tidak).

Tidak ada persyaratan untuk penyimpanan peer-to-peer di sini

Saya pikir gitea akan mendapat banyak manfaat dari berbagi repositori peer-to-peer sehingga repo populer akan menjadi mubazir jika instance turun. Sementara seseorang hanya dapat mencerminkan repositori ke instance mereka sendiri, itu akan memecah pengembangan proyek jika tidak ada tempat sentral untuk berkomitmen. Jika protokol git berlapis pada IPFS, itu akan memungkinkan untuk deduplikasi ketika mem-forking proyek pada satu contoh (jadi seluruh salinan tidak harus disimpan).

apa yang Anda gambarkan tampaknya tidak diperlukan atau bahkan terkait dengan masalah yang dihadapi.

Alasan federasi sangat berguna (dan mengapa orang sangat menginginkannya) adalah karena federasi memungkinkan kolaborasi lintas instance. InterPlanetary Name System (IPNS) memiliki perilaku yang identik dengan OpenID karena dapat digunakan untuk mengidentifikasi pengguna yang memiliki izin untuk memperbarui data tertentu (misalnya repositori dan profil pribadi mereka). Alamat IPNS dapat secara unik mengidentifikasi pengguna dari instance lain tanpa harus mengikat pengguna tersebut ke instance tertentu. Mari kita beri contoh:
Alice menghosting sendiri instance gitea di aliceland.net
Ketika Alice membuat akun baru, gitea akan membuat profil kosong, menghostingnya di IPFS dan kemudian menghasilkan alamat IPNS unik yang mengarah ke profil itu. Setiap kali Alice membuat repositori baru atau memperbarui profilnya dengan cara apa pun, gitea akan (di belakang layar) membuat catatan IPFS baru, melepas pin yang lama, dan menetapkan kembali alamat IPNS Alice ke sana.
Sekarang katakanlah Bob ingin mengirimkan permintaan penggabungan dari cermin repositori di bobland.net ke aliceland.net.
Ketika Bob awalnya melakukan fork repo Alice ke bobland.net, dia membuat catatan tentang IPNS repo Alice serta lokasi IPFS dari komit tempat dia melakukan fork.
Ketika Bob ingin membuka permintaan penggabungan, dia menulis pesannya dan kemudian bobland.net akan memasukkan hal-hal berikut ke dalam blok IPFS:

• Alamat pengguna IPNS Bob
• Alamat IPFS dari komit yang ingin ditarik Bob
• Alamat IPFS dari komit di repo Alice yang harus dimodifikasi
• Pesan dan Judul Bob untuk permintaan penggabungan
• Tanda tangan data dengan kunci profil IPNS pribadi Bob

Bobland.net kemudian akan mengirim alamat IPFS ke aliceland.net yang kemudian dapat memilih untuk mengabaikannya, ATAU mengurai alamat, memverifikasi komit, membuat alamat IPNS untuk utas komentar (yang menunjuk ke semua komentar) dan kemudian memberi tahu Alice bahwa beberapa orang bernama Bob misalnya Bobland.net telah mengirim permintaan penggabungan untuk 3 komit melalui IPFS. Komentar juga akan di-host melalui IPFS dan dapat diakses melalui alamat IPNS.
Pola penggunaan IPNS untuk data yang dapat berubah (seperti utas komentar) dan IPFS untuk data yang tidak dapat diubah (seperti komentar dan komit) dapat diterapkan untuk sebagian besar federasi antar-instance.

Saya tidak berpikir ada minat untuk pindah dari format penyimpanan Git dan protokol transfer.

Pendekatan ke federasi ini tidak harus menjauh dari format Git. Git dapat dengan mudah dilapis dan disimpan di ifps (sambil juga memanfaatkan deduplikasi). Sistem Merkle Tree Git tidak harus terintegrasi dengan IPFS (walaupun itu akan keren) dan protokol transfer git akan tetap sama, IPFS hanya akan memoderasi komunikasi antar instance.

Bisakah Anda membuka edisi terpisah? Yang ini tentang sesuatu yang spesifik, dan ForgeFed sudah mengerjakan sebuah protokol. Lebih baik lagi, bawa bersama mereka.

Menumpuk masalah dengan komentar seperti "bagaimana dengan ipfs/filecoin/blockchain" sepertinya tidak sopan.

+1

GitLab juga membahas fitur ini: https://gitlab.com/gitlab-org/gitlab/-/issues/6468

Saya melakukan ping pada gitea dev discord beberapa hari yang lalu sebagai FYI, dan telah secara proaktif mencoba menjangkau beberapa orang di belakang ForgeFed, seperti go-fed v1 sedang dilakukan & didokumentasikan, akan menyenangkan untuk mendapatkan contoh dari gitea federasi di ActivityPub meskipun itu bukan usaha kecil. Saya pikir orang-orang gitea sibuk dengan atm prioritas lainnya. Sayangnya, saya tidak berhasil mendapatkan salah satu dari orang-orang ForgeFed. :(

Beberapa dari kami di komunitas ActivityPub, yang berasal dari APConf2020, bereksperimen dengan memiliki proses dokumentasi ringan akar rumput pada instance gitea dan rasanya aneh untuk tidak dapat menggabungkannya.

Git sudah memiliki semua fitur yang diperlukan untuk pencerminan terdesentralisasi, satu-satunya fungsi yang hilang adalah apa yang diperlukan untuk mengoordinasikannya, persis seperti yang dilakukan ForgeFed. IPFS tidak perlu berada di sini, dan mengingat betapa buruknya peluncuran mainnet mereka, saya tidak yakin aman untuk terikat secara mendalam dengan proyek-proyek lain oleh Protocol Labs.

Saya tertarik untuk berkolaborasi dalam inisiatif yang ada. Mari kita coba membentuk kelompok kerja. Dapat menyarankan saluran Matrix ini untuk diskusi lebih lanjut #n oteworthy:tincan.community