# BEF-P11 - DECENTRALIZED TECHNOLOGY & NOSTR INFRASTRUCTURE PROTOCOL > Balanced Exchange Framework (BEF) - Framework Version 1.0, 2026-08-22. > Source of record: https://balancedexchangeframe.work/doc/p11 ``` Protocol ID: BEF-P11 | Framework Version: 1.0 | Architecture: SHARED > TECHNOLOGY > NOSTR ``` ### 1. Namen BEF-P11 določa tehnološko in podatkovno arhitekturo, s katero BEF ločuje lastništvo kripto-sredstva, identiteto, podpisovanje dogodkov, shranjevanje podatkov in uporabniške aplikacije. Njegov namen je zagotoviti preverljivost, prenosljivost podatkov, odpornost na odpoved posamezne aplikacije ter jasno razmejitev med decentraliziranim transportom podatkov in funkcijami, pri katerih posamezni KIND zahteva določenega pooblaščenega podpisnika. ### 2. Tri infrastrukturne plasti BEF uporablja tri osnovne infrastrukturne plasti: - LAYER I - LanaCoin Blockchain: asset in transakcijski sloj. - LAYER II - Lana Nostr: identitetni, event, komunikacijski in podatkovni sloj. - LAYER III - Digital Beings: inteligentni sloj. Njegov namen, avtonomija, odgovornost, denarnice in governance pravila so določeni v BEF-P12. ### 3. LanaCoin Blockchain LANA je osnovni crypto-asset na lastnem LanaCoin blockchainu. Blockchain predstavlja neodvisni zapis prenosa LANA in je ločen od aplikacijskega podatkovnega sloja Nostr. BEF ne obravnava Nostr eventa kot nadomestilo za blockchain transakcijo takrat, ko je za določen dogodek potreben dejanski on-chain prenos. Nostr lahko beleži namen, stanje, potrditev ali povezavo do blockchain transakcije, medtem ko lastništvo in prenos osnovnega crypto-asseta dokazujeta pravila LanaCoin blockchaina. ### 4. Lana Nostr Lana Nostr predstavlja distribuirani event in podatkovni sloj ekosistema. Poslovni, registrski, governance, komunikacijski, skupnostni in številni drugi dogodki so modelirani kot Nostr KIND-i in objavljeni na relay infrastrukturo skladno s pravili posameznega KIND-a. Javna protokolna dokumentacija je objavljena na LanaNostr.site. Kanonični strojno berljivi seznam je kinds.json. Ob pregledu za to verzijo je bil kinds.json označen kot verzija 2.42.0, posodobljen 12. avgusta 2026. Human-readable dokumentacija je pomoč pri razumevanju; ob neskladju ima za tehnično implementacijo prednost veljavna specifikacija kinds.json. ### 5. Kriptografska struktura Nostr dogodka Po NIP-01 vsak Nostr event vključuje najmanj event ID, public key avtorja, created_at, kind, tags, content in kriptografski podpis. Event ID se izpelje s SHA-256 iz kanonično serializiranih podatkov dogodka, podpis pa uporablja Schnorr podpisovanje na krivulji secp256k1. Ta struktura omogoča preverjanje integritete dogodka in kriptografskega avtorstva: sprememba podpisanih podatkov spremeni event ID oziroma povzroči neuspešno preverjanje podpisa. Kriptografski podpis dokazuje nadzor nad zasebnim ključem, ne pa sam po sebi pravne identitete človeka. BEF prav zato povezuje Nostr public key z registriranim udeležencem prek identitetnih in registrarskih evidenc. ### 6. Main Wallet in identiteta udeleženca Vsak udeleženec ob vključitvi v Lana okolje pridobi oziroma registrira prvo glavno denarnico - Main Wallet. Main Wallet je prva Registered Wallet in predstavlja primarno točko povezave med udeležencem in njegovo BEF identiteto. Poleg LanaCoin wallet naslova BEF uporablja Nostr HEX public key kot kriptografski identifikator avtorja Nostr dogodkov. Način tehnične povezave oziroma derivacije med uporabniškim ključnim materialom, Main Wallet in Nostr identiteto mora biti dokumentiran v implementacijski specifikaciji in ne sme biti prepuščen nevidni strežniški interpretaciji. ### 7. Private-key načelo Zasebni ključ je uporabnikovo podpisno sredstvo. BEF aplikacije ne smejo trajno hraniti uporabnikovega zasebnega ključa na centralnem strežniku samo zato, da bi izvajale prijavo ali podpisovanje v njegovem imenu. Prijava oziroma dejanje uporabnika se, kjer je tako implementirano, preveri s kriptografskim dokazom nadzora nad ključem. Sistem iz podpisa oziroma izpeljanega public keya preveri identiteto, ne da bi moral ustvariti centralno zbirko uporabniških zasebnih ključev. Če posamezna aplikacija uporablja drugačen signing model, delegated signer ali secure signer, mora biti to posebej dokumentirano. Noben protokol ne sme ustvarjati vtisa, da je event self-signed by user, če ga je dejansko podpisal platformni, facilitatorjev ali Being key. ### 8. Nostr HEX ID in dokaz avtorstva Nostr HEX ID oziroma 64-znakovni public key je ključni tehnični identifikator avtorja dogodka. V kombinaciji z veljavnim podpisom omogoča preverjanje, kateri keypair je dogodek ustvaril. Kadar Registrar poveže ta public key z registriranim udeležencem, lahko aplikacije razlikujejo med kriptografskim avtorjem dogodka in registrirano identiteto, ki je s tem public keyem povezana. Ta razmejitev je pomembna za regulatorno in dokazno jasnost. ### 9. Relay-first podatkovni model BEF uporablja Nostr relaye kot trajni oziroma kanonični podatkovni sloj za dogodke, za katere posamezni KIND določa relay objavo. Aplikacije lahko uporabljajo SQL, lokalne baze, indekse ali cache zaradi hitrosti, iskanja in zmanjšanja obremenitve relayev. Takšna lokalna baza je praviloma izvedeni oziroma začasni pogled na podatke. Če se njena vsebina razlikuje od veljavnega relay dogodka in protokol ne določa drugače, mora aplikacija stanje ponovno izpeljati iz preverljivih dogodkov. To omogoča, da posamezen portal ni edina točka resnice in da lahko neodvisna implementacija ponovno zgradi stanje iz eventov. ### 10. Official relay discovery Veljavni uradni relay endpointi se ne smejo trdo kodirati kot nespremenljivo pravilo Frameworka. Lana System Parameters, KIND 38888, predstavlja konfiguracijski vir za uradne relaye in druge sistemske parametre. Aplikacija mora preveriti veljavnega avtorja KIND 38888 ter aktualno konfiguracijo. V času pregleda je javna dokumentacija navajala relaye relay.lanavault.space, relay.lanacoin-eternity.com in relay.lanaheartvoice.com. Ta navedba je snapshot in ne nadomešča aktualnega KIND 38888. ### 11. Javni podatki in šifrirani podatki Načelo transparentnosti ne pomeni, da je vsebina vsakega eventa nujno plaintext. Nostr relay lahko hrani javno dostopen podpisan event, katerega content je po pravilih posameznega KIND-a šifriran. Primeri v trenutni specifikaciji vključujejo šifrirane Direct Messages in dele OWN procesa. Zato BEF razlikuje med javno preverljivim obstojem oziroma metapodatki dogodka ter dejansko berljivostjo njegove vsebine. Posamezni KIND mora jasno določiti, ali je content public plaintext, encrypted, ephemeral ali drugače omejen. ### 12. Replaceability in zgodovina Nostr KIND-i nimajo vsi enakega življenjskega cikla. BEF uporablja regular non-replaceable evente za nespremenljivo zgodovino, replaceable oziroma addressable evente za trenutno stanje in v nekaterih primerih ephemeral evente za kratkotrajno avtentikacijo ali komunikacijo. Za regulatorni audit mora biti pri vsakem materialnem KIND-u jasno, ali predstavlja trenutno stanje ali zgodovinski dokaz. Aplikacija ne sme združevati preteklih replaceable verzij na način, ki bi ponovno aktiviral odstranjeno stanje. ### 13. Decentralizacija in authority boundaries Decentralizacija podatkovnega transporta ne pomeni, da lahko vsak public key veljavno objavi vsak sistemski dogodek. Nekateri KIND-i so self-signed s strani uporabnika, drugi so veljavni samo od Registrarja, facilitatorja, Business Unit ownerja, Being-a, News Authority, Circle Authority ali druge v protokolu določene funkcije. BEF zato uporablja princip explicit authority boundary: client mora preveriti podpis in hkrati preveriti, ali je avtor po pravilih konkretnega KIND-a pooblaščen za tak dogodek. To je pomembna razlika med decentralizirano infrastrukturo in neomejeno avtoriteto. Podatki so lahko distribuirani, pravica ustvariti veljavno stanje pa je lahko protokolarno omejena. ### 14. Neodvisna infrastruktura in interoperabilnost Ker so event sheme in relay dostop javno dokumentirani, lahko neodvisni razvijalec zgradi lasten reader, indexer, dashboard ali drugo združljivo infrastrukturo ter preverja podpise in dogodke brez dostopa do interne SQL baze posameznega portala. Neodvisna implementacija mora kljub temu spoštovati veljavne authorisation, replaceability, encryption in validation rules posameznega KIND-a. Samo to, da je event mogoče prenesti z relaya, še ne pomeni, da ga je treba sprejeti kot veljaven sistemski event. ### 15. Regulatorna dokazljivost Za regulatorja Nostr layer omogoča ločitev med trditvijo sistema in preverljivim zapisom. Kjer je materialni dogodek podpisan in objavljen skladno s protokolom, je mogoče preveriti njegov event ID, podpis, avtorja, timestamp, vrsto KIND-a in reference na druge dogodke oziroma blockchain transakcije. BEF-P09 določa splošna evidence pravila, BEF-P11 pa določa tehnološki mehanizem, na katerem takšna dokazljivost temelji. ### 16. Security & key management Zasebni ključi so varnostno kritični. Izguba ali kompromitacija ključa lahko vpliva na sposobnost podpisovanja ali na zanesljivost identitete. BEF zato ločuje uporabo ključev, javnih identifikatorjev, service-authority keyev in uporabniških keyev ter zahteva, da aplikacije ne predstavljajo platformno podpisanega eventa kot uporabniško podpisanega. KIND 56757 omogoča javno izjavo o izgubi dostopa do wallet private keya. Dodatna pravila za recovery, key rotation in credential lifecycle se lahko določijo v prihodnji tehnični verziji. ### 17. Data protection Decentralizirana oziroma javna relay arhitektura ne odpravlja pravil varstva osebnih podatkov. Pred objavo osebnih podatkov mora posamezni protocol določiti, kateri podatki so potrebni, kateri so javni, kateri šifrirani in kateri morajo ostati lokalni. Posebej pri podatkih o osebah in procesih mora BEF uporabljati minimizacijo podatkov. Če je mogoče javno dokazati stanje z abstraktnim oziroma psevdonimiziranim zapisom, se ne objavlja več podatkov samo zato, ker tehnologija to omogoča. ### 18. LanaNostr.site kot protocol registry LanaNostr.site je javna tehnična dokumentacija Nostr protokolov Lana ekosistema. kinds.json je strojno berljiv registry in mora biti za implementacijo obravnavan kot dinamičen protokolni vir, ne kot statična priloga tega PDF-ja. Ta Framework zato v Annex E vsebuje human-readable snapshot KIND družin, medtem ko popolno in aktualno shemo, required tags, validation rules, publisher rules, replaceability in primere določa veljavni kinds.json. ### 19. Interface with Digital Beings Tretja infrastrukturna plast so Digital Beings. Lana Nostr specifikacija vsebuje več KIND družin za Being memory, awareness, Being KYC, Being Commons, Agent Rooms in druge funkcije. P11 evidentira in ureja njihovo tehnično povezavo z event in relay infrastrukturo; njihov namen, participativni status, avtonomija, odgovornost, denarnice in governance pravila so podrobno določeni v BEF-P12 - Digital Beings & Symbiotic Intelligence Protocol.