No Solutions #2. There Is No Global w/ Pablo¶

Epizód: #2 • Dátum: 2025. február 15. • Házigazda: No Solutions host (Sovereign Engineering) • Vendég: Pablo Forrás: https://sovereignengineering.io/podcast/02-there-is-no-global-w-pablo Transcript: SRT (https://haven.dergigi.com/5d57d7076a12c26dbd0e84201eea0421e3cee8013101c371e5970da33ed03ea4.srt), saját letöltés 2025-02-15, 13926 szó, ~70 perc — séta a szigeten, hullámzajjal

Összegzés¶

A No Solutions #2 a sorozat második epizódja, amely 2025 február 15-én készült, és a „There Is No Global” címet kapta. A transcript 13926 szót tartalmaz, és a séta-formátumban a házigazda és Pablo a globális, központosított rendszerek kudarcait elemzik a Bitcoin/Nostr-tér kontextusában. Az epizód központi állítása: a „global view” mint célkitűzés fizikailag és logikailag lehetetlen, és mindenki, aki mégis megpróbálja (a YouTube view counter, a like count, a Twitter trending), hazudik.

A párbeszéd első nagy szakasza a „distributed cognition” fogalmát járja körül. A házigazda kiemeli: a nagy, nehéz problémákat nem egyetlen személy oldja meg, hanem elosztott kogníció — repülőgépet, hadihajót, multinacionális vállalatot nem egyetlen személy irányít, hanem rendszerek és emberek együttese. Pablo ehhez hozzáteszi: nincsenek „igazán eredeti gondolatok”, minden remix, minden gondolat valami másból származik, és ezért a „logo” szentsége a nyugati gondolkodásban nem véletlen — a szabad véleménynyilvánítás az egyetlen módja a komplex problémák megközelítésének. Az evolúció a párhuzam: az élet problématerében nincs „tökéletes organizmus”, a kérdés értelmetlen.

A második nagy szakasz a „global view” lehetetlenségét elemzi. Pablo érvelése: ha globális képet akarsz a világról, újra kell építened a Bitcoint — proof of work, minden korlátozás, minden kompromisszum. A YouTube view counter egy „teljes hazugság”, a like count egy „teljes hazugság”, és a sebességkorlát (a fénysebesség, az információ terjedésének fizikai korlátai) miatt ez mindig így lesz. A Bitcoin csak a saját rendszerének igazságát állítja — nem állítja, hogy globális képe lenne minden másról. A párhuzam a Nostr-ra: a Nostr is csak a saját rendszerének (a felhasználó által aláírt események) igazságát állítja, és ez elég.

A harmadik szakasz a „naming problem” és a „central registry” csapdáját tárgyalja. A DNS az internet egyik alapvető technológiája, de centralizált megoldás: a központi registry-t bárki eltávolíthatja vagy megváltoztathatja. A NIP-05 (a Nostr „ellenőrzött” névkiszolgáló mechanizmusa) ugyanebbe a csapdába esik, mert bárki, aki a domain felett rendelkezik, visszavonhatja az ellenőrzést. A Suko Triangle (nincs trusted third party nélküli globális felhasználónév-rendszer) egy matematikailag bizonyítottan megoldhatatlan probléma, és a „fix” kísérletek (NIP-05, ENS, DNS-based) mind visszavezetnek a centralizációhoz.

A negyedik szakasz a fault tolerance kérdését járja körül. A házigazda a RAID analógiát használja: a Bitcoin a RAID extrém formája, ahol „amíg egyetlen merevlemez túléli, minden rendben”. A Nostr ugyanezt az elvet követi a relay-eknél: ha egy relay leáll, nem számít, mert az adat máshol is elérhető. A Wallet of Satoshi kitiltása az US-ből vagy a Primal leállása nem „fault tolerant” rendszer, míg a Damus relay kétszeri „kiütését” szinte senki nem érezte meg. A Blossom szerverek (a Nostr médiatároló protokollja) ugyanezt az elvet követik, bár a „self-healing links” még nem minden kliensben érhető el.

Az ötödik szakasz a building blocks koncepciót artikulálja. A házigazda a nyári Sovereign Engineering cohort-on tartott előadásában a „building blocks” (Legó-darabkák) metaforát használta: a NIP-60 (Nostr ecash wallet), a NIP-61 (Nostr nutzaps), a Blossom (médiatárolás), a NIP-89 (app discovery) mind önálló építőelemek, mindegyiknek megvan a maga trade-offja. A cél: nem egy tökéletes megoldás, hanem egy sor jól definiált, jól dokumentált építőelem, amelyekből a fejlesztő kiválaszthatja a feladathoz illőt.

A hatodik szakasz a local-first mozgalom és a Nostr párhuzamát elemzi. A local-first közösség (amelyik arról szól, hogy az alkalmazások akkor is működjenek, ha offline vagy) ugyanazokat a problémákat azonosítja, mint a Nostr-fejlesztők: data ownership, identity, sync. A megoldásaik (Passkey, end-to-end encrypted sync) visszavezetnek a centralizációhoz (az Apple/Google ecosystem-ekbe zárva). A tanulság: a helyes kérdésfeltevés nem elég, a megoldásnak is illeszkednie kell a „no global view” elvéhez.

Az epizód záró momentumában a házigazda bejelenti: a transcriptben említett „ecash fixes 402” gondolatmenetét külön epizódban fogja részletesen kifejteni (ez lesz a No Solutions #4, Calle-val). A transcript utolsó mondata: „we're gonna figure this out”, a sorozat alapító bizalma abban, hogy a building blocks és a párbeszéd révén a Bitcoin/Nostr-tér ki tudja építeni a „next iteration of the internet” -et.

Az epizód kontextusa, a „no global” mint központi gondolat¶

A No Solutions #2 a sorozat „operating principles” epizódja: itt tisztázzák, hogy a Bitcoin/Nostr-tér nem „fix” -e a web 2.0-nak, hanem egy más alapokra épülő rendszer, amelyik elfogadja a fizikai és logikai korlátokat. Az epizód címe („There Is No Global”) explicit utalás a fizika törvényeire (a fénysebesség, az információ terjedésének korlátai) és a logikai lehetetlenségekre (Suko Triangle, a central registry-k sérülékenysége).

A „no global” elv összekapcsolja a Bitcoin és a Nostr alapvető filozófiáját. A Bitcoin csak a saját rendszerének (a saját blockchain) igazságát állítja, és nem próbál globális képet adni a világról. A Nostr ugyanezt teszi: az adat aláírása a felhasználó kulcsával történik, és a hitelesség nem függ attól, hogy az adat melyik relay-ről jött. Ez a fajta „local truth” a hagyományos web-modellel szemben áll, amelyik központi szerverekre bízza az igazságot (és ezzel sebezhetővé válik a cenzúrával és a hibakezeléssel szemben).

A distributed cognition és az evolúció analógiája¶

Az epizód egyik legfontosabb gondolati építőköve a „distributed cognition” fogalma. A házigazda kiemeli: a „nagy, nehéz problémák” (repülőgép-irányítás, hadihajó-irányítás, egy nagyvállalat vagy egy ország működtetése) nem egyetlen személy által oldódnak meg, hanem elosztott kogníció révén, rendszerek és emberek együttese, ahol senki nem érti a teljes képet, de a rendszer mégis működik.

Az evolúció a párhuzam: „What is the perfect organism? There is no perfect organism. The question makes no sense.” A Bitcoin és a Nostr is ilyen rendszerek: nincs egyetlen tökéletes kliens, nincs egyetlen tökéletes wallet, nincs egyetlen tökéletes feed algoritmus. A cél nem a tökéletes megoldás megtalálása, hanem a rendszer adaptivitásának fenntartása — az evolúció elve, ahol a hibák és a váratlan felhasználási módok a rendszer erősségeivé válnak.

A házigazda példája: a Viagra-t a Pfizer kutatói szívgyógyszernek szánták, de a felhasználók „másra” kezdték használni. Ugyanez történik minden sikeres szoftverrel: a fejlesztő soha nem tudja előre, hogy a felhasználók hogyan fogják használni a terméket. A „ship it and find out” filozófia a distributed cognition gyakorlati megvalósítása.

A „naming problem” és a central registry csapdája¶

Az epizód egyik legkonkrétabb technikai vitája a „naming problem” -ről szól. A DNS az internet egyik alapvető technológiája: a központi registry (ICANN, a domain registrars) tartja a kapcsolatot az IP-címek és a domain nevek között. Ez a centralizáció teszi lehetővé a cenzúrát: ha valaki eltávolít egy domaint a registry-ből, az adott domain eltűnik az internetről.

A NIP-05 (a Nostr „verified address” mechanizmusa) ugyanebbe a csapdába esik. A NIP-05 lehetővé teszi, hogy egy felhasználó a domain nevét (pl. „alice@example.com”) a Nostr pubkey-jéhez kösse, de a domain feletti ellenőrzés a domain tulajdonosánál marad. Ha a domain törlődik vagy a NIP-05 rekord eltűnik, a felhasználó „elveszíti” a nevét.

A Suko Triangle (amelyet a házigazda idéz) egy információelméleti bizonyítás: megbízható, globális, centralizált hatóság nélküli névkiosztás nem lehetséges. Vagy van egy központi hatóság (és akkor visszatérünk a DNS-hez), vagy nincs globális név (és akkor a felhasználónak az npub-ját kell használnia, ami egy hosszú hexadecimális string). A NIP-05 egy kompromisszum: a domain-t használja trusted third party-ként, és ez a kompromisszum a trade-off része.

A házigazda érvelése: „if you care about long-lived things, you must not have a central register”. A „censorship-resistant” szót a házigazda kerüli („bad marketing”), és helyette a „100% uptime” -ot használja, ami ugyanazt jelenti, de a marketing-beszédtől mentes. A central registry nélküli rendszer (a Nostr npub rendszere) nem tökéletes (a felhasználónak hosszú stringeket kell kezelnie), de hosszú távon fenntartható.

A fault tolerance és a Blossom, mint analógiák¶

A „no global” elv egyik legfontosabb gyakorlati következménye a fault tolerance. A házigazda a RAID analógiát használja: RAID 5-ben egy lemez meghibásodása nem kritikus, kettő már az. A Bitcoin a „szélsőséges RAID”, amíg egyetlen teljes csomópont túléli, a rendszer működik. A Nostr ugyanezt az elvet követi a relay-eknél: ha egy relay leáll, a felhasználó egyszerűen átvált egy másikra, és az események onnan is letölthetők.

A Wallet of Satoshi kitiltása az US-ből és a Primal leállása (ha a cache szerverek leállnak) a „nem fault tolerant” rendszerek példái. A Damus relay „kiütése” (amely a transcript tanúsága szerint legalább kétszer megtörtént) szinte észrevehetetlen volt, mert a felhasználók egyszerűen átváltottak más relay-ekre. Ez a fajta ellenállóképesség a Nostr alapvető előnye a centralizált platformokkal szemben.

A Blossom (a Nostr médiatároló protokollja) ugyanazt az elvet követi a médiatartalomra: ha egy Blossom szerver leáll, a tartalom más szerverekről is elérhető. A házigazda kiemeli: a Blossom egy „left side of the curve” megoldás — egyszerű, nem old meg minden problémát (nagy fájlok streamelésére a torrent jobb), de a gyakori use case-ekre elegendő. Az IPFS példája a túlzás: a deduplikáció maximalizálása visszaütött, mert egyetlen shard elvesztése az egész fájlt elérhetetlenné tette.

A Blossom konkrét példája a transcriptben: a No Solutions podcast MP3 fájljait a Blossom szerver szolgálja ki. Ha a podcast-sorozat sikeres lesz, „ez a tartalom egy ideig elérhető marad, és nagyon nehéz lesz megszabadulni tőle” — vagyis a Blossom a decentralizált podcast-archívum alapja.

A building blocks és a NIP-89, mint felfedező eszköz¶

Az epizód egyik legfontosabb gyakorlati momentuma a „building blocks” (Legó-darabkák) koncepció. A házigazda kiemeli: a Bitcoin/Nostr-tér az elmúlt egy-két évben rengeteg építőelemet hozott létre, és ezek együttesen egy „design space” -t nyitnak, amelyben a fejlesztő kiválaszthatja a feladathoz illő kombinációt.

A konkrét építőelemek, amelyeket a transcript említ:

NIP-60: Nostr ecash wallet specifikáció (Nutstash wallet). A „honeypot wallet” példa (amelyet az #1 epizódban Pablo említ) a NIP-60 implementáció korai szakaszának tanulsága.
NIP-61: Nostr nutzaps (a zaps ecash tokenekben fizetett változata).
Blossom: médiatároló protokoll, amely a Nostr eseményekhez csatolt médiafájlokat tárolja.
NIP-89: app discovery specifikáció, amely lehetővé teszi, hogy egy kliens „felfedezze”, hogy egy másik kliens milyen képességekkel rendelkezik (pl. „live streaming support”).
NUT-12, NUT-14: cashu token specifikációk (a NIP-60 alapjai).
LSP (Lightning Service Provider): a Lightning csatornák megnyitásának és fenntartásának külső szolgáltatója.

A NIP-89 külön említést érdemel. A hagyományos app discovery (Google Play, App Store) centralizált: a felhasználó elmegy egy központi helyre, és ott találja meg az alkalmazásokat. A NIP-89 ezzel szemben „app speaks for itself” elvet követ: az alkalmazás egy aláírt NIP-89 eseményt tesz közzé, amely leírja, hogy milyen képességeket támogat. A felhasználó az eseményt bármelyik relay-ről lekérheti, és nem függ egy központi directory-tól. Ez a fajta felfedezés analóg a Bitcoin blokkok felfedezésével: nem számít, hogy a blokk honnan jött, a validáció a tartalom (a proof of work) révén történik.

A házigazda kiemeli: a NIP-89 egy „radikálisan különböző” megközelítés, mert a discovery „a felhasználók interakciójából” származik, nem egy központi directory-ból. Ha a felhasználó követ valakit, aki live streamel, de nem tudja, hogy az adott kliens támogatja-e a live streamet, a NIP-89 esemény megmondja. Ez a fajta „capability discovery” a web 2.0-ban nem létezik.

A local-first mozgalom és a Nostr párhuzama¶

Az epizód egyik legérdekesebb kitérője a local-first mozgalom. A local-first (vagy „offline-first”) alkalmazások célja, hogy a szoftver akkor is működjön, ha nincs internet. A példák: Apple Notes (offline is működik), Linear (offline is szerkeszthető), Figma (offline is használható).

A local-first közösség ugyanazokat a problémákat azonosítja, mint a Nostr-fejlesztők: data ownership (az adat a felhasználónál van), identity (a felhasználó azonosítása), sync (több eszköz közötti szinkronizáció). A megoldásuk a Passkey-re és az end-to-end encrypted sync-re épül, ami visszavezet a centralizációhoz: a Passkey-t az Apple/Google tárolja, és ha ezek a szolgáltatók úgy döntenek, hogy deplatformolják a felhasználót, az elveszíti a hozzáférést a saját adataihoz.

A házigazda kiemeli: a helyes kérdés („how do you solve identity”) nem elég, a megoldásnak is a „no global” elvet kell követnie. A Nostr npub rendszere (amely a felhasználó saját kulcsa) megfelel ennek: az npub nem függ egyetlen szolgáltatótól sem, és a felhasználó szabadon viheti bármely kliensbe, bármely eszközre. A Passkey ezzel szemben egy „API call” a felhasználó adataihoz, és az Apple/Google bármikor megváltoztathatja.

A local-first mozgalom és a Bitcoin/Nostr-tér közötti párhuzam a „sync problem”. Mindkét közösség szembesül azzal, hogy ha a felhasználónak több eszköze van (telefon, laptop, tablet), és ezek nincsenek egyszerre online, akkor a szinkronizálás konfliktusokat generál. A Git fejlesztők ismerik ezt a problémát (merge conflict-ok), és a megoldás a conflict resolution — ami sosem tökéletes, de jobb, mint a „central authority decides” modell.

A 402-es hibakód és az ecash, mint a „next iteration” alapja¶

Az epizód egyik legfontosabb technikai utalása a HTTP 402-es hibakód („Payment Required”) és az ecash. A 402-es hibakód az eredeti HTTP specifikációban (1990-es évek) szerepelt, de soha nem implementálták, mert a fiat fizetési rendszerek nem támogatták a mikrofizetéseket.

A házigazda érvelése: „we were never able to build out the 402 error code payment required, it just didn't work on fiat payment rails. It doesn't work on fiat payment rails. It just doesn't work. It can not work.” A fiat payment rails ugyanis „credit rails” (hitelalapú fizetések), és a hitel KYC-t igényel. A 402-es implementálásához KYC-mentes, azonnali, minimális összegű fizetés kell, és ezt a Bitcoin (különösen a Lightning) és az ecash (cashu tokenek) teszik lehetővé.

Az ecash (a transcriptben „e-cash fixes 402”) a No Solutions #4 epizódjának központi témája lesz, Calle-val. A jelenlegi #2 epizódban a házigazda csak jelzi, hogy ez egy fontos téma, amelyet külön fog tárgyalni. A kontextus: a cashu protokoll (és a NIP-60 wallet-ek) a 402-es implementálásának egyik első kézzelfogható lehetősége a Bitcoin/Nostr-térben.

A „no rug pull” mint killer app¶

Az epizód második felében a házigazda kifejti, miért a „no rug pull” a Nostr killer appja. A példa: sok fejlesztő építette a karrierjét a Reddit API-ra, és most mind „rug pulled”. Ugyanez történik a YouTube API-val, a Twitter API-val, és minden más centralizált API-val. A házigazda személyes története: egy cégnél dolgozott, amelyik megváltoztatta a KYC provider-jét és a banking partnerét, és minden korábbi kódot újra kellett írni az új API-khoz. Ez a fajta „rug pull” ellen nincs védelem, ha a szoftver egy cég API-jára épül.

A Nostr ezt a kockázatot kiküszöböli, mert a protokoll nem változtatható meg egy cég döntésével. A NIP-ek (Nostr Implementation Possibilities) nyílt specifikációk, és bárki implementálhatja azokat. Ha egy kliens eltűnik, egy másik átveszi a szerepét. Ha egy relay leáll, a felhasználó átvált egy másikra. Ez a fajta „built to last” infrastruktúra a Bitcoin-tér egyik alapvető értéke, és a Nostr erre épül.

A házigazda párhuzama a gátakkal (dams): egy gátnak 500 évig kell kitartania, és a mérnököknek a „legrosszabb esetre” kell tervezniük (100 évente egyszer előforduló extrém áradás). A szoftver-infrastruktúrában ez a fajta „long-term thinking” ritka, és a legtöbb szoftver „disposable”. A Nostr célja, hogy olyan infrastruktúrát építsen, amelyik túléli a szerzőit — ahogy az SMTP is túléli az RFC 822 szerzőit.

A Bitcoin-Nostr „fiat credit rails” kritikája¶

Az epizód egyik legélesebb kritikája a fiat payment rails ellen irányul. A házigazda érvelése: „fiat implies fiat credit, fiat rails are credit rails, and credit requires KYC”. Vagyis minden fiat-alapú fizetési rendszer hitelalapú, és minden hitel KYC-t igényel. Ebből következik, hogy a fiat rendszerben a 402-es implementálás „egyszerűen nem lehetséges”, mert a mikrofizetés és a KYC összeegyeztethetetlen.

A Bitcoin (különösen a Lightning) és az ecash ezt a korlátot küszöböli ki. A Lightning csatornák megnyitása viszonylag egyszerű (és a 2024-2025-ös LSP-k révén egyre könnyebb), a tranzakciók másodpercek alatt lebonyolódnak, és a díjak filléres nagyságrendűek. Az ecash (cashu tokenek) a privacy-t is hozzáadja: a tranzakciók anonimak, és a felhasználó nem függ egyetlen banki azonosítótól sem.

A „fiat credit rails” kritikája párhuzamba állítható a „data ownership” kritikával (amely a No Solutions #3 epizód központi témája lesz). Mindkettő ugyanarra a strukturális problémára mutat rá: a centralizált rendszerek a „global view” illúzióját kínálják, de a valóságban törékenyek, cenzúrázhatók, és a felhasználót kiszolgáltatottá teszik.

Vendég: Pablo¶

Pablo a Sovereign Engineering cohort alapító tagja, és a No Solutions sorozat visszatérő vendége. A #2 epizódban konkrét technikai referenciái: a Blossom protokoll (amelyet a No Solutions podcast MP3 fájljait hosztolja), a NIP-89 (amelyről a házigazda Tokióban tartott előadást), és a Nostr „building blocks” gondolatmenete, amely a nyári Sovereign Engineering cohort-on artikulálódott. A transcriptben említett konkrét projektjei: a „cohort-tal kapcsolatos demo day”, ahol az ötletek bemutatkoztak, és a Nostr kliensek fejlesztése, amelyek a building blocks paradigmát követik.

Házigazda¶

A No Solutions házigazdája a Sovereign Engineering egyik alapítója, akinek neve a transcriptben nem derül ki explicit. A #2 epizódban a házigazda stílusa a #1-hez képest filozofikusabb: a „distributed cognition”, a „no global view”, a „naming problem”, a „fault tolerance” és a „local-first mozgalom” mind olyan absztrakt témák, amelyek a gyakorlati Bitcoin/Nostr tapasztalatokból indulnak ki, de eljutnak az általános rendszer-tervezési elvekig. A házigazda aktívan használja a RAID analógiát, a gátak (dams) párhuzamát, és a „left side of the curve” kifejezést, amely a Bitcoin/Nostr-térben a „minimálisan elegendő megoldás” filozófiáját jelenti.

Kulcsmondatok¶

„We do not have the answers.” — No Solutions host
„There is no global. There is no global view of the whole thing. It's impossible.” — Pablo
„If you want to have a global view, you need to build Bitcoin.” — Pablo
„The killer app of Nostr is you can't be rug pulled.” — No Solutions host
„There is no solution. There are only trade-offs.” — No Solutions host

A beszélgetés főbb témái¶

A „distributed cognition” és az evolúció, mint rendszer-tervezési analógiák
A „no global view” elve: a fénysebesség, a logikai korlátok és a központi view count-ok hazugsága
A naming problem és a central registry csapdája (DNS, NIP-05, Suko Triangle)
A fault tolerance: RAID analógia, Blossom, relay-ek és a „kill one server, system survives” elv
A building blocks paradigma (NIP-60, NIP-61, Blossom, NIP-89, NUT-12, NUT-14)
A local-first mozgalom és a Nostr párhuzama (ugyanaz a kérdés, más megoldás)
A 402-es hibakód és az ecash, mint a Bitcoin/Nostr „next iteration” alapja
A „no rug pull” killer app és a multi-generational infrastruktúra

Főbb érvek és gondolatmenetek¶

Az epizód érvelési struktúrája öt nagy blokkra osztható. Az első a distributed cognition és az evolúció: a nagy problémákat nem egyetlen személy oldja meg, és nincs „tökéletes megoldás”, csak adaptív rendszerek. A második a „no global view” fizikai és logikai korlátai: a fénysebesség és a Suko Triangle miatt a globális nézet nem lehetséges. A harmadik a naming problem és a central registry: minden globális névkiosztó rendszer centralizált, és a centralizáció sebezhető. A negyedik a fault tolerance és a building blocks: a Bitcoin/Nostr-tér ellenállóképessége a relay-ek, a Blossom és a NIP-89 révén valósul meg. Az ötödik a local-first párhuzam és a „no rug pull” killer app: a Nostr-tér ugyanazokat a kérdéseket teszi fel, mint a local-first mozgalom, de a megoldásai a „no global” elvet követik.

Szakmai párhuzamok és kontextus¶

A „no global view” elv párhuzamba állítható a „nem tudod a teljes képet” episztemológiai korláttal. A tudományfilozófiában ez a „local knowledge” vagy „tacit knowledge” fogalomhoz kapcsolódik (Michael Polányi „The Tacit Dimension” -je, Hayek „The Use of Knowledge in Society” -je). A Bitcoin/Nostr-tér ezt a felismerést technikai szintre emeli: a rendszer nem törekszik a globális kép elérésére, hanem elfogadja a lokális, aláírt események szintjén a hitelességet.

A Suko Triangle párhuzamba állítható a CAP theorem-mel (Consistency, Availability, Partition tolerance, bármelyik kettő egyidejűleg nem teljesíthető). A Bitcoin a Consistency és az Availability között választ, míg a Nostr inkább az Availability és a Partition tolerance között. Mindkettő a „no global view” elv gyakorlati megvalósítása.

A local-first mozgalom a 2020-as évek elején indult (Ink & Switch, Martin Kleppmann munkássága). A CRDT (Conflict-free Replicated Data Types) és az Automerge a local-first szoftver-technikai alapjai. A Nostr nem CRDT-alapú, de a „saját kulcs, saját adat” elv analóg a local-first „saját eszköz, saját adat” elvével.

A „no rug pull” killer app párhuzamba állítható a nyílt forráskódú szoftverek hosszú távú fenntarthatóságával. A Linux kernel, a PostgreSQL, a Python interpreter mind olyan szoftverek, amelyek túlélték az eredeti szerzőiket, és a közösség (a maintainer-ek és a felhasználók) révén tovább fejlődnek. A Nostr célja, hogy a szoftver-infrastruktúra (kliensek, relay-ek, wallet-ek) hasonlóan hosszú életű legyen — és a „no rug pull” ennek az ígérete.

Forrás¶

Epizód URL: https://sovereignengineering.io/podcast/02-there-is-no-global-w-pablo
Transcript forrás: Haven SRT (https://haven.dergigi.com/5d57d7076a12c26dbd0e84201eea0421e3cee8013101c371e5970da33ed03ea4.srt), saját letöltés 2025-02-15, 13926 szó
No Solutions podcast: https://sovereignengineering.io/podcast