Perlunya Federasi Forge

• Kolaborasi open source berangkat dari kesadaran bahwa kombinasi protokol terdistribusi yang membagi peran pengiriman kode dan komunikasi lebih diinginkan daripada struktur yang sangat bergantung pada satu penyedia
• Kolaborasi kode awalnya dilakukan dengan kombinasi git dan email, lalu bergeser ke kombinasi git dan situs web GitHub, dan berlanjut ke ForgeFed dengan kombinasi git dan ActivityPub, serta Tangled dengan kombinasi git dan AT protocol
• Tangled memiliki struktur yang memfederasikan event di antara server git, dan menyebut tiap server sebagai knot; meski server berbeda, tetap mendukung kolaborasi repositori, fork lintas server, dan pull request ke repositori yang berada di server lain
• Untuk Authenticated Transfer di sekitar kode, Tangled memakai AT, menangani issues, pull requests, timeline event, follows, dan stars secara bersama, serta memanfaatkannya untuk undangan kolaborator dan berbagi kunci publik SSH
• Arah ini mirip dengan alur menjalankan instance cgit sendiri dan mengirim patch lewat email, sambil menunjukkan upaya untuk keluar dari monokultur GitHub dan tetap mempertahankan aspek sosial serta kesenangan dalam berkolaborasi

---

Perlunya federasi forge

• Struktur yang membuat sebagian besar kolaborasi open source bergantung pada satu penyedia bukanlah hal yang diinginkan, dan berpijak pada pandangan bahwa protokol terdistribusi bertahan lebih lama daripada sistem terpusat
• Kolaborasi kode selalu menggunakan dua protokol sekaligus: satu untuk pengiriman kode, dan satu lagi untuk komunikasi
  • Alur awal adalah kombinasi git dan email
  • Setelah itu berubah menjadi kombinasi git dan situs web GitHub
  • ForgeFed membuka kemungkinan kombinasi git dan ActivityPub
  • Tangled sedang dibangun dengan kombinasi git dan AT protocol
• Tangled memfederasikan event di antara server-server git, dan menyebut tiap server sebagai knot
  • Kolaborasi repositori dimungkinkan di server mana pun
  • Mendukung fork lintas server
  • Setelah melakukan push ke repositori di server sendiri, pengguna dapat membuka pull request ke repositori yang di-host di server yang sepenuhnya berbeda
• Pendekatan ini dalam banyak hal mirip dengan alur menjalankan instance cgit sendiri sambil mengirim patch lewat email

Peran yang dijalankan Tangled

• Tangled menggunakan AT untuk Authenticated Transfer atas event di sekitar kode
  • Digunakan untuk menyampaikan event seperti issues dan pull requests
  • Juga menangani fitur sosial seperti timeline event, follows, dan stars
  • vouches juga akan segera ditambahkan
• AT juga digunakan untuk undangan kolaborator dan berbagi kunci publik SSH, sementara bagian lainnya tetap memakai git yang sudah ada
• Open source perlu keluar dari monokultur seperti GitHub, sambil tetap mempertahankan aspek sosial dan kesenangan dalam kolaborasi kode
• tangled alpha
• docs
• source
• discord
• bluesky
• twitter (x)
• feed

[GN⁺]

Opini Hacker News

• Saya tidak terlalu yakin ini akan jauh lebih baik daripada Mastodon

  • ATproto bukan struktur beberapa server yang saling bertukar pesan, melainkan lebih mirip RSS
    Ada lapisan hosting yang terpisah dari aplikasi, siapa pun bisa meng-host datanya sendiri, lalu aplikasi di atasnya mengumpulkan dan menampilkan data dari semua host
    Jadi memang tidak ada konsep defederation ala Mastodon
    Kalau ingin tahu lebih jauh, lihat https://overreacted.io/open-social/ dan https://overreacted.io/a-social-filesystem/
  • ATproto cukup berbeda dari Mastodon dalam cara federasinya, dan di sini tidak ada konsep instance
    Akun di-host di PDS dan rekamannya juga masuk ke sana, tetapi yang ditampilkan di aplikasi disediakan oleh AppView yang mengumpulkan data dari banyak PDS
    Jadi, di PDS mana pun akun berada, pengalaman di aplikasinya terasa seperti layanan terpusat; AppView juga bisa ada banyak dan bisa di-host sendiri
  • AppView cukup berbeda dari fediverse, karena bergantung pada shared relay alih-alih federation yang eksplisit
    Memang ada biaya yang perlu dipikirkan dari terciptanya discoverability yang pada praktiknya bersifat global seperti sekarang, tetapi tetap sulit menyebut ini sekadar Mastodon versi lain
  • Saya tidak paham kenapa harus memihak salah satu sisi atau memilih sisi yang benar
    Bukankah cukup dengan tidak mengambil posisi, atau memakai yang menurut kita sendiri benar?
  • Agak dilebih-lebihkan memang, tetapi sekalipun begitu, ini tetap tampak jauh lebih baik daripada struktur sekarang yang baru terasa eksis kalau bergantung pada GitHub dan GitLab

• Saya mungkin bias karena cukup aktif memakai sisi atprotocol, tetapi saya benar-benar puas menggunakan Tangled
  Ini yang paling mendekati gambaran pengganti GitHub yang saya inginkan; fiturnya memang lebih sederhana, tetapi selama setahun terakhir ini menjadi layanan social/git utama untuk proyek open source pribadi saya
  Akun saya ada di https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
  Saya suka karena social graph yang saya kenal dari Bluesky ikut terbawa, jadi lebih intuitif untuk menghubungkan orang di balik commit, PR, dan issue; login-nya juga sama seperti layanan atproto lain sehingga praktis
  Belakangan juga sudah ada dukungan bawaan untuk situs statis, jadi enak untuk langsung meng-host website client-side atau index.html sederhana dari repo
  Spindles berperan sebagai sistem build/action, dan meski saya bukan penggemar Nix, untuk kebutuhan yang saya punya ini cukup cocok
  open API-nya juga bagus, jadi saya bisa dengan mudah membuat renderer informasi memakai standar berbasis atproto, bikin bot juga, dan menambahkan beberapa fitur npmx.dev
  Kita bisa menjalankan knot (server git) dan runner (Spindles) sendiri, atau memakai versi yang di-host; yang penting, fitur sosialnya dipisahkan, jadi walaupun server git-nya terpisah, percakapan issue atau PR tetap berlanjut di lapisan sosial bersama
  Belum sempurna, dan label alpha di navbar itu bukan tanpa alasan, tetapi untuk kerja open source kemungkinan besar saya akan terus memakainya

  • Saya agak khawatir atproto akan ikut terseret oleh kurangnya daya tarik Bluesky
    Saya sendiri belum yakin apakah itu kekhawatiran yang benar-benar masuk akal

• Nuansa komentarnya cukup negatif, tetapi meski saya juga cenderung waspada terhadap pendanaan VC, saya tetap melihat persaingan di area ini perlu didorong
  Memulai hal seperti ini secara bootstrap di titik sekarang tampak sangat sulit, bahkan nyaris mustahil; memang benar timing-nya juga pas dengan tulisan kritik GitHub yang kemarin ada di puncak HN, tetapi tetap saja saya ingin mendukung upaya seperti ini
  Saya harap ini bisa mapan pada skala yang berarti

  • Menurut saya ini bukan sekadar sikap negatif, melainkan kekhawatiran nyata
    Waktu hanya melihat judulnya saya sempat tertarik, tetapi begitu tahu ada pendanaan VC, langsung keluar dari daftar pertimbangan
    Kalau saya mau menaruh proyek kesayangan saya yang bahkan tidak menghasilkan uang di sebuah platform, saya ingin memilih tempat yang kecil kemungkinan melakukan rug pull lima tahun dari sekarang
    Proyek VC pada akhirnya harus mengembalikan investasi, jadi menurut saya pada suatu saat rug pull itu akan datang dalam bentuk apa pun
    Karena itu, sekarang saya lebih suka layanan yang saya pakai sebagai pelanggan yang membayar, atau yang seperti koperasi di mana saya membayar iuran dan punya hak suara dalam pengambilan keputusan
  • Proyek yang didanai VC pada akhirnya cenderung mengarah ke rug pull, iklan, pelanggaran privasi, atau pemaksaan fitur berbayar yang tidak masuk akal
    Jadi dari sudut pandang pengguna, kemungkinan itu perlu diketahui sejak awal
    Saya kurang suka layanan yang menjual idealisme berlebihan padahal realitas seperti itu sudah jelas di depan mata
    Lebih baik menarik biaya layanan saja, atau kalau memang benar-benar idealis, mulai sebagai non-profit, atau setidaknya jelaskan dengan terang rencana monetisasinya
  • Saya tidak terlalu paham kenapa bootstrap dianggap mustahil
    Sulit itu jelas, tetapi apalagi kalau arahnya federation, bukankah seharusnya bisa dibangun dengan infrastruktur yang justru lebih murah, bukan biaya yang sama atau lebih besar?

• Kalau penasaran dengan model data atproto, saya menulis artikel pengantar di https://overreacted.io/a-social-filesystem/
  Memang agak panjang, tetapi cukup jelas memberi gambaran besarnya

  • Itu malah terkesan meremehkan
    Dari semua tulisan pengantar ATProto yang pernah saya baca, ini yang terbaik
    Saya penasaran apakah ada tag atau daftar khusus yang mengumpulkan tulisan-tulisan seperti ini di satu tempat

• Menurut saya yang dibutuhkan bukan forge federation, melainkan git repo yang lebih kaya
  Fossil sudah mendekati sekitar 90% ke sana dengan mengintegrasikan tiket, forum, dan wiki sebagai bagian dari repositori; saat di-clone, semua itu ikut terunduh dan bisa dilihat secara offline
  Bahkan di pesawat pun kita bisa menulis balasan, lalu kalau izinnya sesuai, bisa langsung disinkronkan atau nanti ketika koneksi pulih
  Tetapi alih-alih meng-hardcode jenis artefak tertentu ke dalam VCS, menurut saya lebih baik repo memuat aplikasi, lalu aplikasi itu sendiri yang menentukan artefak apa yang diizinkan, aturan apa yang berlaku, dan siapa boleh mengunggah/mengunduh apa serta kapan
  forge tinggal menjalankan kebijakan itu dan merendernya untuk pengguna web sesuai kebutuhan
  Dengan begitu, pindah ke forge lain pada akhirnya hanya menjadi soal push repo

  • Terima kasih banyak untuk ini
    Belakangan saya sedang membuat hal seperti sistem tiket atau agen sebagai flat files di dalam git repo, dan sekarang saya jadi berpikir itu perlu diperluas sampai ke pengelolaan repo itu sendiri
    Sepertinya akan sangat bagus

• Menurut saya masalah inti dari federated solution pada akhirnya adalah cold start
  Kalau masuk ke server besar yang sudah ada, kita justru kembali memeluk masalah sentralisasi yang tadinya ingin dihindari, tetapi sebagai gantinya langsung mendapat jaringan yang besar sejak awal
  Sebaliknya, kalau membuka server sendiri, jaringannya nol, discoverability nol, feed kosong, dan kita harus meyakinkan situs lain agar mau berfederasi atau setidaknya tidak memblokir hanya karena ini server satu orang
  Saya tidak tahu apakah hanya saya yang merasa begitu, atau saya memang salah memahami federation
  Bisa jadi ini cuma masalah khas Mastodon

  • Karena itu tampaknya Tangled memilih ATproto daripada ActivityPub
    Karena ia dirancang agar server-server individual dikumpulkan oleh AppView terpusat sehingga memberi satu tampilan yang konsisten seperti jaringan terpusat
    Siapa pun bisa meng-host AppView
  • Ini lebih merupakan karakteristik Mastodon
    atproto tidak bekerja seperti tiap server adalah wilayah semi-terisolasi
    Penjelasan dari sudut pandang sistem terdistribusi di https://atproto.com/articles/atproto-for-distsys-engineers menjelaskannya dengan baik
  • Menurut saya keuntungannya ada di titik tengah
    Kalau server besar mulai mencurigakan dari sisi moderasi, kebijakan, konten, atau masalah teknis, kita bisa relatif mudah keluar, lalu membesarkan atau pindah ke server lain yang juga cukup besar
    Artinya, sejak awal sudah bisa ada tempat berlindung yang punya reputasi dan skala tertentu
    Sudah ada forge alternatif seperti GitLab, Codeberg, freedesktop, Fedora, dan Debian, jadi selama visibilitas dan discoverability proyek tetap terjaga, itu bisa menjadi tempat evakuasi yang cukup aman
  • Selama ini saya juga merasa persis seperti itu, jadi saya menjauhi layanan federatif
    Tetapi setelah melihat proyek ini beberapa hari lalu, saya jadi berpikir ini benar-benar mungkin berhasil
    Karena target penggunanya cukup banyak tumpang tindih dengan kalangan yang terbiasa self-hosting
    Tidak perlu seluruh jaringan saya pindah ke sini; cukup subkelompok yang memang realistis akan masuk ke sini, itu saja sudah berguna
  • Yang menarik di sini adalah bisa self-host, dan juga bisa migration di antara penyedia besar
    Biaya server frontend pasti sangat rendah, jadi rasanya hampir bisa dijalankan selamanya; data yang sesungguhnya juga disuplai oleh host lain

• Fakta bahwa Tangled didukung VC terdengar bagi saya bukan sebagai jaminan stabilitas, melainkan tekanan untuk harus tumbuh apa pun caranya
  Saya kurang melihat daya tariknya
  Bahkan kalaupun federatif, kalau pengembangannya berhenti, siapa yang akan memperbaiki bug dan merawatnya?

  • Tangled dikembangkan sepenuhnya secara terbuka di https://tangled.org/tangled.org/core, dan tujuannya juga permanent software
    Artinya, semuanya ingin dibuat sepenuhnya dapat direproduksi dan bisa di-self-host sepenuhnya dengan biaya minimal
    Pendanaan VC hanyalah sarana, bukan tujuan; bagi dua pendiri asal India yang tinggal di Eropa, hibah butuh 4–12 bulan atau lebih untuk benar-benar cair sehingga nyaris tidak realistis
    Jalan tercepat untuk membentuk tim, menyiapkan infrastruktur, dan mempercepat pengembangan adalah VC, dan mereka menghabiskan lebih dari 6 bulan untuk mencari partner yang sangat selaras dengan tujuan mereka
  • Yang memeliharanya ya para penggunanya sendiri
    Tangled memang punya banyak pilihan desain yang menarik secara struktural, tetapi kodenya sendiri relatif sederhana, dan dari yang saya lihat langsung, tingkat kesulitan pemeliharaannya tampaknya tidak tinggi
    Sebagian besar hanyalah Go modules yang terhubung longgar, ditambah HTML+CSS statis, sedikit TypeScript, dan Nix untuk orkestrasi
    Kalau saya ingat dengan benar, kebutuhan hardwarenya juga sangat kecil, jadi pada skala sekarang satu orang pun bisa meng-host-nya sendiri
    Sebagian besar beban infrastruktur yang nyata justru ditanggung oleh knots, spindles, PDS milik pengguna dan ekosistem atproto secara keseluruhan
  • Komentar ini pun sedang ditulis di situs agregator berita yang juga menerima pendanaan VC, jadi kalau dipikir-pikir, saya tidak yakin pantas sesimpel itu menyimpulkannya
  • VC tidak apa-apa, asal bukan pendanaan YC saja
  • Kalau VC seperti ini masuk, saya akan menanyakan dua hal
    Kenapa harus VC, dan kenapa tidak seperti Ladybird yang didukung sponsor perusahaan
    Lalu kalau para investor mengharapkan imbal hasil 10x, kenapa saya harus menghabiskan waktu pada alat developer yang pada akhirnya akan enshittify?

• Saya teringat lelucon bahwa kalau ada 4 standar lalu kita ingin menyatukannya dengan membuat standar baru, hasilnya justru jadi 5 standar
  Terlepas dari lelucon itu, saya rasa perlu alasan yang lebih kuat kenapa ActivityPub tidak cukup
  Sebelum kita mencoba memecahkan lagi masalah komunikasi terdesentralisasi dengan cara lain

  • ActivityPub dan atproto bentuknya memang berbeda
    Membenturkan keduanya itu mirip seperti bertanya, kalau sudah ada email, kenapa masih perlu web
    ActivityPub seperti email: server bertindak sebagai inbox dan saling bertukar pesan
    Sedangkan atproto seperti web: repositori pengguna meng-host data, lalu aplikasi mengumpulkan dan menampilkannya dari repo-repo itu
    Karena perbedaan topology ini, sifatnya pun berbeda; di atproto, pengalaman aplikasi tidak putus meski pengguna mengganti hosting, dan siapa pun bisa membuat aplikasi baru berdasarkan data yang sudah ada
    ActivityPub tidak memungkinkan hal semacam itu, dan pada akhirnya lebih mirip sekumpulan layanan kecil yang terpusat, di mana hosting dan aplikasinya menyatu lalu saling mengirim pesan
  • Menurut saya perbedaan penting lainnya adalah kenapa Tangled bahkan sebelum pendanaan sudah bisa meluncurkan produk di atas ATProto, sedangkan ForgeFed bertahun-tahun masih berjalan lambat
  • Ini juga sudah ditautkan di artikel aslinya, tetapi penulis ForgeFed sendiri menjelaskan di https://forgefed.org/blog/actor-programming/ kenapa ActivityPub kurang cocok untuk masalah ini

• Ada juga alternatif GitHub yang berjalan di atas Nostr dan relatif matang: https://gitworkshop.dev/
  Ide intinya adalah repositori bisa diunggah ke banyak relay nostr yang kompatibel dengan GRASP, jadi kalau satu server mati, sinkronisasi tetap bisa berlangsung secara transparan lewat tempat lain
  Karena itu, kalau memilih server yang tepercaya, uptime-nya pada praktiknya bisa mendekati 100%, dan repositori, aktivitas, issue, dan sebagainya juga ditandatangani secara kriptografis

  • Tidak terlihat sematang itu
    Dari namanya saja sepertinya sudah melanggar kebijakan merek dagang git
    https://git-scm.com/about/trademark
  • Saya harap saya salah, tetapi proyek itu tampak seperti closed source
  • Saya tidak bisa membuka repositori mana pun dengan benar di situs itu
    Beberapa memberi pesan bahwa browser tidak mendukung URL ssh atau https, beberapa lain hanya menampilkan Failed to load file tree lalu terus loading tanpa akhir
    Jadi saya kurang bisa menerima penilaian fairly mature itu

• Saya sangat mendukung federation, tetapi saya memang tidak pernah benar-benar memahami kegunaan federation of forges
  Sebenarnya data apa yang perlu dipertukarkan antarsesama forge?
  Kenapa forge untuk Blender harus terhubung dengan forge untuk Ubuntu?
  Nilai terbesar yang saya dapat dari GitHub adalah single sign-on untuk berpindah-pindah proyek; menurut saya forge independen pun bisa memberi banyak nilai yang sama hanya dengan mendukung social login, tanpa federation forge yang rumit

  • Pada akhirnya orang mencari software itu tetap mulai dari pencarian GitHub
    Kalau meng-host forge sendiri, kecuali namanya sudah sebesar Blender, tidak ada yang akan menemukan software itu
    Karena itu, agar kodenya tidak hilang ke kehampaan, mirroring ke GitHub nyaris jadi keharusan
    Kalau ingin menghindari itu dan membuat forge-forge kecil bisa bersaing sebagai satu kumpulan, diperlukan satu jaringan tunggal yang memungkinkan software ditemukan di host mana pun, dan ForgeFed memang menargetkan hal itu
    Ini juga mengurangi gesekan karena kontributor pemula tidak harus membuat login khusus untuk tiap forge, meski itu lebih merupakan manfaat tambahan dari masalah yang saling terkait
  • Git pada dasarnya didesain terdesentralisasi
    GitHub hanya memecahkan UI, issue, dan PR dengan baik sehingga pemula pun bisa bekerja dari layar, dan proses itu yang membuatnya menjadi terpusat
    federation lebih dekat dengan filosofi Git, tetapi tidak berarti harus sampai ke distribusi ekstrem di mana jika satu node mati, upstream hilang atau bahkan tidak bisa ditemukan
    Git tidak menyelesaikan masalah ketersediaan, dan menurut saya federation bisa menutup kekurangan itu sambil tetap mempertahankan filosofi desentralisasinya
  • Masalah terbesarnya pada akhirnya adalah discoverability
    Harus ada cara mudah menemukan proyek open source yang tersebar di banyak server
    Pencarian proyek GitHub hanya bekerja di dalam GitHub
  • identity provider yang interoperabel jelas berguna
    Selain itu, sistem seperti ini juga bisa menjadi lebih resilient ketika host proyek hilang, mengubah kebijakan, atau diblokir oleh pemerintah
  • Keunggulan di sini adalah data tinggal di satu tempat, yaitu PDS, dan kalau mau bisa di-self-host
    Lalu AppView mengumpulkan data dari banyak PDS dan menampilkannya dalam satu layar
    Kalau tangled.org suatu hari enshittify, kita tetap bisa lanjut memakai semuanya dari AppView lain mana pun dengan cara yang sama, dan tangled.org sendiri tidak punya posisi istimewa
    social login antar-forge independen memang membantu, tetapi secara pribadi saya lebih suka hanya punya satu akun untuk dikelola, dan berkat AT protocol, bahkan kalau sebuah forge hilang pun datanya tetap bisa diakses lewat AppView lain