Nitter'in halka açık son örneği bakıma muhtaç hale geldi. Nitter projesi, X.com/Twitter'a JavaScript, analitik, izleyiciler ve üçüncü taraf hizmetleri gerektirmeden erişmek için ücretsiz bir ön uç geliştirdi. 31 Ocak'ta Nitter'in X.com'daki içeriğe erişim sağlamak için kullandığı tokenlerin ihracı durduruldu. 26 Şubat'ta daha önce yayınlanan tokenlerin sonuncusunun süresi doldu ve bu da Nitter'in tamamen durmasına yol açtı.
Elon Musk tarafından satın alındıktan sonra Twitter (artık X olarak yeniden adlandırıldı), daha önce kârsız olduğu düşünülen platformdan agresif bir şekilde para kazanmayı amaçlayan bir dizi teknik ve organizasyonel önlem uygulamaya başladı. Değişiklikler arasında, her hesap tarafından alınan bilgiler için tarifeler uygulandı (farklı hesap türleri için sınırlar getirildi - ücretli “mavi onay işareti” sahipleri için 10000, normal hesaplar için 1000, yeni normal hesaplar için 500); Toplu veri çıkarmaya (kazımaya) uygun limitlere sahip “geliştirici” hesapları ücretli olanlar kategorisine aktarılmış; Hesabı olmayan kullanıcılara bilgi dağıtımı durdurulmuştur.
Gerekçe, botlar tarafından otomatik veri yüklemenin sıradan kullanıcılar için hizmetin bozulmasına yol açması nedeniyle bunların "geçici acil durum önlemleri" olduğu kamuya açıklandı (2023-07-01). Bundan önce (2023), Microsoft'a karşı şirketin yapay zekayı eğitmek için Twitter verilerini yasadışı bir şekilde kullandığına ilişkin imalar vardı. Daha sonra (04-19-2023), limitlerin getirilmesi, Musk'un vaat ettiği botlara karşı mücadeleyle meşrulaştırıldı.
Nitter, mesaj göndermeyen ancak yalnızca içerik okuyan Twitter kullanıcılarını, Twitter'ı görüntülemek için bir hesap veya JavaScript'in etkinleştirilmesini gerektirmeyen alternatif bir site sağlayarak takip edilmekten korumak için bir yazılım geliştirme projesiydi. Bu tür yazılımlar aslında verileri veritabanında depolamak yerine son kullanıcıya gönderen bir kazıyıcı ve aracıdır (ancak bazı hizmet verileri Redis'te önbelleğe alınır).
Böylece Nitter yazılımı:
Yeni koşullarda çalışmaya devam etmek için geçici çözümlerin analizi sonucunda, kayıtlı olmayan kullanıcılara JSON formatında bilgi sağlayan ve diğer sosyal ağlarla entegrasyon için kullanılan RSS ve syndication.twitter.com'daki bazı giriş noktaları keşfedildi. Bir süre Nitter bu arayüzler aracılığıyla bilgi aldı ancak daha sonra kapatıldılar. Bunun ardından okuma ayrıcalıklarına sahip “misafir hesaplarını” kullanmanın bir yolu bulundu. Bir tür "misafir hesabı" türü, sadeleştirilmiş tarayıcılara sahip Nesnelerin İnterneti cihazlarında kullanılmak üzere tasarlanmıştı.
Ancak Nitter, çerez yerine OAuth kullanan, API aracılığıyla kaydedilen ve görünüşe göre uygulama tarafından kullanılan farklı bir tür "misafir hesabı" kullandı. AndroidBu hesap türünün 15 dakikada 500 API isteği sınırı vardır ve "kaydı" şunlara bağlıdır: IP adresi (Bir IP adresinden günde yalnızca bir "misafir hesabı" kaydedebilirsiniz, ancak önceden kaydedilmiş bir "hesap" diğer IP adreslerinden kullanılabilir.)
Bu tür “hesaplar” (erişim belirteçleri) 30 gün boyunca faaliyette kaldı. O zamanlar, geçici hesapların toplu kaydı sorununa yeterli bir çözüm, Bibliogram'a (konuk jetonunu kullanıcıdan alan ve halka açık bir örneğe aktaran bir kullanıcı komut dosyası) benzer bir şey kullanarak, kullanıcılar tarafından kayıtlarının kitle kaynak yoluyla sağlanması olurdu. .
Ocak ayının sonunda X, bu tür tokenları çıkarmayı bıraktı. İkinci erişim yönteminin kaldırılması, Nitter'in halka açık, ücretsiz, çok kullanıcılı bir hizmet olmasına son verdi ve yazarın Nitter'in öldüğünü ilan etmesiyle sonuçlandı.
Bazı örnekler bunun ardından hemen kapandı, diğerleri ise mevcut tokenların kullanımını önemli ölçüde azaltmak için kodu değiştirdiler, özellikle de birincil kullanımları hesaplardan tweet listeleri almaktı ve geri kalan her şey için hata mesajları veriliyordu. 26 Şubat'ta son konuk belirteçlerinin süresi doldu ve tüm genel örneklerin işleyişinin durmasına neden oldu. Ancak hata izleyici, konuk hesaplarını bir şekilde etkileyen sorunları tartışıyor.
Soruna yönelik radikal çözümlerden biri, her mesajın ana tanımlayıcısının IPFS CID olduğu ActivityPub ve IPFS'ye dayalı alternatif merkezi olmayan bir hizmet oluşturarak Twitter'ın değiştirilmesi olabilir. Aşağıdaki çok düzeyli yapıyı hayal edebiliriz:
Ancak bu 3 nokta, Twitter kullanıcılarının Twitter değiştirme programına katılmama sorununu çözmüyor.
Her bir merkezi platformdaki her gönderi tanımlayıcısı için, gönderinin metnini bilmeden, ancak merkezi tanımlayıcısını bilmeden merkezi olmayan tanımlayıcısını bulmanızı sağlayan bir önbellek görevi gören IPFS CID'deki eşlemesini korumak tavsiye edilebilir. . IPFS'de bir URI oluştururken (bu aslında doldurmadan yapılabilir), gönderi metni kanonikleştirmeye tabi tutulur; bu, verileri makine tarafından okunabilir meta verilerle HTML tabanlı bir kaba yerleştirmek, Unicode normalleştirme, UTF-8'e dönüştürme, değiştirme işlemlerini içeren bir kurallaştırma işlemine tabi tutulur. boşluk karakterlerinin basit tek boşluklarla değiştirilmesi ve bu platformdaki ve benzer bir prosedürden geçen diğer platformlardaki gönderilere olan tüm bağlantıların IPFS'deki URI'lerle değiştirilmesi.
Her platformda, ağdaki gönderilerdeki bağlantıları IPFS URI'leriyle değiştirilen birçok hizmet de dahil olmak üzere, gönderileri kanonikleştirmeye yönelik kuralları açıklayan, makine tarafından okunabilir bir belge bulunur. Her ağdaki her gönderi, gönderinin kendisinin tarihlendiği tarihte yürürlükte olan, o ağdaki gönderilerin kanonikleştirilmesine ilişkin kurallara uygun olarak kanonikleştirilir. Kanonikleştirme sırasında, bir gönderinin değiştirilen platformlardan birindeki bir gönderiye bağlantı içermesi durumunda uygulama, bağlantıdan merkezi bir tanımlayıcı çıkarır ve bunun güvenilir dizinlerdeki varlığını kontrol eder.
Bir dizinde mevcut olduğunda uygulama, dizinlerdeki merkezi olmayan tanımlayıcıyı kullanır. Eğer yoksa, uygulama gönderimi referans olarak ister, onu standartlaştırır ve indekslere yerleştirilebilecek bir tanımlayıcı üretir. Uygulamanın, talep edilen gönderiyi merkezi olmayan ağa yerleştirme zorunluluğu yoktur. Bir uygulama, süreci yerel olarak tekrar oynatarak indeksteki tanımlayıcının geçerliliğini doğrulayabilir. Süreci yerel olarak yeniden üreterek tanımlayıcıların doğru oluşturulduğunu doğrulamak dizin uygulamasının sorumluluğundadır.
Bu deterministik süreç, posterleri henüz Twitter değiştirme programına katılmayan tweetler için bile değişmez içerik bağlantılarının oluşturulmasına olanak tanıyacaktır. Bunlardan bazıları tweet'lerini IPFS'ye yüklediğinde, dizinin doğru eşlemeleri içermesi ve içeriğin kendisinin değişmemesi koşuluyla, algoritma onlar için zaten onlara olan bağlantılarda kullanılanlarla aynı tanımlayıcılar üretecektir.
Kaynak: opennet.ru
