Tangled - platform kolaborasi Git berbasis atproto

• Tangled adalah platform kolaborasi Git dengan fitur sosial berbasis AT Protocol, yang dirancang agar developer tetap memiliki kepemilikan penuh atas kode mereka sambil memungkinkan komunitas open source beroperasi secara otonom
• Mengadopsi arsitektur kolaborasi kode terdistribusi yang menggabungkan keunggulan model federasi berbasis ActivityPub(Forgejo) dan model P2P penuh milik Radicle
• Konsep inti 'Knot' adalah server Git headless ringan yang mendukung self-hosting pribadi maupun lingkungan multi-tenant berbasis komunitas
• App View(tangled.sh) menyediakan tampilan terpadu untuk repositori di seluruh jaringan, sehingga repositori di Knot yang berbeda dapat ditelusuri·di-clone·dikonstribusikan dengan mulus
• Saat ini masih dalam tahap beta, dengan prinsip utama kepemilikan data·hambatan masuk rendah·pelestarian pengalaman pengguna, dan ke depan menargetkan pembangunan ekosistem Git terdistribusi yang sepenuhnya terbuka

---

Ikhtisar Tangled

• Tangled adalah platform baru yang menyediakan lingkungan kolaborasi Git dengan interaksi sosial, sambil mempertahankan kepemilikan developer atas kode dan identitas mereka
• Dibangun di atas AT Protocol, menerapkan arsitektur aplikasi sosial terdesentralisasi ke kolaborasi Git
• Tujuannya adalah mengembalikan kolaborasi kode menjadi proses yang terbuka dan menyenangkan

Model terdistribusi dan AT Protocol

• Model kolaborasi kode terdistribusi yang sudah ada mencakup pendekatan berikut
  • Forgejo(ActivityPub): kolaborasi melalui federasi antarserver
  • Radicle: struktur P2P(peer-to-peer) sepenuhnya
• Tangled menggabungkan keunggulan kedua model tersebut dan mengadopsi atproto yang memungkinkan manajemen identitas terpusat
• Dengan ini, pengguna dapat mempertahankan ID dan struktur autentikasi yang konsisten bahkan di dalam jaringan terdistribusi

Struktur Knot

• Knot adalah komponen inti Tangled, server ringan yang memungkinkan pengguna meng-host repositori Git secara langsung
  • Mendukung konfigurasi single-tenant maupun multi-tenant
  • Dapat di-self-host bahkan pada perangkat kecil seperti Raspberry Pi
• Tangled pada dasarnya menyediakan layanan Knot terkelola gratis
• Berkat struktur ini, terbentuk jaringan Git terdistribusi yang secara alami menghubungkan server pribadi pengguna dan server komunitas

App View dan jaringan terpadu

• App View yang disediakan di tangled.sh berperan menampilkan repositori dari seluruh jaringan dalam satu tampilan terpadu
• Pengguna dapat dengan mudah melakukan clone dan kontribusi bahkan pada repositori yang berada di Knot lain
• Desain ini mempertahankan workflow Git yang sudah ada sambil menghilangkan hambatan lingkungan terdistribusi

Prinsip pengembangan

• Tim Tangled menetapkan tiga prinsip berikut sebagai arah pengembangan
  • 1. Kepemilikan data — setiap pengguna memiliki langsung kode dan metadata yang mereka buat
  • 2. Hambatan masuk rendah — menyediakan struktur dan antarmuka yang sederhana agar siapa pun bisa berpartisipasi dengan mudah
  • 3. Konsistensi pengalaman pengguna — meski menggunakan struktur terdistribusi, tetap menjamin UX setara layanan terpusat
• Prinsip-prinsip ini tercermin dalam pilihan teknis Tangled serta keseluruhan desain UI/UX

Akses dan komunitas

• Pada awalnya, layanan ini dioperasikan dengan akses berbasis undangan(invite-only), dan developer dapat bergabung melalui kanal IRC #tangled (libera.chat)
• Saat ini statusnya login publik terbuka, sehingga siapa pun dapat menggunakannya di tangled.sh/login
• Tangled masih berada di tahap awal, tetapi terus berkembang sambil memverifikasi fitur melalui penggunaan internalnya sendiri (dogfooding)

Kesimpulan

• Tangled adalah upaya untuk memperluas kolaborasi Git menjadi pengalaman yang terhubung seperti jejaring sosial
• Platform ini mendapat perhatian sebagai ekosistem platform Git terdistribusi baru yang menggabungkan otonomi, aksesibilitas, dan budaya pengembangan yang menyenangkan

[lamanus]

Karena tidak ada kontainer resmi, pengaturan awalnya agak merepotkan.

[GN⁺]

Komentar Hacker News

• Sebagai salah satu pendiri Tangled, baru-baru ini kami mengganti library OAuth dan muncul masalah yang membuat pengguna baru tidak ditambahkan ke knot dan spindle default (server hosting git internal dan runner CI); patch perbaikannya baru saja diterapkan, jadi setelah logout lalu login kembali, pembuatan repositori akan berfungsi normal. Jika ada pertanyaan, saya siap menjawab kapan saja.
  • Pertanyaan pertama adalah apakah di PDS tngl.sh kita bisa mengubah handle atau menghapus akun. Pertanyaan kedua adalah sumber daya seperti apa yang dibutuhkan untuk membuat dan mengoperasikan AppView baru; misalnya, jika membuat AppView berbasis PDS yang hanya mengunggah folder situs web statis seperti Cloudflare Pages lalu langsung menyajikannya, apakah operator AppView harus menanggung sendiri semua biaya trafik besar? Saya ingin tahu bagaimana beban operasional dalam struktur seperti itu.
  • Tangled memakai istilah “social-enabled”, yang tampaknya terkait dengan protokol AT. Saya penasaran apakah Tangled ke depannya merencanakan lebih banyak fitur sosial, atau itu hanya berarti dukungan untuk protokol AT.
• Saya rasa proyek ini benar-benar keren. Saya suka upaya untuk membongkar struktur monopoli layanan code forge yang ada saat ini. Alasan saya tertarik pada bidang ini adalah karena code forge terasa tidak efisien justru karena mencoba menyelesaikan terlalu banyak masalah sekaligus. Kebanyakan forge menggabungkan repositori git, web viewer, alat kolaborasi, pipeline CI/CD, manajemen kerja, dan banyak fitur lain menjadi satu. Padahal menurut saya fitur-fitur itu tidak harus disatukan. Misalnya, jika tidak perlu akses langsung ke repositori git, web viewer yang sepenuhnya statis bisa disediakan seperti https://pgit.pico.sh, atau kolaborasi bisa ditangani oleh server terpisah untuk membagi, me-review, dan mengelola patch secara lokal (https://pr.pico.sh). Bahkan cukup mengunggah bare git repository ke VPS, dan itu sangat mudah dilakukan. Git sendiri sudah merupakan sistem terdistribusi, jadi menjadi tersentralisasi karena layanan tambahan lain menurut saya adalah antipola.
  • Orang sering mengatakan “Git sudah terdistribusi”, tetapi dalam praktiknya konsep distribusi itu agak ambigu. Git sendiri, alih-alih benar-benar berfokus pada distribusi, biasanya berbasis protokol master-slave (HTTP dan semacamnya), sehingga pada akhirnya cenderung terus kembali ke sentralisasi.
  • Jika layanannya banyak, muncul masalah kepercayaan. Kita harus mempertimbangkan apakah lebih baik memeriksa satu layanan yang memenuhi 80% kebutuhan, atau memverifikasi 10 layanan terpisah satu per satu. Selain itu, skala ekonomi infrastruktur dan keuntungan dari integrasi banyak fungsi juga tidak bisa diabaikan. Karena itu masih banyak orang yang lebih memilih monolitik. Pada akhirnya ini jadi trade-off dalam pengalaman pengembang.
  • Menyiapkan remote repository git di VPS benar-benar mudah; selama bisa diakses lewat ssh, itu langsung berjalan. Sebenarnya isu utamanya menurut saya adalah lock-in (ketergantungan pada layanan). Mengapa GitHub dan sejenisnya lebih fokus pada lock-in daripada sekadar menyediakan layanan? Di baliknya ada pendanaan dan model bisnis. Rantai sentralisasi → lock-in → pendapatan terus muncul di banyak layanan. Jika tidak ada struktur yang menghasilkan uang dari layanan itu sendiri, rasanya fenomena ini sulit dihindari.
  • Secara teknis pemisahan fungsi itu bukan tidak mungkin, tetapi ada masalah ekonomi (masing-masing fungsi tidak punya struktur pendapatan yang cukup untuk dipelihara secara terpisah) dan kegunaan (orang menginginkan kenyamanan yang “sudah lengkap”). Hal yang sama juga terjadi di open source; banyak kasus yang mengabaikan aspek ekonomi, tetapi pada akhirnya kebanyakan mati ketika satu maintainer berhenti. Bahkan proyek open source yang paling sukses pun umumnya bertahan berkat sponsor korporat atau dukungan para engineer.
  • Tidak harus dipisahkan, tetapi tetap saja yang terintegrasi jauh lebih nyaman.
• Saya baru tahu kabar dukungan Jujutsu di JJ Con. Detailnya bisa dilihat di https://blog.tangled.org/stacking.
  • Layanan ini benar-benar mendukung stacked PR. GitHub belum bisa melakukan ini bahkan setelah puluhan tahun. Kalau harus dipakai secara privat di internal perusahaan, agak disayangkan karena belum jelas bagaimana cara mengatur instance Tangled agar tidak terhubung ke jaringan eksternal.
• Saya rasa GitHub sudah tidak bisa lagi dipercaya. Memindahkan setidaknya stack OSS ke protokol AT atau jaringan terbuka lain tampaknya menjadi cara yang baik untuk melindungi diri dari risiko perusahaan besar, sensor, dan semacamnya. Senang melihat upaya seperti ini.
  • Tapi kebanyakan orang tidak ingin mengelola server sendiri. Mungkin hanya organisasi OSS besar yang mampu menanganinya. Bahkan selain email, menyediakan PR pun akan sulit.
• Saya termasuk 100 orang pertama yang mendaftar ke tangled. Roadmap review PR berbasis stacked patch dan kecepatan peningkatan fiturnya sangat mengesankan, dan saya juga merasakan energi positif dari antusiasme komunitasnya. Saya sangat menantikan bagaimana ini akan berkembang ke depan. Jika terus maju secara konsisten seperti ini, saya rasa pengalaman yang jauh lebih baik, kontrol yang lebih mendasar, dan keberlanjutan jangka panjang juga bisa terwujud.
• Saya sangat tertarik pada cara kolaborasi git yang lebih terdistribusi. Menurut Anda, apa hambatan terbesar agar pendekatan seperti ini bisa menyebar? Apakah operasional server, pengelolaan private key, atau pada akhirnya efek jaringan?
  • Hambatan terbesar adalah spam, konten ilegal, dan masalah moderasi secara umum. Karena PDS bisa memakai domain apa pun dan satu PDS bisa menampung pengguna tanpa batas, sering kali muncul pengalaman yang merusak kepercayaan. Jika orang mengunggah ebook atau acara TV dalam jumlah besar ke repo git, apa yang harus dilakukan? Atau jika sebuah proyek menjadi sasaran serangan spam karena isu politik, kita juga harus memikirkan solusinya. Hal baik dari konsep AppView adalah, seperti BlueSky, tim moderasi terpusat bisa menerapkan kebijakan yang konsisten. Semua orang memang bisa mengunggah apa saja, tetapi pada akhirnya frontend bisa melakukan kurasi secara selektif. Namun keputusan moderasi terpusat juga selalu kontroversial. Itulah sebabnya saya tidak ingin menanggung beban dan tanggung jawab jaringan yang sepenuhnya terdistribusi. Keterbukaan protokol AT memang keunggulan dibanding layanan seperti Twitter, tetapi sebagai gantinya tetap dibutuhkan sistem yang memusatkan pengelolaan sehari-hari dan pemberian otorisasi. Secara pribadi saya penasaran apakah saat ini ada orang yang bersedia menjadi operator radicle seed node yang “longgar” (mengizinkan unggahan git anonim).
  • GitHub gratis, sedangkan desentralisasi itu berbiaya.
  • Tangled sangat memuaskan karena saya bisa memakai git secara mandiri tanpa harus mengelola server sendiri. Kelemahan terbesarnya adalah layanannya masih terlalu baru. Kesadaran publiknya belum tinggi, dan masih banyak orang yang belum tahu apa yang ditawarkan Bsky dan PDS. Akan bagus jika ada lebih banyak fitur dan alternate client. Meski begitu, saya rasa pengguna awal sudah mendapatkan pengalaman yang cukup baik. Saya menunggu hari ketika lebih banyak pengembang bisa merasakan pengalaman ini.
• Saya senang ada dukungan pipeline CI, tetapi agak kecewa karena bentuknya tampak mirip GitHub Actions. Menurut saya tidak perlu memakai YAML hanya untuk eksekusi sekuensial sederhana; bash script juga sudah cukup. YAML pipeline menurut saya baru bermakna ketika mengekspresikan dependensi (DAG), bukan alur program. Buildkite jauh lebih unggul dalam hal ini.
• Besok sepertinya akan muncul platform bisnis no-code bernama “Spaghetti”, dan layanan brankas penyimpanan data penting bernama “Lock-in”.
• Di perusahaan, kami terpaksa harus memakai GitHub public org. Apakah code review (CR) bisa dilakukan di tangled lalu disinkronkan ke GitHub setelahnya? Apakah pengalaman review dengan tool jj tetap bisa dipertahankan?
  • Bisa di-mirror, dan Anda juga bisa membuat spindle pipeline yang melakukan push ke GitHub saat merge. Dokumen referensi: https://tangled.org/@tangled.org/core/blob/master/docs/spindle/pipeline.md
• Saya penasaran apakah Tangled bisa diadopsi untuk kebutuhan enterprise/private. Alur review stacked diff tampaknya sangat cocok untuk pekerjaan perusahaan.
  • Ada kemungkinan. Versi Tangled yang sepenuhnya airgapped dan terpisah dari AT sedang dibahas. Itu pekerjaan yang cukup besar, jadi sulit dilakukan dalam waktu dekat.
  • Saat ini belum ada solusi enterprise khusus yang benar-benar jelas. Diskusi isu terkait bisa dilihat di https://tangled.org/@tangled.org/core/issues/60.