Migrasi proyek Dillo dari GitHub

 (dillo-browser.org)
2 poin oleh GN⁺ 2025-12-01 | 1 komentar | Bagikan ke WhatsApp
  • Proyek peramban web Dillo sedang bermigrasi dari GitHub ke server yang di-host sendiri
  • Alasan utama migrasi yang diajukan meliputi ketergantungan pada JavaScript, struktur kontrol terpusat, dan performa yang lambat di GitHub
  • Server baru beroperasi di domain dillo-browser.org dan menggunakan frontend Git ringan berbasis cgit serta pelacak bug buatan sendiri bernama ‘buggy’
  • Semua data dikelola sebagai repositori git dan dicerminkan ke Codeberg dan Sourcehut, sehingga meminimalkan risiko kehilangan data
  • Dirancang agar tetap dapat dipercaya bahkan saat DNS hilang melalui tanda tangan OpenPGP, sehingga memperkuat kemandirian dan keberlanjutan proyek

Latar belakang

  • Dahulu, situs asli Dillo adalah dillo.org, yang mencakup repositori Mercurial, server mail, pelacak bug, dan arsip milis
    • Pada 2022, domain tersebut hilang, dan pihak ketiga membuka situs serupa yang dipenuhi iklan AI
    • Sebagian materi berhasil dipulihkan, tetapi tidak sepenuhnya lengkap
  • Pengalaman ini mendorong keputusan untuk menghindari ketergantungan pada satu situs dan membangun struktur cadangan yang terdistribusi
  • Awalnya kode diunggah ke GitHub, tetapi kemudian dinilai tidak cocok untuk jangka panjang

Masalah di GitHub

  • GitHub berguna untuk workflow CI dan pengelolaan repositori, tetapi memiliki berbagai keterbatasan
    • Frontend tidak berfungsi tanpa JavaScript, sehingga isu atau PR tidak dapat dilihat dengan peramban Dillo
    • Halaman menggunakan sumber daya secara berlebihan dan menimbulkan beban yang tidak perlu hanya untuk merender HTML sederhana
  • Ada risiko akun diblokir oleh satu entitas pengendali, yang dapat memutus akses ke data
  • Platform semakin lambat dan menuntut koneksi internet yang cepat
  • Sistem notifikasi “push model” GitHub tidak cocok dengan gaya pengembangan yang berfokus pada kerja offline
  • Kurangnya alat pengelolaan komunitas pada proyek dengan proporsi pengguna non-pengembang yang tinggi meningkatkan kelelahan pengembang
  • Ketika GitHub beralih ke fokus pada LLM dan AI generatif, situs-situs memperkuat tembok JavaScript atau pelacakan sidik jari browser untuk memblokir crawler LLM
    • Efek sampingnya, akses pengguna Dillo ikut terblokir

Membangun hosting sendiri

  • Layanan forge yang ada tidak mampu sekaligus menghilangkan single point of failure dan mempertahankan operasi yang ringan
    • Karena itu diputuskan untuk mengoperasikan server sendiri dan mempertahankan beberapa mirror
  • Domain dillo-browser.org dibeli dan server VPS kecil dibangun
    • Operasinya ternyata lebih stabil dari perkiraan, dan sebagian besar hanya menangani trafik bot AI
  • cgit dipilih sebagai frontend Git
    • Ditulis dalam bahasa C sehingga penggunaan RAM dan CPU rendah, serta berfungsi tanpa JavaScript
    • Sebagian CSS dimodifikasi agar tampil baik di Dillo
    • Dapat diakses di https://git.dillo-browser.org/
  • Pelacak bug menggunakan ‘buggy’ yang dikembangkan sendiri
    • Mengurai file Markdown untuk menghasilkan halaman HTML, dan setiap bug disimpan di repositori git
    • Saat commit, git hook secara otomatis memperbarui halaman
    • Bisa diedit secara offline dan tidak menimbulkan kekhawatiran celah keamanan
    • Tersedia di https://bug.dillo-browser.org/
  • Arsip milis disimpan secara terdistribusi di 3 layanan eksternal, dan salinan internal akan ditambahkan di masa mendatang

Pengaturan mirror

  • Semua data inti dikelola dalam bentuk repositori git dan dicerminkan ke Codeberg dan Sourcehut
    • Bahkan jika repositori tertentu berhenti beroperasi, biaya perpindahan ke mirror lain tetap rendah
  • Satu-satunya titik kegagalan tunggal adalah DNS (dillo-browser.org)
    • Jika DNS hilang, pengguna dapat diberi tahu melalui milis, Fediverse, IRC, dan sebagainya
    • Karena data direplikasi di git, kehilangan fatal tidak akan terjadi

Tanda tangan OpenPGP

  • Halaman ini ditandatangani dengan kunci GPG Rodrigo Arias Mallo (32E65EC501A1B6FDF8190D293EE6BA977EB2A253)
    • Ini adalah kunci yang sama dengan rilis terbaru Dillo, dan juga terdaftar di akun GitHub
    • File tanda tangan (index.html.asc) ditautkan melalui <link rel=signature>
  • Tanda tangan OpenPGP memungkinkan kepercayaan tetap dipertahankan meski DNS hilang
    • Kepemilikan dibuktikan berdasarkan kepercayaan pada tanda tangan, bukan rantai sertifikat TLS
    • Tanda tangan disertakan di semua mirror git untuk memperkuat ketahanan terhadap kehilangan data

Progres migrasi dan prospek

  • Repositori GitHub tidak akan langsung dihapus dan akan terus diperbarui sampai migrasi selesai
    • Setelah selesai, repositori akan diubah ke status ‘archived’ dan diumumkan di situs resmi
    • Commit yang ada dan file rilis akan dipertahankan demi kompatibilitas build lama
  • Infrastruktur baru ini dapat dioperasikan secara mandiri dengan biaya dan konsumsi energi yang rendah
    • Berdasarkan donasi saat ini dan biaya server, dapat dipertahankan setidaknya selama 3 tahun
    • Jika ingin mendukung, bisa memberi bantuan melalui Liberapay (https://liberapay.com/dillo/)

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-01
Komentar Hacker News

  • Selama beberapa tahun saya memakai GitLab sebagai alternatif self-hosted. Saya suka, tetapi sangat boros sumber daya
    Belakangan ini saya sedang menguji Forgejo buatan tim Codeberg, dan ini benar-benar luar biasa
    Perbedaan terbesarnya ada pada penggunaan memori. GitLab berbasis Ruby on Rails sehingga banyak layanan berjalan bersamaan, sedangkan Forgejo adalah arsitektur biner tunggal yang ditulis dalam Go
    GitLab perlahan menghabiskan memori VM 16GB, tetapi Forgejo hanya memakai sekitar 300MB bahkan saat server dan runner dijalankan bersama
    Tidak ada GraphQL, tetapi REST API tampaknya sudah cukup bagus
    Saya kurang paham perbedaan gitea dan forgejo, tetapi melihat dokumen perbandingan Forgejo, sepertinya ini adalah soft fork pada 2022 karena masalah tata kelola

    • Studio kami memiliki sekitar 50 pengguna yang memakai git setiap hari, dan 2 tahun lalu kami sepenuhnya bermigrasi ke Forgejo
      Karena strukturnya sederhana dan berbasis Go, perawatan dan biayanya sangat rendah. Kami juga membangun alat internal langsung di atas Forgejo
      Karena di-host on-premise, pengembangan dan CI tidak berhenti meski internet putus. Ia juga mendukung cache package manager sehingga pengelolaan dependensi jadi mudah
    • Untuk kemudahan pemeliharaan, gitea jauh lebih unggul. Saya sudah memakainya lebih dari 5 tahun, dan upgrade selesai hanya dengan pull versi baru lalu restart daemon
      Dibanding GitHub, downtime-nya 10 kali lebih sedikit, dan itu pun sebagian besar adalah pemeliharaan terjadwal
      Kalau ada tulisan yang mengklaim availability GitHub lebih baik, rasanya lucu
    • Untuk proyek pribadi, saya rasa cukup pakai server SSH dan file system saja
      Saat membuat repositori baru, cukup git init --bare, dan backup juga berjalan otomatis
      Kalau mengembangkan sendirian, rasanya UI memang tidak terlalu diperlukan
    • Jika melihat dokumen konsep dasar Forgejo Actions, sistem CI-nya tersusun rapi
      Saya rasa CI ala GitLab jauh lebih baik daripada GitHub Actions, GitHub memang jadi standar berkat popularitasnya, tetapi desainnya terasa kurang memuaskan
    • Jika ingin alternatif yang lebih minimal, ada juga Gerrit. Ini aplikasi Java tanpa ketergantungan DB eksternal, dan menyimpan konfigurasi serta informasi runtime di repo git
      Hanya dengan file system bersama, scaling dan backup pun jadi sederhana

  • Saya menjalankan klub matematika di daerah, dan anak-anak memakai Forgejo untuk mengumpulkan tugas LaTeX dan Python
    Pengelolaan login dan reset kata sandinya mudah, jadi sangat berguna juga untuk pendidikan

  • Saya setuju dengan pendapat yang tidak menyukai model notifikasi push GitHub dan ingin melihat pembaruan hanya saat memeriksanya sendiri
    Dengan memanfaatkan penyaringan email, notifikasi push bisa diubah seperti model pull. Kumpulkan notifikasi di folder khusus lalu lihat hanya saat diperlukan

    • Kalau itu pun masih tidak memuaskan, tinggal pakai fitur notifikasi bawaan di UI GitHub. Jujur saja, rasanya seperti mempermasalahkan sesuatu demi mencari masalah

  • Menarik membaca cerita dari orang yang membuat sendiri bug tracker sederhana bernama 'buggy'. Katanya ini alat C yang mem-parsing Markdown dan menghasilkan halaman HTML
    Semangat hacker-nya masih hidup

    • Tapi saya rasa hampir tidak ada orang yang akan mengambil pendekatan seperti itu. Kalau saya, malah terasa hanya akan menambah masalah
    • Ini pendekatan yang punya kelebihan dan kekurangan

  • Ada pertanyaan yang menanyakan perbedaan antara “model push” dan “model pull”

    • Sepertinya yang dimaksud adalah workflow berbasis email seperti Source Hut atau kernel Linux. Dengan IMAP, patch bisa diambil ke lokal dan dikerjakan bahkan saat offline
    • Push membawa tekanan waktu seperti “kerjakan sekarang juga”, sedangkan pull adalah perbedaan cara mengelola waktu, yaitu memeriksa sesuai ritme yang saya tentukan sendiri

  • Saya rasa sekarang kita sedang berada pada fase diaspora ketika berbagai alternatif GitHub bermunculan sekaligus
    Dalam beberapa bulan, bisa saja satu arus utama mulai mengerucut. Kalau ada perusahaan atau tokoh terkenal meluncurkan platform baru, mereka juga bisa memimpin pasar

    • Arus seperti ini sudah ada sejak 10 tahun lalu. Dulu masa orang-orang pindah ke GitLab, dan bahkan sekarang discoverability GitHub masih tetap tak tertandingi
      Proyek yang meninggalkan GitHub masih sangat sedikit, jadi menurut saya masih terlalu dini
    • Karena setiap pengembang punya cara kolaborasi yang berbeda, sulit untuk mengerucut ke satu solusi saja
      Justru sedang terjadi re-decentralization. Ini zaman ketika masing-masing memilih forge yang sesuai dengan kontrol, yurisdiksi, dan workflow mereka sendiri
    • Ke depannya, tujuannya adalah menuju struktur federation alih-alih terpusat seperti GitHub. Jadi kita tidak lagi bergantung pada satu entitas
    • Yang penting adalah apakah kita menginginkan ‘satu pengganti tunggal’, atau ingin mengulang situasi yang sama lagi 5 tahun dari sekarang
    • Kami sedang mencoba tepat itu. Kami sedang menyiapkan platform kolaborasi berfokus indie bernama Tangled, dan sebentar lagi akan ada pengumuman besar

  • Saya ingin mengundang proyek Dillo ke Tangled → tangled.org

    • Mengesankan bahwa ini tetap bekerja dengan baik tanpa JavaScript
    • Saya harap nanti juga mendukung sistem kontrol versi selain Git

  • Saya rasa masalah terbesar GitHub adalah pengalaman penggunaan yang makin lambat

    • Saya penasaran apakah ungkapan “more and more slow” terdengar alami. Apakah “slower and slower” lebih umum?
    • Dulu tidak masalah, tetapi belakangan pemuatan halaman terasa terlalu lambat. Sepertinya bukan semata karena React
      Untuk penjelajahan kode saya mengandalkan github.dev, tetapi PR dan Actions tetap lambat dan membuat frustrasi

  • Jika ingin memasang Forgejo di VM, saya sudah membuat skrip yang bisa menyiapkan server dan runner sekaligus → easyforgejo

  • Saya bukan ahli di topik ini, tetapi tetap membacanya dengan menarik
    Mengejutkan bahwa ada begitu banyak hal yang perlu dipertimbangkan hanya untuk menyiapkan satu sistem kontrol versi
    Saya memakai Fossil, dan untuk organisasi kecil saat satu orang merangkap sebagai developer, admin sistem, dan staf dukungan, ini jauh lebih sederhana
    Batasan deploy key GitHub juga merepotkan. Saat menjalankan banyak aplikasi dan server, saya harus mengatur key terpisah untuk masing-masing, dan itu cukup merepotkan