Sosyal Medyanın Yeni Yılı: Nostr İlkeleri ve Temel Yönetim Sorunları
Beşinci Sağ kapsamındaki yeni sosyal medya tasarımları yıllardır araştırılıyor ve kitlesel olarak benimsendiğine dair hiçbir işaret yok. Geçtiğimiz yıl, şifreleme teknolojisinin sürekli gelişmesi ve Musk'un Twitter'ı satın almasıyla ilgili endişeler nedeniyle, merkezi olmayan sosyal ağ yeni fırsatların önünü açtı.
Bu sosyal ağların çözmeye çalıştığı sorunlar arasında sansürün güçlendirilmesi, içerik denetiminin daha esnek hale getirilmesi ve büyük sosyal medya şirketlerinin insanların çevrimiçi ortamda ne hakkında konuştuklarını şekillendirme ve takip etme gücünün azaltılması sayılabilir.
Yeni platformlar ortaya çıkıp büyüdükçe, alternatif sosyal ağların seçimi genellikle politik değerlendirmeleri de beraberinde getiriyor. Getr, Parler, Gab ve Truth Social gibi sitelerin tümü kendilerini Twitter'a ifade özgürlüğü alternatifi olarak tanıtarak sağa hitap ediyor.
Bugün tartışacağımız şey Nostr-damus, son zamanlarda büyük ilgi gören ve biraz yenilikçi olan yeni bir sosyal medya protokolü. Bunlar arasında Nostr'ın teknik ilkeleri, çözülmesi gereken temel yönetim sorunları ve aktarmanın çalışmaya devam etmesi için nasıl teşvik edileceği yer alıyor.
Nostr'a Genel Bakış
2020 başlatılan, nostr kullanıcıların kendi kimliklerine sahip olmalarına ve kamu-özel anahtar şifrelemesini kullanarak dijital imzalar kullanarak gönderileri doğrulamalarına olanak tanıyan merkezi olmayan bir protokoldür. Bu gönderiler daha sonra birbirine bağlı bir sunucu ağına yayılır. Protokol, ilk deneylerde sosyal ağlar için çok yavaş olduğu tespit edilen bir blockchain kullanmıyor. Ancak yapısal benzerlikler var ve Nostr, özgürlükçü ve açık kaynak ahlakıyla kripto kalabalığında erken bir yer buldu.
Mastodon Nostr'a Karşı
Nostr protokolü ve ilk geçiş sunucusu, geliştirici fiatjaf tarafından 2020'nin sonlarında oluşturuldu. Yaygın ilgi görmeden önce Nostr, Twitter ve Mastodon'un sorunlarına hafif bir çözüm olmayı amaçlayan sessiz bir niş protokoldü.
2016 yılında kurulan açık kaynaklı bir ağ olan Mastodon, herkesin sunucu kurmasına olanak tanıyor. Tasarım genellikle "birleşik" olarak tanımlanır ve nasıl tanımlandığına bağlı olarak "Web3"ün bulanık çizgisine girebilir veya girmeyebilir. Mastodon, kullanıcıların özel içerik denetleme kurallarıyla seçilmiş topluluklara katılmasına olanak tanır. Şu anda kayıtlı kullanıcı sayısı 200+'a ulaştı ve liberaller, gazeteciler ve akademisyenler için güvenli bir sığınak haline geldi.
In Twitter ve Mastodon sistemler, kimlikler/kullanıcı adları sunucuyu çalıştıran kişi tarafından kontrol edilir.
Nostr'daki temel fark, her kullanıcının, sunucu operatörünün sahip olduğu bir kullanıcı adını kullanmak yerine işlevi gerçekleştirmek için genel/özel bir anahtar çifti kullanmasıdır, bu da Nostr'ı sansüre karşı dayanıklı hale getirir. Bu, tüm Nostr protokolünü oluşturmak için temel yapı taşlarından biridir.
Etkinlikler: İstemcilerin ve bağlandıkları aktarma sunucularının mesaj gönderip almak için kullandıkları temel nesne/veri türüdür. Protokolün genel fikri, istemcilerin olayları bir aktarma sunucusuna göndermesi, daha sonra bu sunucunun bunları saklayıp dizine eklemesi ve diğer istemcilerin, aldıkları ve sakladıkları olayları talep etmek için aktarma sunucusuyla iletişim kurabilmeleridir. Orjinalinde NIP01, üç farklı etkinlik türü tanımlandı:
- Kullanıcı hakkında kullanıcı adı, resim, biyografi vb. gibi meta veriler gönderin.
- SMS ve temel içerik gönderin
- Etkinlik oluşturucuyu takip eden kişilerin bağlanmaları için geçiş sunucusunu önerin
Tüm etkinlikler özel olarak tanımlanmış bir şekilde yapılandırılmıştır. İçerik oluşturucunun genel anahtarını, oluşturma zaman damgasını, türünü (veya spesifikasyon türünü), içerik yükünü ve etkinlik oluşturucunun imzasını içerir. Alternatif olarak, diğer olaylara veya kullanıcılara atıfta bulunan ve yaratıcının imzası dışında her şeyin karma değeri olan bir kimlik değerine sahip olan etiketler olabilir (Bitcoin işleminin TXID'sine benzer).
Bu, mesajın gerçekten de içindeki genel anahtarın sahibi tarafından oluşturulduğunu ve mesajın imzalandıktan sonra değiştirilmediğini garanti etmek için kullanıcıların imzayı (ve eğer gizliliği ihlal edilmemişse anahtarın sahibini) doğrulamasını sağlar. BT.
Nasıl ki bir Bitcoin işlemi imzalandıktan sonra geçersiz kılınmadan değiştirilemiyorsa, kullanıcı da işlemi oluşturucudan sonra değiştiremez. nostr olay bunu bariz bir sahtekarlık haline getirmeden imzaladı.
Etkinlik türü sistemi orijinaline göre önemli ölçüde genişletildi NIP. Doğrudan şifrelenmiş mesajlar için, gönderenin özel anahtarını alıcının genel anahtarıyla birleştirerek paylaşılan bir sır oluşturan bir olay türü vardır; bunun sonucu, gönderenin genel anahtarını alıcının özel anahtarıyla birleştirerek elde ettiğiniz sonuçla aynıdır. aynıdır (BIP 47 ve sessiz ödemeler bu şekilde çalışır).
Ayrıca değiştirilebilir olay ve geçici olay türleri de vardır. Değiştirilebilir etkinlikler söz konusu olduğunda (tabii ki), etkinliğin asıl yaratıcısının eskisinin yerine geçecek yeni bir etkinliğe imza atabilmesi için tasarlanmışlardır. Bu spesifikasyonu takip eden aktarma sunucuları, eski olayları depolarından otomatik olarak silecek ve alındıktan sonra istemcilere daha yeni sürümler sunmaya başlayacaktır.
Geçici etkinlikler, bir aktarmaya gönderildiğinde, yaratıcısına abone olan herkese yayınlanacak, ancak aktarma sunucusunun bunları saklamaması sağlanacak şekilde tasarlanmıştır. Bu, yayın sırasında mesajı yalnızca çevrimiçi olanların görme olasılığını yaratır. Hatta diğer insanların etkinliklerine verilen tepkileri (beğeniler veya emojiler gibi) temsil eden bir etkinlik türü bile vardır.
Son sorudan bahsetmişken, etkinlikler de etiketler içerebilir. Şu anda, aşağıdakiler için etiket türleri bulunmaktadır: Etkinlikler (tam bir Nostr olayına atıfta bulunarak), Genel anahtar (başka bir kullanıcıyı etiketlemek veya ona atıfta bulunmak için) ve Konu (bir e-posta konusu gibi işlevselliği taklit etmek için).
Bunların tümü, kullanıcıların farklı sunucular üzerinde etkileşimde bulunabilmesi için verilerin alındığı belirli aktarma sunucularına işaret eden işaretçiler içerebilir, yani bir kullanıcı, içeriğini farklı bir sunucudaki başka bir kullanıcı tarafından etkileşime girilebilecek ve referans alınabilecek bir aktarma sunucusu içeriğinde yayınlayabilir. Böylece herhangi bir kullanıcı, ilgili verilerin çok sayıda karmaşık işlemden oluştuğunu bulmak zorunda kalmadan, etkileşimin tüm akışını uygun sırayla tutarlı bir şekilde alabilir.
Orjinalinde NIP, bir istemcinin, almak istediği olaylar için filtreler içeren bir mesaj/veri yapısına abone olarak bir aktarma sunucusuyla nasıl etkileşime girdiğine dair bir spesifikasyon verilmiştir. Bu filtreler kullanıcının genel anahtarını, tam olayı, olayın türünü ve hatta önceki kriterlere göre olmasını istedikleri belirli bir zaman dilimini belirleyebilir.
Kullanıcılar, "1xjisj..." gibi genel anahtarları veya olay kimliklerinin öneklerini bile gönderebilir ve bu kısa dizeyle başlayan bir genel anahtardan herhangi bir veya daha fazla olayı alabilir (bu, gerçekte görmek istediklerinizi aktarma sunucularından gizlemek için kullanışlıdır). .
Genel olarak protokol, mesajların bütünlüğünü garanti etmek ve mesaj göndermek için genel anahtar kimliklerini kullanmak gibi önemli şeyleri kapsayan, aynı zamanda son altyapı aktarma sunucularının oldukça merkezi olabilmesini veya kullanıcıların çalışmasına izin verebilmesini kolaylaştıran, kullanıcılar arasında mesaj aktarımı için çok basit bir genel şemadır. Kullanıcıların tek bir aktarma sunucusunu kullanmalarının yasaklanması durumunda büyük bir kaosa neden olmadan, birbirleriyle sorunsuz bir şekilde etkileşime girerek kendi kişisel aktarma sunucularını sunar.
Başka bir sunucuya geçebilirler veya kendi sunucularını çalıştırabilirler ve platformu önceki sunucularından ayırarak dijital kimliklerini veya takipçilerini kaybetmezler, çünkü özel anahtarlarının kontrolünü hâlâ ellerinde tutarlar ve kullanıcılar kimlik doğrulaması için bunu başka bir yerde kullanabilirler. onları bulduklarında.
Aktarma sunucuları aynı zamanda istedikleri her şeyi çalıştırabilirler: ücretsiz olarak çalışabilirler, mesajları yayınlamak veya indirmek için küçük bir ücret talep edebilirler ve hatta mesajların gönderilmesi için hash nakit tarzı iş kanıtı gerektiren bir NIP'ye sahip olabilirler.
Gönderileri barındıran ve bunları yalnızca diğer kullanıcıların kullanımına sunan tek bir geçiş sunucusu veya Twitter veya Reddit gibi belirli ölçekte çalışan bir sunucu olabilirler (müşteriler bilgileri istedikleri gibi görüntüleyebilir ve düzenleyebilir, bu da herhangi bir sosyal medyanın simüle edilmesine olanak tanır). Bunların tümü, kullanıcıları kilitlemeden sorunsuz bir şekilde birlikte çalışır.
Nostr tarafından ele alınacak temel yönetim sorunları
Kullanıcının genel/özel anahtarları, Nostr'un bir protokol olarak nasıl çalıştığının ayrılmaz bir parçasıdır. Bu, gerçek kullanıcı ile diğerlerinin onu nasıl tanımladığı arasında sıkı bir bağ oluşturarak herhangi bir aktarma sunucusunun bu iki şeyi çözmesini, yani birinin tanımlayıcısını başka bir kullanıcıya vermesini engeller. Aynı zamanda platformdaki en büyük sorunlardan birini de çözüyor: kullanıcının kendi kimliği üzerindeki kontrol eksikliği.
Ancak bu aynı zamanda yeni sorunları da beraberinde getiriyor: Anahtar kaybolabilir, anahtar ele geçirilebilir ve böyle bir olay meydana gelirse kullanıcı yardım çağıramayacaktır.
Bu, kaçınılmaz olarak kullanıcıların bir anahtar çiftinden diğerine doğrulanabilir ve keşfedilebilir bir şekilde geçiş yapmaları ve protokol aracılığıyla diğer kullanıcılarla etkileşime girmeleri için bir şema gerektirecektir. Protokolün tamamı, bir olayın belirli bir kullanıcıdan (kimlik anahtarı) geldiğinin kanıtlanmasına dayanmaktadır; dolayısıyla birinin anahtarı ele geçirildiğinde, tüm bu garantiler havaya uçar.
Nostr, bir anahtarın dönüşünü diğerine bağlayan gerçek bir şifreleme şeması gerektirir. Geliştirici fiatjaf, bu sorunu çözebilecek temel bir çözüm önerdi. Temel fikir, tek bir ana tohumdan türetilen uzun bir adres listesi almak ve Taproot ağaçlarının Bitcoin anahtarlarına bağlı olmasına benzer şekilde bir dizi "ayarlanmış" anahtar oluşturmaktır.
Taproot, Taproot ağacının Merkle kökünü alır ve yeni bir genel anahtar oluşturmak için onu genel anahtara "ekler". Bu, yeni genel anahtarla eşleşen özel bir anahtar elde etmek için özel anahtara Merkle kökünün eklenmesiyle çoğaltılabilir. Fiatjaf'ın fikri, taahhütleri baştan sona zincirlemek, böylece ayarlanan her anahtarın aslında bir sonraki ayarlanan anahtarın onu oluşturmak için kullanıldığına dair kanıt içermesidir.
Yani zincirin sonuncusu olan Z tuşuyla başladığınızı hayal edin. Bir şeyle ince ayar yapabilir, sonra geri dönüp ayarlanmış Z tuşunu (Z' + Y = Y') kullanarak Y anahtarının ayarlanmış bir versiyonunu oluşturabilirsiniz. Buradan Y' alabilir ve X'i (Y' + X = X') ayarlamak için kullanabilirsiniz. Bunu A anahtarına kadar yaparsınız, A'yı alırsınız ve oradan o anahtarı kullanırsınız. Bozulduğunda kullanıcı, ayarlanmamış A anahtarını ve ayarlanmış B' anahtarını içeren bir olayı yayınlayabilir.
Bu, B'nin A'yı oluşturmak için kullanıldığını göstermek için gereken tüm verileri içerecektir ve kullanıcı A'yı takip etmeyi hemen bırakıp bunun yerine B'yi takip edebilir. Açıkça B'nin o kullanıcı için bir sonraki anahtar olduğunu bilirler ve onun yerine o anahtarı takip ederler.
Ancak bu öneride hâlâ bazı sorunlar var. İlk olarak, kullanılacak tüm anahtarların önceden oluşturulması gerekir ve tamamen yeni bir anahtar grubuna geçmenin bir yolu yoktur. Bu sorun, bu şemada, bu rotasyonu noter tasdik edebilecek bir ana anahtar işlenerek veya başlangıçtan itibaren çok büyük bir anahtar seti oluşturularak çözülebilir.
Her iki yol da mümkündür ancak sonuçta kök anahtarı veya anahtarlama materyalini güvende tutmayı ve yalnızca bireysel kısayol tuşlarını (Kısayol Tuşları) Nostr istemcilerine göstermeyi gerektirir.
Ancak bu şema, kök anahtarlama malzemesinin kaybolması veya tehlikeye atılması durumunda kullanıcıları korumaz veya kimlik kurtarma mekanizmaları sağlamaz.
Buradaki potansiyel çözümlere ilişkin bazı tartışmalar için, bunu düşünmenin başka bir yolu da, bir anahtarı, bir anahtardan başka bir rotasyona olayları imzalamak için kullanılması gereken bir ana soğuk anahtara ayarlamaktır. A ve M'nin (ana anahtar) eklenmesiyle elde edilen A' anahtarınız var; rotasyon olayı A, M ve B' (B ve M eklenerek oluşturulur) ve M'nin imzası olacaktır. M, çoklu imza eşik anahtarı olabilir (üçte iki, beşte üç vb.).
Bu, kayba karşı yedeklilik sağlayabilir ve anahtar rotasyonu için güvenli bir mekanizma sağlayabilir. Bu aynı zamanda kurtarmaya yardımcı olacak hizmetleri kullanmanın veya bu anahtarlardan bazılarını güvenilir arkadaşlara yaymanın kapısını da açar. Bitcoin'in kendisindeki çoklu imza ile aynı esnekliği sunar.
PIN26 aynı zamanda bu sorunla baş etmede çok yararlı olabilecek bir öneridir. Bu, bir anahtardan gelen imzanın başka bir anahtara kendi adına olay yayınlama yetkisi vermesine izin veren olaylar için bir protokol uzantısını belirtir. Daha sonra "belirteç" veya yetkilendirilmiş imza kanıtı, birincisi adına ikinci genel anahtar tarafından yayınlanan tüm olaylara dahil edilecektir. Hatta süre sınırlı bile olabilir, dolayısıyla delegasyon jetonlarının süresi otomatik olarak dolar ve yenilenmesi gerekir.
Anahtar yönetimi ve güvenlik sorunu, ödünleşimler ve sıkıntılı noktalarla dolu çok geniş bir tasarım alanına sahip, çok büyük bir sorundur. Ancak Nostr, kullanıcılar için bu kimliklerin bütünlüğünü koruyamazsa ve sürdüremezse, tamamen kimlik olarak kullanılan genel/özel anahtar çiftlerine dayalı bir protokol büyük ölçekte benimsenmeyecektir.
Nostr'a bakan genişleme
Nostr protokolünün tamamı, bir yerde aktarma sunucusu çalıştıran birine dayanır. “Nostr ağı” yoktur, yalnızca röleler ve rölelere bağlı istemciler vardır. İnsanların aktarıcıları çalıştırmaya teşvik edilmesi gerekiyor ve bu, sonuçta aktarıcıların uzun vadede ne kadar ölçeklenebileceğinin büyük bir parçası olacak. Bir Nostr aktarımı karlı olmadığı veya en azından kendi işletme maliyetlerini karşılamaya yetecek kadar para getirmediği sürece Twitter sunucusuyla aynı boyutta bir aktarım asla olmayacaktır.
Reklam
Nostr'un bir protokol olarak çalışma şekli göz önüne alındığında, reklamların tamamen engellenmesi önemsiz bir çözüm olacaktır ve bu da onu gerçekleştirilemez bir çözüm haline getirecektir. Aktarma sunucuları, reklamları bir gelir modeli olarak kullanmayı deneyebilir; bu, görünüşe göre neredeyse tüm çevrimiçi ücretsiz hizmetler için ana gelir modelidir, ancak sorun, kullanıcıların temelde buna dahil olmak zorunda olmasıdır. Aktarmalar, müşterilere gönderdikleri etkinliklere kolayca reklam enjekte edebilir. ancak istemciler, abone olmayı amaçladıkları ortak anahtar tarafından oluşturulmamışsa, reklam olaylarını kullanıcı arayüzlerinden kolayca filtreleyebilirler.
micropayment
Mikroödemeler, özellikle de entegre etme çabaları göz önüne alındığında, başka bir bariz çözümdür. Şimşek ağ Nostr uygulamasına daha sıkı bağlanın. Bu model, şarj etme şekliniz konusunda çok fazla esneklik sunar. Röleler yalnızca orada etkinlik yayınlamak, etkinlik okumasını indirmek veya ikisinin birleşimi için ücret alabilir ve her birinin fiyatı, tükettikleri kaynak miktarına göre ayarlanır. Ancak bu modelin Twitter ölçeğine yükseltilebileceği şüpheli.
İçerik mikro ödemeleri, birçok niş üründe uygulanabilirliğini göstermiştir. Şimşek ağ, ancak gerçekten küresel ölçeğe ölçeklendirmenin iki temel sorunu var.
Öncelikle Bitcoin'in benimsenmesi henüz yeterli değil. Herkes Nostr'daki her küçük hizmet etkileşimi için sihirli bir şekilde ödeme yapmayı kabul etse bile, Twitter gibi devasa bir şeyi desteklemek için bitcoin tutan yeterli sayıda insan olmayacaktı. Röleler abonelik ücretlerini fiat para birimi cinsinden alabilir ancak bu ödeme yöntemleri yayınlanan veya indirilen her etkinlik için küçük bir ücret ödenmesini desteklemez.
İkincisi, insanlar aslında bu tür ücretsiz hizmetlere alışkındır. Bu tam olarak beklenebilecek bir şey. Mikro ödemelerin büyük ölçekli geçişi gerçekten destekleyebileceğini düşünmüyorum.
Geçişi kullanan her sınıftaki kullanıcıyı zorlamadan, mikro ödemeleri "daha yapışkan" veya daha sürdürülebilir hale getirmenin bir yolu var. Twitter klonu dışında Nostr'ın üzerine çeşitli uygulamalar oluşturma konusunda çok fazla konuşma yapıldı. GitHub, Wikipedia ve hatta Uber.
Sonuncusu çok önemli: ekonomik beklentiler. İnsanlar bir yerde bir işin ilanı verildiğinde ücret ödemeye veya çevrimiçi bir şey sipariş ederken bir pazaryeri operatörüne ücret ödemeye çok alışkındır ancak ücretsiz olması gerektiğini düşündükleri şeyleri (Google, Twitter) sunmazlar. Bu, aktarıcıların çok fazla sürtüşme yaratmadan veya ortalama potansiyel kullanıcının beklentilerini kırmadan, kullanıcılarından sağlam bir gelir elde etmelerine olanak sağlayabilir.
Eğer mikro ödemeler de bir faktör olacaksa aktarma operatörlerinin öncelikle kullanıcılardan fon alabilmek için bir Lightning düğümü çalıştırması gerekecek. Bu, geçiş tarafından uygulanan herhangi bir mikro ödeme modeliyle uygun şekilde sinerji oluşturulduğunda geliri potansiyel olarak artırabilir.
Aktarma sunucusu ne kadar fazla gelir elde ederse, bunu kolaylaştırmak için Lightning Network'te o kadar fazla likiditeye ihtiyaç duyar. Operatörler ağdaki likiditeyi nasıl dağıtacaklarını veya dağıtacaklarını doğru bir şekilde planlarlarsa, yalnızca bir yönlendirme düğümünü çalıştırma eylemi, aktarmalar yoluyla veri almak veya iletmek için alınan ücretlere ek olarak başlı başına önemli bir gelir oluşturucu haline gelebilir.
Sonuç
Yukarıda belirtilenlere ek olarak Web3 sosyal projeleri nostr ve Mastodongibi projeler de yer alıyor. haberci ve Lensmevcut sosyal medya platformlarının yerini hemen almayacak. İstatistiklere göre Twitter'ın yüz milyonlarca aktif kullanıcısı var. Facebook milyarlar var ama Mastodon sadece 2.5 milyon kullanıcı, ve nostr sadece hakkında var 220,000 benzersiz kullanıcı kimliği. Birçok Web3 sosyal projesi, kitlesel benimsenmeyi yavaşlatan kullanılabilirlik engelleriyle karşı karşıyadır.
Medya ve siyaset birbirinden ayrılamaz. Web3 sosyal projeleri çoğaldıkça ve kamuya açık konuşmalar farklı uygulamalar ve protokoller arasında bölündükçe, siyasi sonuçlar ortaya çıkabilir. Eşit MessinaUzun süredir merkezi olmayan sosyal medyayı savunan Trump, merkezi olmayan yönetimin, son yıllarda karşılıklı düşmanlık ve yanlış anlamalarla damgalanan kamusal söylemi daha da körükleyeceğinden korkuyor.
YASAL UYARI: Bu web sitesindeki bilgiler genel piyasa yorumu olarak verilmektedir ve yatırım tavsiyesi niteliği taşımamaktadır. Yatırım yapmadan önce kendi araştırmanızı yapmanızı öneririz.
Haberleri takip etmek için bize katılın: https://linktr.ee/coincu
Harold
Coincu Haberler
Yazar
bilgi
Sosyal Medyanın Yeni Yılı: Nostr İlkeleri ve Temel Yönetim Sorunları
Beşinci Sağ kapsamındaki yeni sosyal medya tasarımları yıllardır araştırılıyor ve kitlesel olarak benimsendiğine dair hiçbir işaret yok. Geçtiğimiz yıl, şifreleme teknolojisinin sürekli gelişmesi ve Musk'un Twitter'ı satın almasıyla ilgili endişeler nedeniyle, merkezi olmayan sosyal ağ yeni fırsatların önünü açtı.
Bu sosyal ağların çözmeye çalıştığı sorunlar arasında sansürün güçlendirilmesi, içerik denetiminin daha esnek hale getirilmesi ve büyük sosyal medya şirketlerinin insanların çevrimiçi ortamda ne hakkında konuştuklarını şekillendirme ve takip etme gücünün azaltılması sayılabilir.
Yeni platformlar ortaya çıkıp büyüdükçe, alternatif sosyal ağların seçimi genellikle politik değerlendirmeleri de beraberinde getiriyor. Getr, Parler, Gab ve Truth Social gibi sitelerin tümü kendilerini Twitter'a ifade özgürlüğü alternatifi olarak tanıtarak sağa hitap ediyor.
Bugün tartışacağımız şey Nostr-damus, son zamanlarda büyük ilgi gören ve biraz yenilikçi olan yeni bir sosyal medya protokolü. Bunlar arasında Nostr'ın teknik ilkeleri, çözülmesi gereken temel yönetim sorunları ve aktarmanın çalışmaya devam etmesi için nasıl teşvik edileceği yer alıyor.
Nostr'a Genel Bakış
2020 başlatılan, nostr kullanıcıların kendi kimliklerine sahip olmalarına ve kamu-özel anahtar şifrelemesini kullanarak dijital imzalar kullanarak gönderileri doğrulamalarına olanak tanıyan merkezi olmayan bir protokoldür. Bu gönderiler daha sonra birbirine bağlı bir sunucu ağına yayılır. Protokol, ilk deneylerde sosyal ağlar için çok yavaş olduğu tespit edilen bir blockchain kullanmıyor. Ancak yapısal benzerlikler var ve Nostr, özgürlükçü ve açık kaynak ahlakıyla kripto kalabalığında erken bir yer buldu.
Mastodon Nostr'a Karşı
Nostr protokolü ve ilk geçiş sunucusu, geliştirici fiatjaf tarafından 2020'nin sonlarında oluşturuldu. Yaygın ilgi görmeden önce Nostr, Twitter ve Mastodon'un sorunlarına hafif bir çözüm olmayı amaçlayan sessiz bir niş protokoldü.
2016 yılında kurulan açık kaynaklı bir ağ olan Mastodon, herkesin sunucu kurmasına olanak tanıyor. Tasarım genellikle "birleşik" olarak tanımlanır ve nasıl tanımlandığına bağlı olarak "Web3"ün bulanık çizgisine girebilir veya girmeyebilir. Mastodon, kullanıcıların özel içerik denetleme kurallarıyla seçilmiş topluluklara katılmasına olanak tanır. Şu anda kayıtlı kullanıcı sayısı 200+'a ulaştı ve liberaller, gazeteciler ve akademisyenler için güvenli bir sığınak haline geldi.
In Twitter ve Mastodon sistemler, kimlikler/kullanıcı adları sunucuyu çalıştıran kişi tarafından kontrol edilir.
Nostr'daki temel fark, her kullanıcının, sunucu operatörünün sahip olduğu bir kullanıcı adını kullanmak yerine işlevi gerçekleştirmek için genel/özel bir anahtar çifti kullanmasıdır, bu da Nostr'ı sansüre karşı dayanıklı hale getirir. Bu, tüm Nostr protokolünü oluşturmak için temel yapı taşlarından biridir.
Etkinlikler: İstemcilerin ve bağlandıkları aktarma sunucularının mesaj gönderip almak için kullandıkları temel nesne/veri türüdür. Protokolün genel fikri, istemcilerin olayları bir aktarma sunucusuna göndermesi, daha sonra bu sunucunun bunları saklayıp dizine eklemesi ve diğer istemcilerin, aldıkları ve sakladıkları olayları talep etmek için aktarma sunucusuyla iletişim kurabilmeleridir. Orjinalinde NIP01, üç farklı etkinlik türü tanımlandı:
- Kullanıcı hakkında kullanıcı adı, resim, biyografi vb. gibi meta veriler gönderin.
- SMS ve temel içerik gönderin
- Etkinlik oluşturucuyu takip eden kişilerin bağlanmaları için geçiş sunucusunu önerin
Tüm etkinlikler özel olarak tanımlanmış bir şekilde yapılandırılmıştır. İçerik oluşturucunun genel anahtarını, oluşturma zaman damgasını, türünü (veya spesifikasyon türünü), içerik yükünü ve etkinlik oluşturucunun imzasını içerir. Alternatif olarak, diğer olaylara veya kullanıcılara atıfta bulunan ve yaratıcının imzası dışında her şeyin karma değeri olan bir kimlik değerine sahip olan etiketler olabilir (Bitcoin işleminin TXID'sine benzer).
Bu, mesajın gerçekten de içindeki genel anahtarın sahibi tarafından oluşturulduğunu ve mesajın imzalandıktan sonra değiştirilmediğini garanti etmek için kullanıcıların imzayı (ve eğer gizliliği ihlal edilmemişse anahtarın sahibini) doğrulamasını sağlar. BT.
Nasıl ki bir Bitcoin işlemi imzalandıktan sonra geçersiz kılınmadan değiştirilemiyorsa, kullanıcı da işlemi oluşturucudan sonra değiştiremez. nostr olay bunu bariz bir sahtekarlık haline getirmeden imzaladı.
Etkinlik türü sistemi orijinaline göre önemli ölçüde genişletildi NIP. Doğrudan şifrelenmiş mesajlar için, gönderenin özel anahtarını alıcının genel anahtarıyla birleştirerek paylaşılan bir sır oluşturan bir olay türü vardır; bunun sonucu, gönderenin genel anahtarını alıcının özel anahtarıyla birleştirerek elde ettiğiniz sonuçla aynıdır. aynıdır (BIP 47 ve sessiz ödemeler bu şekilde çalışır).
Ayrıca değiştirilebilir olay ve geçici olay türleri de vardır. Değiştirilebilir etkinlikler söz konusu olduğunda (tabii ki), etkinliğin asıl yaratıcısının eskisinin yerine geçecek yeni bir etkinliğe imza atabilmesi için tasarlanmışlardır. Bu spesifikasyonu takip eden aktarma sunucuları, eski olayları depolarından otomatik olarak silecek ve alındıktan sonra istemcilere daha yeni sürümler sunmaya başlayacaktır.
Geçici etkinlikler, bir aktarmaya gönderildiğinde, yaratıcısına abone olan herkese yayınlanacak, ancak aktarma sunucusunun bunları saklamaması sağlanacak şekilde tasarlanmıştır. Bu, yayın sırasında mesajı yalnızca çevrimiçi olanların görme olasılığını yaratır. Hatta diğer insanların etkinliklerine verilen tepkileri (beğeniler veya emojiler gibi) temsil eden bir etkinlik türü bile vardır.
Son sorudan bahsetmişken, etkinlikler de etiketler içerebilir. Şu anda, aşağıdakiler için etiket türleri bulunmaktadır: Etkinlikler (tam bir Nostr olayına atıfta bulunarak), Genel anahtar (başka bir kullanıcıyı etiketlemek veya ona atıfta bulunmak için) ve Konu (bir e-posta konusu gibi işlevselliği taklit etmek için).
Bunların tümü, kullanıcıların farklı sunucular üzerinde etkileşimde bulunabilmesi için verilerin alındığı belirli aktarma sunucularına işaret eden işaretçiler içerebilir, yani bir kullanıcı, içeriğini farklı bir sunucudaki başka bir kullanıcı tarafından etkileşime girilebilecek ve referans alınabilecek bir aktarma sunucusu içeriğinde yayınlayabilir. Böylece herhangi bir kullanıcı, ilgili verilerin çok sayıda karmaşık işlemden oluştuğunu bulmak zorunda kalmadan, etkileşimin tüm akışını uygun sırayla tutarlı bir şekilde alabilir.
Orjinalinde NIP, bir istemcinin, almak istediği olaylar için filtreler içeren bir mesaj/veri yapısına abone olarak bir aktarma sunucusuyla nasıl etkileşime girdiğine dair bir spesifikasyon verilmiştir. Bu filtreler kullanıcının genel anahtarını, tam olayı, olayın türünü ve hatta önceki kriterlere göre olmasını istedikleri belirli bir zaman dilimini belirleyebilir.
Kullanıcılar, "1xjisj..." gibi genel anahtarları veya olay kimliklerinin öneklerini bile gönderebilir ve bu kısa dizeyle başlayan bir genel anahtardan herhangi bir veya daha fazla olayı alabilir (bu, gerçekte görmek istediklerinizi aktarma sunucularından gizlemek için kullanışlıdır). .
Genel olarak protokol, mesajların bütünlüğünü garanti etmek ve mesaj göndermek için genel anahtar kimliklerini kullanmak gibi önemli şeyleri kapsayan, aynı zamanda son altyapı aktarma sunucularının oldukça merkezi olabilmesini veya kullanıcıların çalışmasına izin verebilmesini kolaylaştıran, kullanıcılar arasında mesaj aktarımı için çok basit bir genel şemadır. Kullanıcıların tek bir aktarma sunucusunu kullanmalarının yasaklanması durumunda büyük bir kaosa neden olmadan, birbirleriyle sorunsuz bir şekilde etkileşime girerek kendi kişisel aktarma sunucularını sunar.
Başka bir sunucuya geçebilirler veya kendi sunucularını çalıştırabilirler ve platformu önceki sunucularından ayırarak dijital kimliklerini veya takipçilerini kaybetmezler, çünkü özel anahtarlarının kontrolünü hâlâ ellerinde tutarlar ve kullanıcılar kimlik doğrulaması için bunu başka bir yerde kullanabilirler. onları bulduklarında.
Aktarma sunucuları aynı zamanda istedikleri her şeyi çalıştırabilirler: ücretsiz olarak çalışabilirler, mesajları yayınlamak veya indirmek için küçük bir ücret talep edebilirler ve hatta mesajların gönderilmesi için hash nakit tarzı iş kanıtı gerektiren bir NIP'ye sahip olabilirler.
Gönderileri barındıran ve bunları yalnızca diğer kullanıcıların kullanımına sunan tek bir geçiş sunucusu veya Twitter veya Reddit gibi belirli ölçekte çalışan bir sunucu olabilirler (müşteriler bilgileri istedikleri gibi görüntüleyebilir ve düzenleyebilir, bu da herhangi bir sosyal medyanın simüle edilmesine olanak tanır). Bunların tümü, kullanıcıları kilitlemeden sorunsuz bir şekilde birlikte çalışır.
Nostr tarafından ele alınacak temel yönetim sorunları
Kullanıcının genel/özel anahtarları, Nostr'un bir protokol olarak nasıl çalıştığının ayrılmaz bir parçasıdır. Bu, gerçek kullanıcı ile diğerlerinin onu nasıl tanımladığı arasında sıkı bir bağ oluşturarak herhangi bir aktarma sunucusunun bu iki şeyi çözmesini, yani birinin tanımlayıcısını başka bir kullanıcıya vermesini engeller. Aynı zamanda platformdaki en büyük sorunlardan birini de çözüyor: kullanıcının kendi kimliği üzerindeki kontrol eksikliği.
Ancak bu aynı zamanda yeni sorunları da beraberinde getiriyor: Anahtar kaybolabilir, anahtar ele geçirilebilir ve böyle bir olay meydana gelirse kullanıcı yardım çağıramayacaktır.
Bu, kaçınılmaz olarak kullanıcıların bir anahtar çiftinden diğerine doğrulanabilir ve keşfedilebilir bir şekilde geçiş yapmaları ve protokol aracılığıyla diğer kullanıcılarla etkileşime girmeleri için bir şema gerektirecektir. Protokolün tamamı, bir olayın belirli bir kullanıcıdan (kimlik anahtarı) geldiğinin kanıtlanmasına dayanmaktadır; dolayısıyla birinin anahtarı ele geçirildiğinde, tüm bu garantiler havaya uçar.
Nostr, bir anahtarın dönüşünü diğerine bağlayan gerçek bir şifreleme şeması gerektirir. Geliştirici fiatjaf, bu sorunu çözebilecek temel bir çözüm önerdi. Temel fikir, tek bir ana tohumdan türetilen uzun bir adres listesi almak ve Taproot ağaçlarının Bitcoin anahtarlarına bağlı olmasına benzer şekilde bir dizi "ayarlanmış" anahtar oluşturmaktır.
Taproot, Taproot ağacının Merkle kökünü alır ve yeni bir genel anahtar oluşturmak için onu genel anahtara "ekler". Bu, yeni genel anahtarla eşleşen özel bir anahtar elde etmek için özel anahtara Merkle kökünün eklenmesiyle çoğaltılabilir. Fiatjaf'ın fikri, taahhütleri baştan sona zincirlemek, böylece ayarlanan her anahtarın aslında bir sonraki ayarlanan anahtarın onu oluşturmak için kullanıldığına dair kanıt içermesidir.
Yani zincirin sonuncusu olan Z tuşuyla başladığınızı hayal edin. Bir şeyle ince ayar yapabilir, sonra geri dönüp ayarlanmış Z tuşunu (Z' + Y = Y') kullanarak Y anahtarının ayarlanmış bir versiyonunu oluşturabilirsiniz. Buradan Y' alabilir ve X'i (Y' + X = X') ayarlamak için kullanabilirsiniz. Bunu A anahtarına kadar yaparsınız, A'yı alırsınız ve oradan o anahtarı kullanırsınız. Bozulduğunda kullanıcı, ayarlanmamış A anahtarını ve ayarlanmış B' anahtarını içeren bir olayı yayınlayabilir.
Bu, B'nin A'yı oluşturmak için kullanıldığını göstermek için gereken tüm verileri içerecektir ve kullanıcı A'yı takip etmeyi hemen bırakıp bunun yerine B'yi takip edebilir. Açıkça B'nin o kullanıcı için bir sonraki anahtar olduğunu bilirler ve onun yerine o anahtarı takip ederler.
Ancak bu öneride hâlâ bazı sorunlar var. İlk olarak, kullanılacak tüm anahtarların önceden oluşturulması gerekir ve tamamen yeni bir anahtar grubuna geçmenin bir yolu yoktur. Bu sorun, bu şemada, bu rotasyonu noter tasdik edebilecek bir ana anahtar işlenerek veya başlangıçtan itibaren çok büyük bir anahtar seti oluşturularak çözülebilir.
Her iki yol da mümkündür ancak sonuçta kök anahtarı veya anahtarlama materyalini güvende tutmayı ve yalnızca bireysel kısayol tuşlarını (Kısayol Tuşları) Nostr istemcilerine göstermeyi gerektirir.
Ancak bu şema, kök anahtarlama malzemesinin kaybolması veya tehlikeye atılması durumunda kullanıcıları korumaz veya kimlik kurtarma mekanizmaları sağlamaz.
Buradaki potansiyel çözümlere ilişkin bazı tartışmalar için, bunu düşünmenin başka bir yolu da, bir anahtarı, bir anahtardan başka bir rotasyona olayları imzalamak için kullanılması gereken bir ana soğuk anahtara ayarlamaktır. A ve M'nin (ana anahtar) eklenmesiyle elde edilen A' anahtarınız var; rotasyon olayı A, M ve B' (B ve M eklenerek oluşturulur) ve M'nin imzası olacaktır. M, çoklu imza eşik anahtarı olabilir (üçte iki, beşte üç vb.).
Bu, kayba karşı yedeklilik sağlayabilir ve anahtar rotasyonu için güvenli bir mekanizma sağlayabilir. Bu aynı zamanda kurtarmaya yardımcı olacak hizmetleri kullanmanın veya bu anahtarlardan bazılarını güvenilir arkadaşlara yaymanın kapısını da açar. Bitcoin'in kendisindeki çoklu imza ile aynı esnekliği sunar.
PIN26 aynı zamanda bu sorunla baş etmede çok yararlı olabilecek bir öneridir. Bu, bir anahtardan gelen imzanın başka bir anahtara kendi adına olay yayınlama yetkisi vermesine izin veren olaylar için bir protokol uzantısını belirtir. Daha sonra "belirteç" veya yetkilendirilmiş imza kanıtı, birincisi adına ikinci genel anahtar tarafından yayınlanan tüm olaylara dahil edilecektir. Hatta süre sınırlı bile olabilir, dolayısıyla delegasyon jetonlarının süresi otomatik olarak dolar ve yenilenmesi gerekir.
Anahtar yönetimi ve güvenlik sorunu, ödünleşimler ve sıkıntılı noktalarla dolu çok geniş bir tasarım alanına sahip, çok büyük bir sorundur. Ancak Nostr, kullanıcılar için bu kimliklerin bütünlüğünü koruyamazsa ve sürdüremezse, tamamen kimlik olarak kullanılan genel/özel anahtar çiftlerine dayalı bir protokol büyük ölçekte benimsenmeyecektir.
Nostr'a bakan genişleme
Nostr protokolünün tamamı, bir yerde aktarma sunucusu çalıştıran birine dayanır. “Nostr ağı” yoktur, yalnızca röleler ve rölelere bağlı istemciler vardır. İnsanların aktarıcıları çalıştırmaya teşvik edilmesi gerekiyor ve bu, sonuçta aktarıcıların uzun vadede ne kadar ölçeklenebileceğinin büyük bir parçası olacak. Bir Nostr aktarımı karlı olmadığı veya en azından kendi işletme maliyetlerini karşılamaya yetecek kadar para getirmediği sürece Twitter sunucusuyla aynı boyutta bir aktarım asla olmayacaktır.
Reklam
Nostr'un bir protokol olarak çalışma şekli göz önüne alındığında, reklamların tamamen engellenmesi önemsiz bir çözüm olacaktır ve bu da onu gerçekleştirilemez bir çözüm haline getirecektir. Aktarma sunucuları, reklamları bir gelir modeli olarak kullanmayı deneyebilir; bu, görünüşe göre neredeyse tüm çevrimiçi ücretsiz hizmetler için ana gelir modelidir, ancak sorun, kullanıcıların temelde buna dahil olmak zorunda olmasıdır. Aktarmalar, müşterilere gönderdikleri etkinliklere kolayca reklam enjekte edebilir. ancak istemciler, abone olmayı amaçladıkları ortak anahtar tarafından oluşturulmamışsa, reklam olaylarını kullanıcı arayüzlerinden kolayca filtreleyebilirler.
micropayment
Mikroödemeler, özellikle de entegre etme çabaları göz önüne alındığında, başka bir bariz çözümdür. Şimşek ağ Nostr uygulamasına daha sıkı bağlanın. Bu model, şarj etme şekliniz konusunda çok fazla esneklik sunar. Röleler yalnızca orada etkinlik yayınlamak, etkinlik okumasını indirmek veya ikisinin birleşimi için ücret alabilir ve her birinin fiyatı, tükettikleri kaynak miktarına göre ayarlanır. Ancak bu modelin Twitter ölçeğine yükseltilebileceği şüpheli.
İçerik mikro ödemeleri, birçok niş üründe uygulanabilirliğini göstermiştir. Şimşek ağ, ancak gerçekten küresel ölçeğe ölçeklendirmenin iki temel sorunu var.
Öncelikle Bitcoin'in benimsenmesi henüz yeterli değil. Herkes Nostr'daki her küçük hizmet etkileşimi için sihirli bir şekilde ödeme yapmayı kabul etse bile, Twitter gibi devasa bir şeyi desteklemek için bitcoin tutan yeterli sayıda insan olmayacaktı. Röleler abonelik ücretlerini fiat para birimi cinsinden alabilir ancak bu ödeme yöntemleri yayınlanan veya indirilen her etkinlik için küçük bir ücret ödenmesini desteklemez.
İkincisi, insanlar aslında bu tür ücretsiz hizmetlere alışkındır. Bu tam olarak beklenebilecek bir şey. Mikro ödemelerin büyük ölçekli geçişi gerçekten destekleyebileceğini düşünmüyorum.
Geçişi kullanan her sınıftaki kullanıcıyı zorlamadan, mikro ödemeleri "daha yapışkan" veya daha sürdürülebilir hale getirmenin bir yolu var. Twitter klonu dışında Nostr'ın üzerine çeşitli uygulamalar oluşturma konusunda çok fazla konuşma yapıldı. GitHub, Wikipedia ve hatta Uber.
Sonuncusu çok önemli: ekonomik beklentiler. İnsanlar bir yerde bir işin ilanı verildiğinde ücret ödemeye veya çevrimiçi bir şey sipariş ederken bir pazaryeri operatörüne ücret ödemeye çok alışkındır ancak ücretsiz olması gerektiğini düşündükleri şeyleri (Google, Twitter) sunmazlar. Bu, aktarıcıların çok fazla sürtüşme yaratmadan veya ortalama potansiyel kullanıcının beklentilerini kırmadan, kullanıcılarından sağlam bir gelir elde etmelerine olanak sağlayabilir.
Eğer mikro ödemeler de bir faktör olacaksa aktarma operatörlerinin öncelikle kullanıcılardan fon alabilmek için bir Lightning düğümü çalıştırması gerekecek. Bu, geçiş tarafından uygulanan herhangi bir mikro ödeme modeliyle uygun şekilde sinerji oluşturulduğunda geliri potansiyel olarak artırabilir.
Aktarma sunucusu ne kadar fazla gelir elde ederse, bunu kolaylaştırmak için Lightning Network'te o kadar fazla likiditeye ihtiyaç duyar. Operatörler ağdaki likiditeyi nasıl dağıtacaklarını veya dağıtacaklarını doğru bir şekilde planlarlarsa, yalnızca bir yönlendirme düğümünü çalıştırma eylemi, aktarmalar yoluyla veri almak veya iletmek için alınan ücretlere ek olarak başlı başına önemli bir gelir oluşturucu haline gelebilir.
Sonuç
Yukarıda belirtilenlere ek olarak Web3 sosyal projeleri nostr ve Mastodongibi projeler de yer alıyor. haberci ve Lensmevcut sosyal medya platformlarının yerini hemen almayacak. İstatistiklere göre Twitter'ın yüz milyonlarca aktif kullanıcısı var. Facebook milyarlar var ama Mastodon sadece 2.5 milyon kullanıcı, ve nostr sadece hakkında var 220,000 benzersiz kullanıcı kimliği. Birçok Web3 sosyal projesi, kitlesel benimsenmeyi yavaşlatan kullanılabilirlik engelleriyle karşı karşıyadır.
Medya ve siyaset birbirinden ayrılamaz. Web3 sosyal projeleri çoğaldıkça ve kamuya açık konuşmalar farklı uygulamalar ve protokoller arasında bölündükçe, siyasi sonuçlar ortaya çıkabilir. Eşit MessinaUzun süredir merkezi olmayan sosyal medyayı savunan Trump, merkezi olmayan yönetimin, son yıllarda karşılıklı düşmanlık ve yanlış anlamalarla damgalanan kamusal söylemi daha da körükleyeceğinden korkuyor.
YASAL UYARI: Bu web sitesindeki bilgiler genel piyasa yorumu olarak verilmektedir ve yatırım tavsiyesi niteliği taşımamaktadır. Yatırım yapmadan önce kendi araştırmanızı yapmanızı öneririz.
Haberleri takip etmek için bize katılın: https://linktr.ee/coincu
Harold
Coincu Haberler
Diğer Yazılar
İlgili Mesajlar
Haberler
Pantera Capital TON Yatırım, VC Şirketinin Web3 Alanındaki En Büyük Fonudur
Haberler
BlockFi'nin Kapatılması Mayıs Ayında Gerçekleşecek, Kullanıcıların 28 Nisan'dan Önce Varlıklarını Çekmeleri Gerekiyor
Haberler
Sui'nin zkLogin Özelliği Artık Apple Hesapları İçin Çoklu İmza Kurtarma ve Destek Ekliyor
Haberler
BORÇ Kutusu Davası Artık SEC Örtbaslarıyla Daha Karmaşık Hale Geliyor
Haberler
Pantera Capital TON Yatırımı, P2P Ödeme Yeteneklerini Geliştirmeye Yönelik
Haberler
Adres Hatası 68 Milyon Dolarlık WBTC Kaybına Neden Oldu, Kurban Kimlik Avı Dolandırıcılığına Düştü
Haberler
Pantera Capital TON Yatırım, VC Şirketinin Web3 Alanındaki En Büyük Fonudur
bilgi
