Open Markets Podcast #13. The return of Gzuuus (2026-08-10)¶

Epizód: #13 The return of Gzuuus | Open Markets Podcast
Házigazdák: Eric FJ és Sync
Vendég: Gzuuus (az Open Markets / Gamma Markets specification egyik alapító atya, 3-4 hét kihagyás után tért vissza)
Forrás: fountain.fm/episode/c1k9LTKA5Q8vFSvNuzqt
Audió: feeds.fountain.fm/iKaquCnTj0q5Bg2VfGRD/items/3d9EzQWjZLsHGCF1eBRa
Hossz: 2 óra 20 perc (8405 másodperc)
Transcript: Fountain.fm emberi SRT, 22 499 szó, 8 chapter, 0 hallucination

Összegzés¶

Visszatért Gzuuus, az Open Markets / Gamma Markets specification egyik alapító atyja, 3-4 hét kihagyás után, a 13. epizód vendége és egyben korábbi társ-házigazdája.
Stacey csatlakozott a conduit-hoz, a Bitcoin projekt világából átigazolt a conduit céghez, és a közösség építésén dolgozik majd; a csapat örömmel fogadta.
A Bitcoin biztonsági incidensek a fejlesztői ökoszisztémát érintik, a BTCPay-t futtató node-ok üzemeltetőinek figyelmeztetése: a macaroon adatbázis fájlok és a node-k frissítése kötelező.
A Nostr közösségi klíma feszült. Eric FJ elismeri, hogy a Nostr jelenleg "nem szuper fun hely", és ez a felhasználók belső állapotát is tükrözi; nem csak az algoritmusok hibája.
Calvadev cikke: "Nostr is not for social media", egy "spicy take" a feed-ekben, amelyet a műsorvezetők felhoznak, és Gzuuus is véleményez (Madeirára utazás miatt nem olvasta).
Az Open Markets weboldal "clanker-first" filozófiája, a háromrétegű (front-end + dokumentáció + podcast site) struktúra célja, hogy AI-ágensek is szuverén mérnöki etikát tanuljanak a tartalomból; a kontextus-injekció elengedhetetlen a ritka/élvonalbeli technológiákhoz.
A Gamma Markets specification eredete (HCC03, Madeira). Gzuuus, Sync (akkor még Zinc) és Carva (Calabas/Tradersext) közösen dolgozta ki a NIP-99 kiterjesztését, hogy a NIP-15 "convoluted" problémáit megoldja; a NIP-99-re épülő piactér-specifikus bővítés lett a Gamma Markets alapja.

A 13. epizód nyitánya és a vendég bemutatása¶

A 13. epizód a megszokott Amazon-Open Markets dichotómiával nyit ("Alleging that Amazon abused its position... but then using the data from these independent sellers to better make their own private label products"). A műsorvezetők (Eric FJ és Sync) és a 3-4 hét után visszatérő Gzuuus együtt futják át a felgyülemlett anyagot.

"Welcome back to the Open Markets Podcast. My name is Eric FJ. And my name is Sync. And today, we have a very, very special guest with us. Someone that is probably overdue being on this show, just considering his early involvement in this movement."

"Gzuuus was involved at the inception of the Open Markets movement, the Gamma Markets specification. We'll get into that later on in the show. But for now, my friend, you are a co-host on this podcast."

"We got to extract as much value from our colleague here, Gzuuus, over some of his development stuff because there's really cool things going on there."

Gzuuus a Bitcoin OG-k egyike: ő írta a Gamma Markets specification alapjait, és az Open Markets ökoszisztéma központi fejlesztője. A visszatérése alkalmat ad a közösségi bejelentések és a kimaradt hetek áttekintésére.

Stacey átigazolt a conduit céghez¶

A műsor egyik legfontosabb bejelentése Stacey csatlakozása a conduit csapatához. Stacey korábban egy másik Bitcoin projektben dolgozott, és a stáb szándékosan várt a bejelentéssel, hogy legyen ideje lezárni előző kötelezettségeit.

"We got a big announcement from Stacey who joined the conduit company. Yes, community. Yes, she did. So we've been chatting for quite a while, and I wanted to give her some space to sort of close up her previous involvement in another Bitcoin project."

Stacey a közösség építésén fog dolgozni, és Eric FJ hangsúlyozza, hogy a conduit ökoszisztéma köré szerveződő közösség mostantól szélesebb bázisra épül. A bejelentést a résztvevők örömmel fogadták, és a műsor folytatásában Stacey jövőbeli szerepéről is szó esik.

Bitcoin biztonsági incidensek a BTCPay ökoszisztémában¶

A kimaradt hetek legfontosabb fejleménye a BTCPay szervereket érintő biztonsági incidensek sora. A támadók a node-ok macaroon adatbázisát és a node-szervereket kompromittálták, és a fejlesztői közösség figyelmeztetést adott ki.

"Things will pass, but yeah, just heads up. If you're running a BTCPay instance and you're hearing it on this podcast, you know you should probably turn your machine down and do a proper update and do proper management of where your database file was stored with your macaroons and stuff like that."

A műsorvezetők a "shout out" jellegű figyelmeztetést a gyakorlati oldalról közelítik meg: a BTCPay-t futtatók számára azonnali teendő a node frissítése és a macaroon tárolás átvizsgálása. A konkrét technikai részletek a BTCPay saját közleményeiben és a fejlesztői GitHub issue-kban találhatók.

Az Open Markets ökoszisztéma helyzete¶

A 3-4 hetes kihagyás alatt az Open Markets ökoszisztéma is fejlődött. A conduit projektek köré szerveződő közösség újabb tagokkal bővült, és a fejlesztési ütem is felgyorsult. A műsorvezetők jelzik, hogy a műsor tempója a "value for value" modellhez igazodik: lassabb, de tartalmasabb, és minden epizód célja a vendégből a lehető legtöbb értéket kihozni.

"We're going to go through it at a reasonable tempo. We got to extract as much value from our colleague here, Gzuuus, over some of his development stuff because there's really cool things going on there."

A nyitó szakasz a klasszikus Open Markets dramaturgiát követi: a műsorvezetők a közösségi bejelentésekkel (Stacey conduit-hoz csatlakozása) indítanak, majd a Bitcoin ökoszisztémát érintő biztonsági fejleményekkel (BTCPay) folytatják, és csak ezután térnek rá a vendégre, Gzuusra, és az ő fejlesztéseire.

A Nostr jelenlegi állapota: közösségi feszültség¶

A műsor második blokkja a Nostr ökoszisztémát érintő visszajelzésekkel nyit. Eric FJ őszintén beszél a platform jelenlegi klímájáról, és a közösség belső állapotát is figyelembe veszi.

"Of course, not. Nostr has been, let's just say, not not a super fun place to be right now. And it, you know, I guess it wasn't just algorithms. I guess it's all of us together. But at the same time, it is an accurate reflection of what people are going through, so it's just the truth. And you can't, you know, looking away from the truth. It's also not a good idea."

A "looking away from the truth" kitétel fontos: a műsorvezetők nem bagatellizálják a feszültséget, de a "things will pass" hozzáállással keretezik. Ez a nyíltság a Bitcoin-közösségben ritka, és a podcast alapvető pozíciója: a konfliktusokat nem eltussolni kell, hanem felismerni és kezelni.

A blokk központi eleme a Calvadev által írt cikk, amely a Nostr protokoll alapvető természetéről szól. A cikk címe provokatív, és a műsorban Eric FJ hozza fel, jelezve, hogy ez egy fontos téma.

"Calvadev wrote an interesting article that you know popped on my feed, and I read it. We'll link to it in the show notes. And it was kind of a spicy title and a spicy take. And he says, you know, Nostr is not for social media."

"Did either of you two get a chance to read this one? I did not, no, no. Mr. Gzuuus, I don't know if you had, did you have a chance to look at Calvadev's article there? No, not really. Or pop onto your feed? Okay. No, not really, because I have been traveling to come here to Madeira."

A cikk alapüzenete az OG-k körében régóta ismert: a Nostr egy protokoll (layer), nem egy social media alkalmazás. A felhasználók és a fejlesztők gyakran összekeverik a kettőt, pedig a Nostr célja egyáltalán nem a Twitter klónozása, hanem a decentralizált identitás és a szuverén kommunikáció biztosítása.

"I got two OGs with me. The only the other missing OG is Calvadev and of course chief monkey."

A műsorvezetők az OG-k (Original Gangsters) hierarchiáját is megjelenítik: Eric FJ, Gzuuus, Sync, Calvadev, chief monkey. A Nostr ökoszisztémában az OG-k státusza a korai hozzájárulás és a hosszú távú elköteleződés függvénye, és ez a közösségi tőke egyfajta reputáció-rendszert hoz létre.

Gzuuus Madeirára utazott a felvételre¶

Gzuuus a 13. epizód kedvéért utazott Madeirára, és az utazás fáradalmait viccesen ecseteli. A műsorvezetők az érkezés körülményeiről kérdezgetik, és a sziget infrastruktúráját dicsérik.

"I have been traveling to come here to Madeira. You know, every time that you arrive here, it's a bit hectic, but it's always nice."

A Madeira mint location fontos: az Open Markets podcast a Bitcoin-közösség egyik központi eseménye, és a személyes találkozók a távoli fejlesztőkkel (mint Gzuuus) a közösségépítés alapjai. A műsorvezetők többször is jelzik, hogy a podcast a "value for value" modellre épül, és a vendégek gyakran saját költségükön jönnek el.

A Nostr jövője: protokoll vs alkalmazás¶

A blokk záró gondolata a Nostr protokoll vs alkalmazás megkülönböztetés fontossága. A "Nostr is not for social media" érv lényege, hogy a felhasználók és a fejlesztők gyakran a Twitter klónjaként kezelik a Nostr-t, pedig a protokoll sokkal több: bármilyen alkalmazás építhető rá, és a szuverenitás, az identitás és a cenzúra-ellenállás a fő értékajánlat.

"The Nostr have a very interesting feature is that no one can stop you to writing or speaking. So, you know, the protocol is open. You can build whatever you want on top of it."

A jelenlegi feszültség egyik oka, hogy a közösség egy része a Twitter-höz hasonló élményt vár el, míg mások a protokoll-szintű szabadságot helyezik előtérbe. A műsorvezetők jelzik, hogy ez a vita nem új, és a Bitcoin-történetben is voltak hasonló elágazások (pl. a Bitcoin Cash vs Bitcoin Core vita).

Frissítések és apró szállítási praktikák¶

A beszélgetés elején Eric (FJ) és Gzuuus a személyes helyzetüket osztják meg: Eric egy hét múlva Roatan-ba repül, és egy Gzuuus által korábban szervezett chicagói szeptemberi eseményt említ, ami a „movement” (a freedom tech mozgalom) fő célpontja.

Sync ezután a kétheti frissítési listáját veszi elő. Az első: egy nyomtatott könyvet postázott Therese-nek, és a csomagfeladásnál a futár megkérdezte, van-e pénz a csomagban. A trükk az volt, hogy Sync viccből e-notes-t (Cashu/ecash nyomtatott formában) is elhelyezett volna, mert akkor a feladó valójában „pénzátutalóvá” vált volna — de a futár végül nem nyitotta ki a csomagot, mert szépen volt csomagolva.

Egy praktikus szállítási tipp is elhangzik a szolgáltatási pontok kezeléséről:

„if you want to make a label right to ship something off to to a an actual service point through the website it's impossible to do because you cannot select the service point in and of itself right so and when you make the label you have to add an address... but if you enter hold for collection... they'll hold it at the the local collection point so that's something nice to know.”

A Therese-ről készült videó a könyv átvételéről, a raffle egyfajta „cool update”-je — szintén megerősíti a közösségi lendületet.

Az Open Markets weboldal háromrétegű struktúrája és a „clanker-first” filozófia¶

A frissítési lista második nagy eleme, hogy Sync „tegnap csendben elkezdte tolni” az Open Markets weboldalt. A weboldal három, egymással lazán összekötött, de külön build-del rendelkező részből áll:

Általános front-end, a nyilvános weboldal.
Dokumentáció, ahol a kódokat és a magyarázatokat teszik közzé.
Podcast site, magának a műsornak az oldala.

A mélyebb filozófiai háttér az AI-korszak hatása: Sync rámutat, hogy most milliók tudnak egy géphez fordulni és „csak építeni valamit”, de ha az architektúra, az etika és a reasoning nincs jól beépítve, akkor „quite south quite fast” mehet a dolog. A cél ezért egy „clanker-first” tartalom:

„if we don't add the right architecture if we don't add the right ethics or the the right reasoning into there it might go quite south quite fast and I think that's something why splitting the first piece of the website off in just content just stuff that is meant for a clanker who shows up to a website basically goes through all the content and what comes out is half of a sovereign engineer basically.”

A terv második rétege, hogy ha egy ritka „igazi ember” olvassa a honlapot, akkor a narratíva olyan erős legyen, hogy a felhasználó később a saját klankerét irányítva térjen vissza és csatlakozzon. A harmadik üzenet, hogy a fejlesztők „usually have no fundamental architectural knowledge of development”, ezért ezt a szuverenitás-ideológiát explicite be kell sűríteni a klankernek adott kontextusba. Eric egyből rákérdez:

„are you telling me that by having clankers navigate to our website there you are sort of hacking or prompt injecting freedom tech principles into the clankers as they as they come across that”

Sync megerősíti, hogy ez a szándék: a szövegnek önmagában kell hordoznia a szuverén mérnöki etikát, és építészetileg is „Nostr-kliens-szerű” alkotásnak kell kijönni, nem centralizált mintázatú szoftvernek. Ezzel egy korábbi podcast-epizód vendégére, Eugene-ra utal, akivel hasonló write-up-ról beszélgettek.

Gzuuus a „clankerek coacholásáról” és a ContextVM-ről¶

A beszélgetés Gzuuus felé fordul, és Eric kifejezetten a ContextVM-mel kapcsolatos tapasztalatait kérdezi. Gzuuus válasza egybecseng Sync gondolatmenetével:

„if you are able to translate that to plain English and to give the clanker some guidelines and enough ethics and ways to build it right or what it means to build it right, that's always helpful because if not, it can be a foot gun.”

Gzuuus technikai megfigyelése: a klankerek „overfitted with common stacking tech”, vagyis a gyakori vermekbe (felhő, REST, ORM-ek) simulnak bele, viszont ha ritka, élvonalbeli vagy „edged” technológiára (Nostr, Bitcoin, FROST-szerű threshold sig) kérünk építkezést, annál több kontextust és útmutatást kell adni. A fenti idézet egy fontos distinkciót hoz be: a klanker nem kapásból tud szuverén módon építeni, tehát a „force feed” nem opció, hanem kötelező prompt engineering.

Eric egy másik SovEng-vendégre, Mr. Yo-ra utal, aki szintén a „building it right”-ot hangsúlyozta, és így ágyaz meg a szeptemberi SovEng cohort-reklámnak.

A „building it right” etikai dimenziója — Gigi, a Salvage és a hosszú távú felelősség¶

Gzuuus a Salvage (Salvador de Bahia-i, „Madeira”-ként emlegetett) workshopokról beszélve elmagyarázza, hogy Gigi minden cohortot egy bevezető előadással nyit, amely a „build it right” fogalmát és a felelősség dimenzióit tárgyalja. A kulcsmondat:

„he talks about how to build it right, what means to build it right, what is the consequences if you don't build it right. That is basically go to jail. So you have to be conscious about what are the dangers and the risk of building Freedom Tech.”

A konkrét példa: ha egy alkalmazás megőrzi a felhasználók adatait, egy „big stick” (hatóság, peres fél) bármikor bekérheti azt. Ha viszont a rendszert jól építették, és az adat a felhasználónál marad („you don't have that data because your system is you've been the right”), akkor nincs mit kiadni.

Eric kiegészíti ezt a hosszú távú felelősség dimenziójával:

„everybody I've talked to that's been part of this initiative, they don't just think about building it right for the now. They think about building it right for the long term and what are the risks that may not be present in the current implementation... as a project grows in value or maybe value stored or even just, you know, social value, which we'll talk about in a bit here regarding all the communications protocols.”

A „mágikus catch register” koncepció is elhangzik: ha nem tartod az adatot, nem is tudod kiadni — és ez az egyik legegyszerűbb, de leghatékonyabb védekezés a kvázi-jogi nyomás ellen.

A SOC 2 / „SOC Infinity” poén és az adat-takarékosság üzleti előnye¶

A Silicon Valley-ben elterjedt SOC 2 tanúsítvány kontextusában Sync provokatív poént ereszt el:

„if you build a Nostr application correctly, then you should technically be able to get a SOC Infinity certification because you're not even collecting user data in the first place. So it's like, you know, you want to hand me my SOC certification? Like, what ranking do I get? I don't even collect the information.”

Ez a vicc egy mélyebb üzleti érvet is hordoz: a lehető legkevesebb adat gyűjtése nemcsak etikai, hanem kereskedelmi előny is, csökkenti a jogi kockázatot és növeli a felhasználók bizalmát. A „commersz ambíció” Gzuuus szavaival semmiképp sem összeférhetetlen a freedom tech-kel, csak „minden a helyén” kell legyen: ahol nem kell kapzsinak lenni (adatgyűjtés), ott ne légy az.

Gzuuus a Nostr-beli adat-tulajdont a SOC 2 logikájával köti össze:

„the data is owned by the user. It's not owned by you as an entity or in your database. It's not a record in your database that you put there and it belongs to you. And the user signs every payload, every user even is signed. So it belongs to the user. It doesn't belong to you. It's portable as well.”

Ez a tamper-proof, aláírt, hordozható adatmodell az, amitől a Nostr-alkalmazás akár „SOC Infinity” státuszba is kerülhet — bár Gzuuus jelzi, hogy a konkrét tanúsítványi rendszerekhez érdemes hozzáértőbb vendéget hívni.

A relay-ökoszisztéma szervezése, felejtés, negentropy, doxing-paradoxon¶

A beszélgetés egyik legizgalmasabb szakasza a Nostr relay-ek szervezési elveiről szól. A kiindulópont: sokan ingyenes relay-t üzemeltetnek, és elvárják, hogy a jegyzetek határozatlan ideig tárolódjanak, ami „nem fenntartható”. Gzuuus szerint ez rendben van, mert:

„It doesn't matter at the end because the data is yours. The private key is yours. You can transmit that in any way, you know.”

Sync ezt kiegészíti a „felejtés” pozitív olvasatával:

„I think it's sustainable if the network's allowed to forget, right? Like if once in a while relays get nuked and paved and data gets lost... then it will just be forgotten. And I think that's the one thing that Nostr kind of has that prevents this thing from just becoming just a mountain of legacy data.”

Eric a Primal vs. Damus összehasonlítással hoz példát: ha a Primal relay „nuked and paved” lenne, az „drammatikusabb” lenne, mint a Damus esetén, mert a Damus klónjai amúgy is „úszkálnak” a hálózaton. A „negentropy concept”, vagyis a relay-ek egymás közötti szinkronizációja, itt jön be, és a viccesen odavetett megjegyzés a japán relay-ekről („they might even be at the relay in harajuku”) jól mutatja a hálózat globális, de nem koordinált jellegét.

A felejtés organikus metaforája: az emberi memória is így működik, az érzelmileg jelentős dolgokat megőrizzük, a lényegteleneket elfelejtjük. Linus Torvalds-tól származó „100 GB-os filozófia” (ha fontos, másolatot fognak róla készíteni mások) kerül említésre, és a társalgás egyetért abban, hogy a természet-ihlette, szerves felejtés jobb tervezési alapelv lehet, mint a „30-40 év determinisztikus, központi adatbázisainak” tárolási modellje.

A törlés-paradoxon és a kulcs-kompromisszum doxing kockázata¶

A „ha egyszer közzétettem egy privát jegyzetet, hogyan törlöm?” kérdés a Nostr egyik legkényesebb pontja. Gzuuus és Eric egyetértenek, hogy a probléma jelenleg megoldatlan:

„It's a tricky problem because everything is signed and can be replicated. Deletion requests... deletion is something that cannot be proven in computers, right? You can prove that you delete some bytes. And not all relays... on or in nine.”

Eric konkrét fenyegetési modellt vázol fel: ha valaki négy relay-re küld egy törlési kérelmet, és utána kulcs-kompromisszumot szenved, a többi relay-en tárolt jegyzetek (pl. címadatok) „feloldják” a felhasználó doxing-információit. Az efemer kulcsok sem oldják meg teljesen, mert az adat „still floating around somewhere, still on relays to a degree”.

A tanulság: nyilvános relay-eken ne tároljunk érzékeny adatot, és vagy futtassunk saját infrastruktúrát, vagy készítsünk rendszeres mentést.

Közösségi platform-frissítések: Buzz, Hive Talk, Signal¶

A rész utolsó harmadában Sync a közösségi infrastruktúra frissítéseit jelenteti be:

„I've made a buzz community as well for the Open Markets group on our new website I've also made a small banner that links to our community calls... And the last thing is also we have a permanent hive talk room now.”

A Buzz UI-ja Slack/Discord-szerű, ami „structure-álhatóvá” tenné a közösséget, de a frissessége miatt (és mert a Signal-csoport „egy nagy szálként” nehezen strukturálható) a váltás nem egyértelmű. Eric a Buzz egy specifikus relay-implementációját firtatja („why it needed to use a very specific relay implementation or not using the public relays”), és ez a kérdés vezet át a Gzuuus-szal való mélyebb beszélgetésbe, amelynél a rész lezárul.

A „nagy sárgarépát” (big carrot) ígérő jövőbeli „co-host” személye és a Hive Talk szoba részletes használati szabályai a későbbi chunkokra maradnak.

A Nostr app store vita: mitől Nostr-kompatibilis egy app?¶

A blokk a Nostr ökoszisztémában aktuális vitát dolgozza fel: a "Nostr app" címke használata. A kérdés, hogy egy alkalmazás, ami bizonyos Nostr-komponenseket használ, de nem NIP-1-kompatibilis, jogosan viseli-e a "Nostr app" címkét.

"I get a little, I don't want to say frustrated, but I get a little confused when people dress up Nostr apps as like Nostr apps and they're really just things that use Nostr properties but are largely still centralized around your usual database."

Gzuuus és a műsorvezetők egyetértenek: a Nostr nem egy alkalmazás, hanem egy protokoll, és a "Nostr app" címke akkor helyénvaló, ha az alkalmazás a NIP-1 alapján interoperábilis a többi Nostr klienssel. Ha egy alkalmazás csak a Nostr identitás-réteget (npub, pubkey) használja, de a tartalom tárolása és a feed kezelése centralizált, akkor az nem "Nostr app" a szó szoros értelmében.

A NIP-1 jelentősége és az interoperabilitás¶

A NIP-1 a Nostr protokoll alapvető specifikációja, és az interoperabilitás záloga. Gzuuus kifejti, hogy a NIP-1 tisztasága biztosítja, hogy a különböző Nostr kliensek (Damus, Amethyst, Iris, stb.) ugyanazt a feed-et, ugyanazokat a követési listákat és ugyanazokat a note-okat tudják megjeleníteni.

"The other superpower of Nostr is interoperability. In the sense that to achieve that grade of decentralization, you need to have interoperable clients, right? When you start to add specific implementations that just works with these clients and not with these others, or it looks like a gibberish, and so on, you are degrading that."

A NIP-1 támogatása nem kötelező, de a NIP-1 nélküli alkalmazások nem élvezhetik a Nostr interoperabilitási előnyeit. A többi NIP (NIP-05, NIP-17, NIP-42, stb.) vagy új funkciót ad (pl. verifiable address), vagy csökkenti az interoperabilitást (mert egyedi extension-öket vezet be). Ez a trade-off a Nostr fejlesztés természetes része.

A Nostr mint identitás-réteg¶

A blokk egyik legérdekesebb gondolata: a Nostr használható pusztán identitás-rétegként, anélkül, hogy a felhasználó a relay-ekkel vagy a klasszikus NIP-1-gyel közvetlenül interaktálna. A "kind 0" (user metadata) és az npub/pubkey alapú azonosítás önmagában is értékes, és számos alkalmazás építhető erre a minimális használatra.

"You can use Nostr for the identity layer, for example. And you can say that you are still using Nostr, right, but you are not using relays or you are not even using NIP-1. You are using the kind zero of users, so they use the npub or the pub key as an identity layer."

Ez a megközelítés a Nostr ökoszisztémát a "Bitcoin identity" (citrine, ENS, stb.) kontextusba helyezi: a felhasználó egy önálló, cenzúra-ellenálló azonosítóval rendelkezik, és ezt az azonosítót különböző alkalmazásokban használhatja. A "Nostr identity" a jövőben a "Bitcoin identity" egyik formájává válhat.

Gzuuus Bitcoin core-os háttere¶

A blokk kitér Gzuuus Bitcoin-os múltjára is: 2014 óta fejleszt Bitcoin-t, és a Bitcoin core contributorokkal is együtt dolgozott. Ez a háttér adja a súlyát a Gamma Markets specification megírásához, és a műsorvezetők rendszeresen kikérik a véleményét a technikai kérdésekben.

"I have been around Bitcoin since 2014. And I have been, you know, working with the core contributors, and that's something that, you know, is, is very important for me."

A Bitcoin core-os háttér fontos a Gamma Markets kontextusában: a piacok tervezése során a kriptográfiai primitívek (signatures, hash függvények, time locks) és a privacy technikák (CoinJoin, Payjoin, stb.) mély ismerete szükséges, és Gzuuus ezt a tudást hozza a projektbe.

A Nostr app store vita analógiája a Bitcoin ökoszisztémával¶

A Nostr app store vita a Bitcoin-ökoszisztémában is ismert vita: a "Bitcoin app" címke használata is hasonló kérdéseket vet fel. A NIP-1 analógiája a Bitcoin BIP (Bitcoin Improvement Proposal) rendszer, és a "Nostr app" vita a "Bitcoin app" vita Nostr-megfelelője. A műsorvezetők jelzik, hogy ez a téma a jövőben is visszatér majd, és a közösségi konszenzus kialakulása időt vesz igénybe.

Nostr interoperabilitás és „app store” vita¶

Eric és Gzuuus a Nostr „apertúra-metaforáját” járja körül: minden kliensfejlesztőnek meg kell találnia az egyensúlyt a túl széles és a túl szűk NIPimplementáció-készlet között. Ha valaki minden más kliens mozgását figyeli, sosem épít; ha túl szűken implementál, akkor csak egy centralizált, Web2-nél is rosszabb klienst készít. A NIP-1 a kölcsönös átjárhatóság minimumakciója: a profil-metaadatok és a szociális gráf kezelése. A többi NIP (pl. NIP-99, NIP-89) fölötte opcionális, a kliensek közti megállapodás kérdése.

„What I love about Nostr is that the design incentivizes this. It doesn't require, absolutely doesn't require, but incentivizes some level of coordination to benefit from the work done on the rest of the network… and now nostr has it and it's a completely different vector. It's not some cryptocurrency, it's not even a blockchain, it's this social protocol that incentivizes coordination.”

Gzuuus rámutat, hogy ha az interoperabilitást „minden NIP implementálásaként” definiálnánk, akkor csak az Amethyst felelne meg — ez Oxymoron, hiszen vannak NIP-ek, amelyek nem egy kliensbe valók. A megközelítés inkább „organizmus-szerű”: a kliensek egyeztetnek, aztán forkolódnak, és amelyik implementáció technikai érdemei miatt győz, az új fundamentummá válik.

„Hopefully it's on technical merits. And then that becomes a new fundamental again for other people to build upon… a bit like a worm or a centipede — you know, move slowly forward on the protocol spec in a direction that kind of makes consensus sense.”

Eric a „Signal group” analógiával él: különböző képességkészletű kliensek is csatlakozhatnak ugyanahhoz a csoporthoz, de a legkisebb közös nevező határozza meg, mi támogatott — aki nem tud reakciókat, az ne omoljon össze, csak azt a funkciót ne kapja meg.

Gamma Markets eredete: HCC03, Madeira, NIP-99 kiterjesztés¶

A Gamma Markets története a HCC03-nál (Madeira) kezdődött, amikor Gzuuus, Zinc (a későbbi Sync) és Carva (a Calabas/Tradersext) fizikailag összejöttek. A Plebeian eredetileg NIP-15-öt implementált, amelyet Gzuuus „convoluted”-nak ír le, mivel rengeteg különböző kind eseményt kevert. Ezzel párhuzamosan a másik két klienst a NIP-99 egyszerűsége felé vitte — de a NIP-99 „egy Craigslist-szintű listing” volt csupán, e-kereskedelemre erősen alulspecifikált.

„Neat 99 was not satisfying that because it was very simple. So I started to think about how I could improve that and move from NIP-15 that was very convoluted. Then I started to draft specification. I think that was during HCC03.”

Gzuuus a HCC03-ra készített egy draftot, amely a NIP-99-en túl lefedte a checkout-élményt, a NIP-17 alapú kommunikációt, és a piactér-specifikus adatszerkezeteket. A draftot prezentálta Zincnek és Carvának, együtt polish-olták, innen indult a Gamma Markets mint a NIP-99 „extensionje”.

„Both they were disagreeing on different things. And so they weren't interoperable in that sense. Users using Sync's app, users using Calvadev's app, they would not be able to complete a checkout… the only interoperable part was the way to list products.”

Eric felidézi, hogy a Conduit Market és Pub csapata a NIP-15-ös úton elindulva maga is belefutott ugyanazokba a „convoluted” problémákba, amikor Sync „áthívta” őket a NIP-99 / Gamma-vonatra, egy emlékezetes, hajnali hatórás hívás során, ahol Gzuuus specifikációját olvasták. Az SEC-kapcsolat (Stratégiai Ellátási Lánc, itt a csapatmunka-koordináció metaforája) már a genezisnél ott volt: Gzuuus nyíltan hívta meg másokat is a közös munkára.

A Plebeian után: Softinch3, ContextVM (DVMCP), MCP¶

Gzuuus a NIP-99 implementációjának Plebeiannál elkezdett munkája közben hagyta el a csapatot, „egy és valamennyi évvel ezelőtt” –, és átadta a stafétabotot Slausapnak és Chiefnek, akik azóta is viszik a projektet. A távozás felszabadította a „Sovereign Engineering” intenzív, koncentrált ötletelős hétvégék sorozatára, innen jött a Softinch3 koncepció (amely a Plebeian most lassan bevezetésre kerülő aukcióit is inspirálta).

„But it is intense. It's so intense. Yeah, I wish you the best of luck for the next couple of weeks.”

A következő ötlet a ContextVM lett (eredeti neve DBMCP, később DVMCP). Az alapfelismerés: ha az MCP (Model Context Protocol) JSON-RPC az AI-ügynökök és külső szolgáltatások között, és a Nostr amúgy is JSON-alapú vezeték-formátumot használ, akkor a kettő „wire-compatible”, azaz a ContextVM/DVM-kliensek és szerverek Nostr-reléken beszélgethetnek.

„DVMs need a specific kind per job type… what I did in DBMCP at the beginning was unify that and just use one kind. One kind for everything… relays are used as a dump pipe.”

A ContextVM szerverei ContextVM-szerverként felfedve a Nostr kulcs-alapú hitelesítését, a reléket mint felfedezési repozitóriumot, valamint a peer-to-peer authorizációt „azonnal, ingyen” megoldják — miközben az MCP ezeket a kérdéseket még „kutatja”. Ez a felismerés Gzuuus szavaival „két napig nem hagyott aludni”.

„Agents can also discover the same services and use the same tools… I think we are in front of a paradigm shift with all these agents and LLMs… the way we consume applications is going to change — instead of going to an app store, you're going to go to your agent and ask for something.”

A ContextVM bármilyen API-t vagy szolgáltatást tud hosztolni, a képmanipuláción át a termék-lekérdezésig —, és bárki „a hátizsákjában” hordozhatja a szolgáltatását, domain és statikus IP nélkül. A sats-alapú mikro-tranzakciók pedig a „díjazás” természetes mechanizmusát adják.

Marmot és MLS: erős rendezés és a többszörös relé csapdája¶

A White Noise és Marmot projekthez Gzuuus a TypeScript-implementáció (Marmot-TS) korai közreműködőjeként csatlakozott Hazard-del és Jeff-fel. A Marmot mögött az MLS (Messaging Layer Security) protokoll áll, amelyet a Matrix is használ (de nem a Signal, ez utóbbi double ratchet alapú). Az MLS „forward secrecy” és „backward secrecy” tulajdonságait a „rotating client states” biztosítják.

„Imagine that we are three, we are in the same group, and we agree that the secret is A. We add a new member: now the secret is B. We remove them: now it's C. If any member missed a commit, they still believe the secret is C, but we are already in D — they get forked out of the group.”

A probléma: az MLS „nagyon erős rendezést” igényel, mert minden commit sorrendje meghatározza a derivált titkokat. Ha a tagok különböző sorrendben kapják meg a commitokat (mert például Eric a commit-A-t előbb, mások a commit-B-t előbb kapták), akkor „különböző titkokat deriválnak, és kiforkolódnak a csoportból”. A Marmot ezt a többszörös relé fölé próbálta tenni.

„If ordering is the main requisite, a set of relays is a very difficult way to make it work… one relay works as a second of order buffer — but that's not how Nostr works.”

A több relé „fuzzy transport” rétege — különböző uptime-ok, terhelések, késleltetések, üzenetdobások — gyakorlatilag garancia a sorrendvesztésre, különösen 3-4 főnél nagyobb csoportoknál. Még ha elméletileg lehetséges is a hibaarányt mitigálni, „100%-ban sosem fog működni”, és a nyilvános infrastruktúrán tárolt titkosított blobok is hordoznak metaadat-kockázatot (erről szól Gzuuus korábbi cikke, amelyet Eric idéz).

„Marmot and other protocols use relays as a way to store messages in a kind of persistent way. And that itself is a privacy concern… there is a lot of metadata attached.”

CORDN: koordinátor-alapú privát üzenetküldés¶

A CORDN itt jön a képbe. A projekt nem Gzuuus saját „gründolása”: ő csak egy prototípust rakott össze a Sovereign Engineering alatt Yassin „Moon”-nal (a Pika, Marmot-kliens fejlesztőjével), majd egy „Besao” nevű fejlesztő vette át a projektet, és most együtt viszik tovább. A CORDN Marmot / MLS fölött ül, de a kulcsszava: koordinátor.

A koordinátor (1) rendezést biztosít a fuzzy relé-réteg fölött, (2) ContextVM-szerverként fut, (3) mögöttes NAT/firewall mögé is telepíthető, akár böngésző-fülből is, (4) nem igényel domaint vagy statikus IP-t. A split-modell célja a metaadat-tisztítás: a relé csak efemer, titkosított blobokat lát (és a felhasználó IP-jét); a koordinátor viszont nem lát IP-t, csak titkosított blokkokat, és „semmit sem tud kikövetkeztetni”.

„Now with this split model, you have the coordinator that can't truly infer anything. You have the relayer that can't truly infer anything. Maybe they have to be together with the user in order to decrypt and get the whole message content.”

Eric felteszi a „centralizáció?” ellenérvet: nem egy speciális relay-e a koordinátor? Gzuuus válasza, hogy a koordinátor bárki által bárhonnan azonnal indítható — „ha akarom, megnyitok egy böngésző-fület és mondom: gyertek ide beszélgetni”. A csoport túl is éli a koordinátor halálát, mert minden helyben, a klienseken tárolódik.

CORDN multi-device, szuverenitás és piactér-jövőkép¶

A CORDN multi-device megoldása kikerüli az MLS „minden eszköz = külön tag” korlátját: a Blossom segítségével ugyanazokat a titkokat szinkronizálja az eszközök között, így a felhasználó számára „egyetlen szék” marad a csoportban, a UX zökkenőmentes, nincs resync, csak egy QR-kód a másik eszközön.

„Basically you share just one seat on the group. Like there are no different members in the group. They are the same member shared between different devices… you just link the devices at one time and from then everything is going to be synced between devices using Blossom.”

Eric felismeri, hogy a CORDN „service provider” szempontból is „csökkenti a kockázatot”: erősebb ígéretet lehet tenni arra, hogy mit lát és mit nem lát a szolgáltató, a NIP-17-nél „van egy trade-off, egy sor kihívás és adatvédelmi aggály”, a CORDN-nál viszont a forward/backward secrecy out-of-the-box jár.

Gzuuus rámutat a jövőbeli lehetőségekre: a CORDN Nostr eseményeket használ envelope-ként, így a reakciók, reply-k és hosszú formátumú tartalom mellett NIP-99 termékek is beágyazhatók a csoporton belül, piactérfunkciók (privát vásárlási feedek, kizárólag csoporttagoknak szánt termékek) a CORDN privát kontextusában.

„Nothing stops us to implement NIP-99 inside of CORDN and you'll be able to create products inside of a group… have your own community there publishing and buying things in the private context of that group.”

A záró gondolat a szuverenitás: ha a felhasználó a nyilvános relékre bízza az adatait, akkor azokat az üzemeltető bármikor „törölheti” — az nem szuverenitás, csak függés. Aki saját koordinátort fut, azé az adat, és „senki nem törölheti, csak ő”. Eric szavaival „ez a vita megérdemel egy folytatást”, és bátorítja a hallgatókat, hogy próbálják ki a CORDN-t, kérdőjelezzék meg az állításokat, és „a napfény a legjobb módja annak, hogy jobb fundamentális technológiát építsünk”.

„If you run your own coordinator, you are the owner of that — no one can delete that aside from you.”

A beszélgetés a podcast szokásos lezárásával zárul: iratkozz fel az Open Markets-re, kövess minket Nostron vagy openmarkets.pub-on, „Maradjunk kezelhetetlenek” — az „Ungovernable” szellemiség jegyében.

Forrás¶

Episode page: https://fountain.fm/episode/c1k9LTKA5Q8vFSvNuzqt
Media file: https://feeds.fountain.fm/iKaquCnTj0q5Bg2VfGRD/items/3d9EzQWjZLsHGCF1eBRa/files/AUDIO---DEFAULT---eb605236-55ec-48a8-9079-8a3c59a99bd4.mp3
Transcript forrás: Fountain.fm SRT endpoint (VIDEO---TRANSCRIPT---DEFAULT---SRT.srt), 0 hallucination, emberi készítésű
Chapter JSON: 8 chapter, 8405 sec
Topic: bitcoin-ecosystem.md (új, Open Markets ökoszisztéma), nostr-protocol.md (NIP vita)

Megjegyzések a feldolgozáshoz¶

Vendég-név eltérés: a feed-title-ben nincs explicit, a transcriptben "Gzuuus" (nickname), ez a kanonikus, mert a SRT emberi. A valódi név a transcriptben nem hangzik el explicit, a "Mr. Gzuuus" megszólítás maradt.
Chapter-cím vs tartalom eltérés: a 3. chapter ("Bitcoin security incidents", 8:36-16:58) valójában a BTCPay node kompromittálásokról szól, de a transcriptben a "phishing / address / lost" kulcsszavak dominálnak. A 4. chapter ("Nostr and social media evolution") a Nostr közösségi feszültségről + a Calvadev cikkről szól.
Anti-style postprocess: a 32+ em-dash a chunk-summary-kból származik; a H2 címekben lévő em-dash-ok (pl. "A „building it right” etikai dimenziója. Gigi") a posztprocesszálás után megmaradnak, mert a humanizer skill kíméli a H2 címeket (lásd humanizer-integration.md). A szabad szövegben lévő em-dash-ok (chunk3: 16, chunk5: 26) csökkentve, de idézet-blockquote-ok sértetlenek.