Tangled - atproto tabanlı Git iş birliği platformu

 (blog.tangled.org)
3 puan yazan GN⁺ 2025-10-12 | 2 yorum | WhatsApp'ta paylaş
  • Tangled, AT Protocol tabanlı, sosyal özelliklere sahip bir Git iş birliği platformudur; geliştiricilerin kod üzerindeki tam sahipliğini korurken açık kaynak topluluklarının özerk biçimde işletilebilmesi için tasarlanmıştır
  • Mevcut ActivityPub(Forgejo) odaklı federasyon modelinin ve Radicle'ın tamamen P2P modelinin güçlü yanlarını birleştiren dağıtık bir kod iş birliği yapısı benimser
  • Temel kavram olan 'Knot', hafif bir headless Git sunucusudur; hem bireysel self-hosting hem de topluluk düzeyinde çok kiracılı ortamları destekler
  • App View(tangled.sh), ağ genelindeki depoları birleşik bir görünümde sunarak farklı Knot'lardaki depoların sorunsuz biçimde keşfedilmesini, klonlanmasını ve katkı verilmesini sağlar
  • Şu anda beta aşamasındadır; veri sahipliği, düşük giriş engeli ve kullanıcı deneyiminin korunmasını temel ilkeler olarak benimser ve gelecekte tamamen açık, dağıtık bir Git ekosistemi kurmayı hedefler

Tangled'e genel bakış

  • Tangled, geliştiricilerin kod ve kimlik sahipliğini korurken sosyal etkileşime olanak tanıyan bir Git iş birliği ortamı sunan yeni bir platformdur
  • AT Protocol üzerine kuruludur ve merkeziyetsiz sosyal uygulama mimarisini Git iş birliğine uygular
  • Amaç, kod iş birliğini yeniden açık ve keyifli bir süreç haline getirmektir

Dağıtık model ve AT Protocol

  • Mevcut dağıtık kod iş birliği modellerinde şu yaklaşımlar bulunur
    • Forgejo(ActivityPub): sunucular arası federasyon yoluyla iş birliği
    • Radicle: tamamen P2P(peer-to-peer) yapı
  • Tangled, iki modelin avantajlarını birleştirerek merkezi kimlik yönetimine olanak tanıyan atproto'yu benimser
  • Böylece kullanıcılar, dağıtık ağ içinde bile tutarlı bir kimlik ve kimlik doğrulama yapısını koruyabilir

Knot yapısı

  • Knot, Tangled'ın temel bileşenidir; kullanıcıların doğrudan Git depoları barındırabilmesini sağlayan hafif bir sunucudur
    • Hem tek kiracılı hem çok kiracılı yapılandırmaları destekler
    • Raspberry Pi gibi küçük cihazlarda da self-hosting yapılabilir
  • Tangled, varsayılan olarak ücretsiz yönetilen Knot hizmeti sunar
  • Bu yapı sayesinde, kullanıcıların kişisel sunucuları ile topluluk sunucularını doğal biçimde bağlayan dağıtık bir Git ağı oluşur

App View ve birleşik ağ

  • tangled.sh tarafından sunulan App View, tüm ağdaki depoları tek bir birleşik görünüm içinde gösterir
  • Kullanıcılar, başka Knot'larda bulunan depolar için bile clone ve contribute işlemlerini kolayca gerçekleştirebilir
  • Bu tasarım, Git'in mevcut iş akışını korurken dağıtık ortamın engellerini ortadan kaldırır

Geliştirme ilkeleri

  • Tangled ekibi, geliştirme yönünü belirlemek için şu üç ilkeyi tanımlamıştır
    • 1. Veri sahipliği — her kullanıcı, oluşturduğu kod ve metaverinin doğrudan sahibidir
    • 2. Düşük giriş engeli — herkesin kolayca katılabilmesi için basit yapı ve arayüz sunulması
    • 3. Kullanıcı deneyiminde tutarlılık — dağıtık yapıya rağmen merkezi hizmet düzeyinde UX sağlanması
  • Bu ilkeler, Tangled'ın teknik tercihleri ile UI/UX tasarımının geneline yansır

Erişim ve topluluk

  • Başlangıçta davet tabanlı erişim(invite-only) ile işletiliyordu; geliştiriciler #tangled IRC kanalı (libera.chat) üzerinden katılabiliyordu
  • Şu anda açık giriş durumundadır; herkes tangled.sh/login üzerinden kullanabilir
  • Tangled hâlâ erken aşamada olsa da, kendi içinde kullanım (dogfooding) yoluyla özelliklerini doğrulayarak büyümeyi sürdürüyor

Sonuç

  • Tangled, Git iş birliğini sosyal ağ gibi bağlantılı bir deneyime dönüştürme girişimidir
  • Özerklik, erişilebilirlik ve keyifli geliştirme kültürünü birleştiren yeni bir dağıtık Git platformu ekosistemi olarak dikkat çekmektedir

İlgili okumalar

2 yorum

 
lamanus 2025-10-12

Resmi bir container olmadığı için ilk kurulum biraz zahmetliydi.
 
GN⁺ 2025-10-12
Hacker News yorumları
  • Tangled'ın kurucu ortaklarından biri olarak, yakın zamanda OAuth kütüphanesini değiştirirken yeni kullanıcıların varsayılan knot ve spindle'a (dahili git barındırma sunucusu ve CI runner) eklenmemesine yol açan bir sorun oluşmuştu; az önce düzeltme yamasını uyguladım, çıkış yapıp tekrar giriş yaparsanız artık normal şekilde repository oluşturabilirsiniz, sorularınız varsa her zaman yanıtlayabilirim
    • İlk soru, tngl.sh PDS'de handle değiştirmenin veya hesabı silmenin mümkün olup olmadığıyla ilgili. İkincisi ise yeni bir AppView oluşturup çalıştırmak için gereken kaynaklar hakkında: örneğin Cloudflare Pages gibi statik web sitesi klasörünü yükleyip olduğu gibi servis eden PDS tabanlı bir AppView kurarsam, AppView operatörü yüksek trafik maliyetinin tamamını üstlenmek zorunda mı? Böyle bir yapıda operasyon yükünün nasıl olduğunu merak ediyorum
    • Tangled, “social-enabled” ifadesini kullanmış; bunun AT protokolüyle ilgili olduğunu tahmin ediyorum. İleride Tangled içinde daha çeşitli sosyal özellikler planlanıyor mu, yoksa bu sadece AT protokolü desteği anlamına mı geliyor, merak ediyorum
  • Bu projenin gerçekten harika olduğunu düşünüyorum; mevcut code forge hizmetlerinin tekelci yapısını sökmeye çalışma fikri hoşuma gidiyor. Bu alana ilgi duymamın nedeni, code forge'ların bir sürü sorunu aynı anda çözmeye çalışırken aslında verimsiz hale gelmesi. Çoğu forge; git repository, web görüntüleyici, iş birliği araçları, CI/CD pipeline'ları, iş takibi gibi çeşitli işlevleri tek yerde topluyor. Ama bu özelliklerin ille de tek bir pakette olması gerekmediğini düşünüyorum. Örneğin git deposuna doğrudan erişim gerekmiyorsa, https://pgit.pico.sh gibi tamamen statik bir web görüntüleyici sunulabilir; ya da iş birliği için patch'leri ayırıp yerelde incelemeyi ve yönetmeyi sağlayan ayrı bir sunucu (https://pr.pico.sh) olabilir. Hatta bir VPS'e sadece bare git deposu koymak bile yeterli ve bu gerçekten çok kolay. Git zaten dağıtık bir sistemken, diğer yan hizmetler yüzünden merkezileşmesi bence anti-pattern
    • İnsanlar sık sık “Git zaten dağıtık” diyor ama gerçekte dağıtıklık kavramının belirsiz tarafları var. Git'in kendisi dağıtıklığa odaklanmaktan çok genelde master-slave protokol temelli (HTTP vb.) çalıştığı için, sonuçta merkezileşmenin tekrarlandığı bir eğilim ortaya çıkıyor
    • Hizmetler birden fazlaysa güven sorunu doğuyor. İhtiyaçların %80'ini karşılayan tek bir hizmeti mi denetleyeceksiniz, yoksa ayrı ayrı 10 hizmeti mi doğrulayacaksınız, bunu düşünmek gerekiyor. Ayrıca altyapıda ölçek ekonomisinin ve birden fazla özelliğin entegrasyonuyla gelen avantajların da önemi var. Bu yüzden hâlâ monolitik yapıları tercih eden çok insan var. Sonuçta geliştirici deneyimi açısından ciddi trade-off'lar söz konusu
    • VPS'te git remote repository kurmak gerçekten çok kolay; SSH erişimi varsa hemen çalışıyor. Asıl mesele bence 'lock-in' yani hizmete bağımlılık. GitHub gibi hizmetler neden doğrudan hizmet sunmaktan çok lock-in'e odaklanıyor? Bunun arkasında finansman ve iş modeli var. Merkezileşme → lock-in → gelir zinciri pek çok hizmette sürekli karşımıza çıkıyor. Hizmetin kendisinden doğrudan gelir üreten bir yapı yoksa, bunun kaçınılmaz olduğunu hissettim
    • Teknik olarak işlevleri ayırmak imkânsız değil ama ekonomi tarafında her özelliğin ayrı ayrı sürdürülebileceği bir gelir yapısı yok; kullanılabilirlik tarafında da insanlar 'batteries-included' rahatlığını istiyor. Açık kaynak dünyasında da ekonomik gerçekleri göz ardı eden pek çok örnek var ama sonuçta çoğu, tek bir bakımcının tükenmesiyle yok olup gidiyor. En başarılı açık kaynak projeleri bile çoğunlukla kurumsal sponsorlar ya da mühendislerin desteğiyle ayakta kalıyor
    • Ayırmak zorunlu değil ama entegre olması kesinlikle çok daha kullanışlı
  • Yakın zamanda Jujutsu desteği haberini JJ Con'da öğrendim, ayrıntılar https://blog.tangled.org/stacking adresinde
    • Bu hizmet gerçekten stacked PR destekliyor. GitHub bunu onlarca yıldır yapamıyordu. Eğer bunu şirkette özel olarak kullanmak istesem, Tangled instance'ının dış ağa bağlanmamasını nasıl ayarlayacağımın belirsiz olması biraz hayal kırıklığı yaratıyor
  • GitHub'a artık güvenilemeyeceğini düşünüyorum. En azından OSS stack'ini AT protokolü ya da başka açık ağlara taşımak, büyük şirketler ve sansür gibi risklere karşı korunmak için iyi bir yöntem gibi geliyor. Bu yüzden böyle girişimleri görmek sevindirici
    • Ama çoğu insan kendi sunucusunu işletmek istemiyor. Bunu ancak büyük OSS organizasyonları kaldırabilir. Hatta e-posta dışında PR bile sağlamak zor bir durum
  • tangled'a katılan ilk 100 kişiden biriyim. Stacked patch tarzı PR inceleme yol haritası ve özellik geliştirme hızları etkileyiciydi; topluluğun heyecanından da olumlu enerji aldım. Bundan sonra nasıl gelişeceğini gerçekten merakla bekliyorum. Böyle istikrarlı şekilde ilerlerse çok daha iyi bir deneyim, daha temel bir kontrol ve uzun vadeli sürdürülebilirlik sağlanabileceğini düşünüyorum
  • Daha dağıtık git iş birliği modellerine büyük ilgi duyuyorum. Sizce bu yaklaşımın yayılmasının önündeki en büyük engel nedir? Sunucu işletimi mi, özel anahtar yönetimi mi, yoksa sonuçta ağ etkisi mi? Görüşlerinizi merak ediyorum
    • En büyük engel spam, yasa dışı içerik ve genel moderasyon sorunları. PDS herhangi bir domain olabildiği ve tek bir PDS sınırsız kullanıcıyı barındırabildiği için, güvenin çöktüğü deneyimler çok yaşanıyor. İnsanlar git repo'larına tonla ebook ya da TV dizisi yüklerse ne yapılacağı, ya da bir proje politik nedenlerle spam saldırısına uğrarsa nasıl başa çıkılacağı gibi sorular ortaya çıkıyor. AppView kavramının iyi yanı, BlueSky'da olduğu gibi merkezi bir moderasyon ekibinin tutarlı politikalar uygulayabilmesi. Herkes istediğini yükleyebilir ama sonuçta frontend tarafında seçici kürasyon mümkün. Tabii merkezi moderasyon decisions da her zaman tartışmalı. Bu yüzden tamamen dağıtık bir ağın yükünü ve sorumluluğunu üstlenmek istememek anlaşılır. AT protokolünün açıklığı, Twitter benzeri hizmetlere kıyasla bir avantaj ama bunun karşılığında günlük yönetim ve yetkilendirmenin daha merkezileştiği yapılara da ihtiyaç duyuluyor. Kişisel olarak şu anda “cömert” bir radicle seed node operatörü olup anonim git yüklemelerine izin vermek isteyen biri çıkar mı, merak ediyorum
    • GitHub ücretsiz, dağıtıklık ise maliyetli
    • Tangled, kendi sunucunuzu işletmeden de git'i bağımsız kullanabilmeyi sağladığı için beni çok memnun ediyor. En büyük eksisi hâlâ çok yeni bir hizmet olması. Henüz geniş bir bilinirliği yok ve Bsky ile PDS'nin ne sunduğunu bilmeyen çok kişi var. Biraz daha fazla özellik ve alternate client görmek güzel olurdu. Yine de erken kullanıcıların şimdiden yeterince iyi bir deneyim yaşadığını düşünüyorum. Daha fazla geliştiricinin bu deneyimle tanışacağı günü bekliyorum
  • CI pipeline desteği olduğunu görmek sevindiriciydi ama yapısının GitHub Actions'a benzemesi biraz hayal kırıklığı yarattı. Basit ardışık çalıştırma için YAML kullanmak zorunda olmak gereksiz geliyor; bash script yeterli olabilir. Pipeline YAML'ının anlamı, program akışını değil bağımlılıkları (DAG) ifade ettiğinde ortaya çıkıyor. Buildkite bu açıdan çok daha iyi
  • Yarın “Spaghetti” adında no-code bir iş platformu ve “Lock-in” adında önemli veriler için bir kasa hizmeti çıkacak galiba
  • Şirkette mecburen GitHub public org kullanmak zorundayız. Code review'yu Tangled'da yapıp sonrasında GitHub ile senkronize etmek mümkün mü, jj tool inceleme deneyimini aynen koruyabilir miyiz merak ediyorum
  • Tangled'ı enterprise/private amaçlarla kullanmak mümkün mü merak ediyorum. Stacked diff inceleme akışı kurumsal işleyişe çok uygun görünüyor
    • Böyle bir olasılık var. Tamamen airgapped ve AT'den ayrılmış bir Tangled sürümü konuşuluyor. Oldukça büyük bir iş olduğu için hemen ilerletmek zor
    • Şu an için net bir kurumsal çözüm ayrı olarak mevcut değil. İlgili issue tartışmasını https://tangled.org/@tangled.org/core/issues/60 adresinde görebilirsiniz