Forge’ların federasyonuna ihtiyaç var
(blog.tangled.org)- Açık kaynak işbirliği, tek bir sağlayıcıya büyük ölçüde bağımlı bir yapı yerine, kod aktarımı ile iletişimi ayrı ayrı üstlenen dağıtık protokoller kombinasyonunun daha tercih edilir olduğu düşüncesine dayanıyor
- Kod işbirliği başlangıçta git ve e-posta kombinasyonuyla yürütülüyordu; daha sonra git ve GitHub web sitesi kombinasyonuna geçti, ForgeFed ise git ile ActivityPub’ın, Tangled da git ile AT protocol’ün birleşimi olarak devam ediyor
- Tangled, git sunucuları arasındaki olayları federasyon yapısıyla bağlıyor; her sunucuya knot adı veriliyor ve sunucular farklı olsa da depo işbirliğini, sunucular arası fork işlemlerini ve başka sunuculardaki depolara pull request göndermeyi destekliyor
- Kod etrafındaki Authenticated Transfer için AT kullanılıyor; issues, pull requests, olay zaman akışı, follows ve stars birlikte ele alınıyor, ayrıca işbirlikçi daveti ve SSH açık anahtarı paylaşımı için de kullanılıyor
- Doğrudan bir cgit instance’ı çalıştırıp yamaları e-postayla gönderme akışına benzerken, aynı zamanda GitHub monokültüründen uzaklaşıp işbirliğinin sosyalliğini ve eğlencesini koruma yönelimi de ortaya çıkıyor
Forge federasyonunun gerekliliği
- Açık kaynak işbirliğinin önemli bir kısmını tek bir sağlayıcıya bağımlı bir yapıya bırakmak arzu edilir değil; bu yaklaşım, merkezi sistemlerden ziyade dağıtık protokollerin daha uzun ömürlü olduğu görüşüne dayanıyor
- Kod işbirliği her zaman iki protokolü birlikte kullandı; bunlardan biri kod aktarımı, diğeri ise iletişim için görev yaptı
- İlk akış git ve e-posta kombinasyonuydu
- Daha sonra git ve GitHub web sitesi kombinasyonuna dönüştü
- ForgeFed, git ile ActivityPub kombinasyonu olasılığını ele alıyor
- Tangled ise git ile AT protocol kombinasyonuyla inşa ediliyor
- Tangled, git sunucuları arasındaki olayları federasyonla bağlıyor ve her sunucuya knot adını veriyor
- Hangi sunucuda olursa olsun depo işbirliği mümkün
- Sunucular arası fork desteği sunuyor
- Kendi sunucunuzdaki depoya push yaptıktan sonra, tamamen farklı bir sunucuda barındırılan depoya pull request açabiliyorsunuz
- Bu yaklaşım, doğrudan bir cgit instance’ı işletip yamaları e-postayla gönderme akışına birçok açıdan benziyor
Tangled’ın üstlendiği rol
- Tangled, kod etrafındaki olayların Authenticated Transfer katmanı için AT kullanıyor
- issues ve pull requests gibi olayların iletiminde kullanılıyor
- Olay zaman akışı, follows, stars gibi sosyal özellikleri de birlikte ele alıyor
- vouches özelliğinin de yakında eklenmesi planlanıyor
- AT, işbirlikçi daveti ve SSH açık anahtarı paylaşımı için de kullanılıyor; bunun dışındaki kısımlarda mevcut git aynen kullanılmaya devam ediyor
- Açık kaynak, GitHub gibi bir monokültürden çıkma ihtiyacı duyuyor; aynı zamanda kod işbirliğinin sosyalliğini ve eğlencesini korumak da gerekiyor
- tangled alpha
- docs
- source
- discord
- bluesky
- twitter (x)
- feed
1 yorum
Hacker News görüşleri
Bunun Mastodon'dan ne kadar daha iyi olacağından pek emin değilim
Uygulamadan bağımsız bir barındırma katmanı var ve herkes kendi verisini barındırabiliyor; uygulamalar da bunun üstünde tüm host'lardaki veriyi toplayıp gösteriyor
Bu yüzden Mastodon tarzı bir defederation kavramı burada yok
Daha fazlasını merak ediyorsanız https://overreacted.io/open-social/ ve https://overreacted.io/a-social-filesystem/ bağlantılarına bakabilirsiniz
Hesaplar PDS üzerinde barındırılıyor ve kayıtlar da oraya gidiyor, ama uygulamada görünen içerik birden fazla PDS'den verileri toplayan AppView tarafından sunuluyor
Bu yüzden hangi PDS'de olursanız olun uygulama deneyimi merkezi bir servis gibi hissediliyor; ayrıca birden fazla AppView olabilir ve bunları kendiniz de barındırabilirsiniz
Bunun, bugün olduğu gibi fiilen küresel keşfedilebilirlik yaratmasının maliyeti biraz düşündürücü, ama bu yüzden bunu sadece bir başka Mastodon olarak görmek de doğru değil
Taraf seçmemek ya da kendi doğru bulduğunuz yolda ilerlemek de mümkün değil mi?
atprotocol tarafında epey aktif kullanan biri olarak taraflı olabilirim ama Tangled'ı kullanmaktan gerçekten memnunum
GitHub alternatifi olarak benim istediğim şeye en çok yaklaşan servis bu; özellikleri daha sade ama son 1 yıldır kişisel açık kaynak projelerimde ana social/git hizmetim oldu
Hesabım https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
Bluesky'dan bildiğim sosyal grafiğin devam etmesi sayesinde commit, PR ve issue'ların arkasındaki insanları sezgisel olarak bağlayabilmek hoşuma gidiyor; giriş de diğer atproto servisleriyle aynı olduğu için kullanışlı
Yakın zamanda yerleşik statik site desteği de geldi; böylece client-side web sitelerini ya da basit bir index.html dosyasını doğrudan repo içinden barındırmak için çok uygun oldu
Spindles build sistemi/action rolünü üstleniyor; Nix hayranı olmasam da benim ihtiyaçlarım için gayet iyi iş gördü
open API de iyi; atproto tabanlı standartları kullanarak kolayca bilgi görselleştirmeleri oluşturabildim, botlar yaptım ve npmx.dev'e birkaç özellik ekledim
İsterseniz kendi knot'unuzu (git sunucusu) ve runner'ınızı (Spindles) çalıştırabilirsiniz, isterseniz barındırılan sürümü kullanabilirsiniz; ama asıl önemli nokta sosyal özelliklerin ayrılmış olması, yani git sunucusu ayrı olsa bile issue ve PR konuşmaları ortak sosyal katmanda devam ediyor
Kusursuz değil ve navbar'daki alpha etiketi boşuna değil, ama açık kaynak geliştirme için kullanmaya devam etme olasılığım yüksek
Bunun ne kadar haklı bir kaygı olduğundan ise henüz emin değilim
Yorumların genel havası oldukça olumsuz ama ben de VC fonlamasına temkinli yaklaşan biri olarak bu alandaki rekabetin teşvik edilmesi gerektiğini düşünüyorum
Şu anda böyle bir şeyi bootstrap ederek başlatmak çok zor, hatta fiilen imkânsız görünüyor; ayrıca bunun dün HN üst sıralarında olan GitHub eleştirileriyle zamanlama açısından iyi örtüştüğü de doğru, ama yine de bu tür girişimleri desteklemek istiyorum
Umarım anlamlı bir ölçeğe ulaşır
Başlığı görünce heyecanlandım ama VC fonu aldığını öğrendiğim anda değerlendirme dışı kaldı
Para bile kazandırmayan, sevdiğim bir projeyi bir platforma koyacaksam, 5 yıl sonra rug pull yaşama ihtimali düşük olan bir yer seçmek isterim
VC destekli projelerin yatırım geri dönüşü üretmesi gerekir; dolayısıyla bir noktada mutlaka bir tür rug pull yaşanacağını düşünüyorum
Bu yüzden şu an ya ücret ödeyen müşteri olarak kullandığım ya da kooperatif benzeri, aidat ödeyip karar süreçlerinde oy hakkı veren servisleri tercih ediyorum
Bu yüzden kullanıcıların bunun olası olduğunu en baştan bilmesi gerekir
Yaklaşan gerçeklik buyken aşırı idealist bir söylem kullanan servislerden hoşlanmıyorum
Bunun yerine doğrudan servis ücreti alabilirler ya da gerçekten ideallere bağlılarsa non-profit olarak başlayabilirler; en azından gelir modeli konusunda açık olmalılar
Zor olduğu açık, ama özellikle federasyonu hedefliyorsanız bunun aynı hatta daha yüksek maliyetli değil, daha ucuz bir altyapıyla da mümkün olması gerekmez mi?
atproto veri modelini merak ediyorsanız https://overreacted.io/a-social-filesystem/ adresinde başlangıç düzeyine uygun bir yazı var
Biraz uzun ama büyük resmi oldukça net veriyor
Şimdiye kadar gördüğüm en iyi ATProto giriş yazısıydı
Acaba bu yazıları bir araya toplayan bir etiket ya da liste var mı?
Bana göre ihtiyaç olan şey forge federation değil, daha zengin bir git repo'nun kendisi
Fossil, ticket, forum ve wiki'yi deponun bir parçası olarak birleştirerek neredeyse %90 yol kat etmiş durumda; clone ettiğinizde bunlar da birlikte iniyor ve çevrimdışıyken de görüntülenebiliyor
Uçakta bile yanıt yazabilirsiniz; yetkiniz varsa hemen ya da bağlantı sonradan geri geldiğinde senkronize edebilirsiniz
Yine de belirli artifact türlerini doğrudan VCS'ye gömmek yerine, repo içine uygulamalar koyup bu uygulamaların hangi artifact'lere izin vereceğini, hangi kuralları uygulayacağını, kimin ne zaman upload/download yapabileceğini belirlemesi bana daha iyi görünüyor
Forge tarafı da yalnızca bu politikayı uygular ve web kullanıcılarına istedikleri şekilde render eder
Böyle olursa başka bir forge'a taşınmak da sonuçta repo'yu push etmek kadar basit olur
Son zamanlarda ticket sistemi veya ajan benzeri şeyleri git repo içinde flat files olarak yapıyordum; şimdi bunu repo yönetiminin kendisine kadar genişletmem gerektiğini düşünüyorum
Harika olabilir
Bana göre federated solution'ların temel sorunu sonuçta cold start
Mevcut büyük sunuculardan birine girerseniz kaçmak istediğiniz o merkezileşme sorununu yeniden kabul etmiş oluyorsunuz, ama karşılığında en baştan büyük bir ağ elde ediyorsunuz
Kendi sunucunuzu açarsanız ağınız 0, keşfedilebilirliğiniz 0, feed'iniz boş oluyor ve diğer siteleri sizinle federasyon kurmaya ya da sizi tek kişilik bir sunucu diye engellememeye ikna etmeniz gerekiyor
Bunu sadece ben mi böyle hissediyorum, yoksa federasyonu yanlış mı anlıyorum bilmiyorum
Belki de bu sadece Mastodon'a özgü bir sorundur
Tek tek sunucuları merkezi AppView'lerin bir araya getirip merkezi bir ağ gibi tutarlı tek bir görünüm sunacak şekilde tasarlanmış
AppView'i herkes barındırabilir
atproto'da her sunucu yarı izole bir bölge gibi davranmıyor
Dağıtık sistemler açısından bunu açıklayan https://atproto.com/articles/atproto-for-distsys-engineers yazısı oldukça iyi
Büyük bir sunucu moderasyon, politika, içerik ya da teknik sorunlar yüzünden şüpheli hale gelirse oradan görece kolay çıkıp başka, yine oldukça büyük bir sunucuyu büyütmek ya da oraya taşınmak mümkün
Yani baştan belli bir itibar ve ölçeğe sahip sığınaklar oluşturulabilir
Zaten GitLab, Codeberg, freedesktop, Fedora, Debian gibi alternatif forge'lar var; proje görünürlüğü ve keşfedilebilirlik korunabildiği sürece bunlar yeterince güvenli sığınaklar olabilir
Ama birkaç gün önce bu projeyi görünce bunun gerçekten işe yarayabileceğini düşündüm
Çünkü hedef kullanıcı kitlesi, self-hosting'e alışık kesimle oldukça fazla örtüşüyor
Tüm ağımın burada olmasına gerek yok; fiilen buraya gelme ihtimali olan o alt küme bile yeterince faydalı
Frontend sunucu maliyetleri çok düşük olacaktır, bu yüzden neredeyse kalıcı biçimde çalıştırmak mümkün görünüyor; gerçek veriyi ise başka host'lar sağlıyor
Tangled'ın VC destekli olması bana güven vermekten çok mutlaka büyümek zorunda olduğu baskısını çağrıştırıyor
Cazibesini pek göremiyorum
Federatif olsa bile geliştirme durursa hataları kimin düzelteceğini ve bakımı kimin yapacağını merak ediyorum
Yani tamamen yeniden üretilebilir ve en düşük maliyetle bütünüyle self-host edilebilir hale getirmek
VC fonu amaç değil araç; Avrupa'da yaşayan iki Hintli kurucu için hibeler fiilen alınabilir hale gelene kadar 4-12+ ay sürdüğünden pek gerçekçi değilmiş
Ekip kurmanın, altyapı oluşturmanın ve geliştirmeyi hızlandırmanın en hızlı yolu VC olmuş; ayrıca yatırımcılarla hedef uyumunu güçlü biçimde kurmuşlar ve bu partneri bulmak için 6 aydan fazla zaman harcamışlar
Tangled yapısal olarak ilginç tercihlere sahip olsa da kodun kendisi nispeten sade ve benim incelediğim kadarıyla bakım zorluğu yüksek görünmüyor
Büyük ölçüde gevşek bağlı Go modules'lardan oluşuyor; üstüne statik HTML+CSS, biraz TypeScript ve orkestrasyon için Nix eklenmiş
Yanlış hatırlamıyorsam donanım gereksinimleri de oldukça düşük; mevcut ölçekte tek bir kişi bunu barındırabilir
Altyapı yükünün büyük kısmını zaten kullanıcıların knots'u, spindles'ı, PDS'leri ve genel olarak atproto ekosistemi taşıyor
Neden özellikle VC gerekli ve neden Ladybird örneğinde olduğu gibi kurumsal sponsorluk tercih edilmiyor?
Bir de yatırımcılar 10x getiri beklerken, sonunda enshittification yaşayacak bir geliştirici aracına neden zaman harcayayım?
4 standart varken bunları birleştirelim diye yeni bir standart yapınca sonunda 5 standart olur esprisini hatırlatıyor
Espri bir yana, ActivityPub'ın neden yetersiz olduğuna dair daha güçlü bir gerekçe görmek isterim
Merkezsiz iletişim sorununu yeniden bir başka şekilde çözmeye kalkmadan önce
Bunları karşı karşıya koymak, e-posta varken neden web'e ihtiyaç var diye sormaya benziyor
ActivityPub, e-posta gibi sunucuların gelen kutusu işlevi gördüğü ve birbirlerine mesaj gönderdikleri bir yapı
Buna karşılık atproto, web gibi kullanıcı depolarının veriyi barındırdığı ve uygulamaların bu depolardan verileri toplayıp gösterdiği bir yapı
Topolojideki bu fark, özellikleri de değiştiriyor; atproto'da kullanıcı barındırmasını değiştirseniz bile uygulama deneyimi kesintiye uğramıyor ve herkes mevcut veriler üzerinden yeni uygulamalar geliştirebiliyor
ActivityPub buna izin vermiyor; sonuçta daha çok barındırma ile uygulamanın birleştiği küçük merkezi servislerin birbirine mesaj gönderdiği bir yapı ortaya çıkıyor
Nostr üzerinde çalışan görece olgun bir GitHub alternatifi olarak https://gitworkshop.dev/ de var
Temel fikir, depoların birden fazla GRASP uyumlu nostr relay'ine yüklenebilmesi ve bir sunucu düşerse diğerleri üzerinden şeffaf biçimde senkronize olabilmesi
Böylece güvenilir sunucular seçerseniz pratikte neredeyse %100 uptime elde edebilir ve repo, aktiviteler, issue'lar gibi şeyleri kriptografik olarak imzalayabilirsiniz
İsmi bile git'in ticari marka politikasını ihlal ediyor gibi duruyor
https://git-scm.com/about/trademark
Bazılarında tarayıcının ssh ya da https URL'lerini desteklemediği yazıyor, bazılarında ise sadece
Failed to load file treeçıkıp sonsuza kadar yükleniyorBu yüzden fairly mature nitelemesi bana pek ikna edici gelmiyor
Federasyonu güçlü biçimde destekliyorum ama federation of forges fikrinin kullanım alanını hep anlamakta zorlandım
Forge'lar birbirleriyle tam olarak hangi veriyi paylaşacak?
Blender için olan bir forge neden Ubuntu için olan bir forge ile bağlantı kursun ki?
Benim GitHub'dan aldığım en büyük değer, projeler arasında geçerli olan tek bir giriş sistemi; bağımsız forge'lar da karmaşık bir forge federasyonu olmadan sadece social login desteği vererek bunun önemli bir kısmını sağlayabilir
Kendi forge'unuzu barındırırsanız, Blender gibi zaten büyük bir isim değilseniz kimse yazılımınızı bulamaz
Bu yüzden kodun boşluğa karışmaması için en azından GitHub aynalaması neredeyse zorunlu hale geliyor
Bunu önlemek ve daha küçük forge'ların birlikte rekabetçi olmasını sağlamak için, yazılımın hangi host'ta olduğuna bakmadan bulunabildiği tek bir ağ gerekiyor; ForgeFed tam olarak bunu hedefliyor
Yeni katkı verecek kişilerden her seferinde ayrı bir forge hesabı açmalarını istemek gibi sürtünmeleri de azaltıyor; bu ikincil bir fayda olsa da bağlantılı bir mesele
GitHub ise UI, issue ve PR süreçlerini iyi çözerek yeni başlayanların ekrandan çalışmasını sağladı ve bu süreçte merkezileşti
Federasyon, Git'in felsefesine daha yakın ama bir düğüm kapanınca upstream'in tamamen kaybolduğu ya da bulunamadığı kadar uç bir dağıtıklığa gitmek de gerekmiyor
Git erişilebilirlik sorununu çözmüyor; federasyon ise merkezsiz felsefeyi korurken bu erişilebilirliği güçlendirebilir
Dağınık sunucular üzerindeki açık kaynak projeleri kolayca bulmanın bir yolu gerekli
GitHub proje araması sadece GitHub içinde çalışıyor
Bunun yanında proje host'u kaybolduğunda, politikasını değiştirdiğinde ya da bir hükümet tarafından engellendiğinde sistem daha resilient hale gelir
Ardından AppView, birden fazla PDS'den veriyi toplayıp tek bir ekranda gösteriyor
Eğer tangled.org enshittification yaşarsa, başka herhangi bir AppView üzerinden aynı şekilde kullanmaya devam edebilirsiniz; tangled.org'un ayrıcalıklı bir konumu yok
Bağımsız forge'lar arasında social login de yardımcı olurdu ama şahsen yönetmem gereken hesabın tek olmasını tercih ederim; ayrıca AT protocol sayesinde tek tek forge'lar ortadan kalksa bile verilere başka AppView'ler üzerinden erişmeye devam edebilirsiniz