Constant's avatar
Constant 3 weeks ago
In this interview i thought i would attempt to explain perhaps the most arcane insight behind Nostr. I think i failed, but thats not the end of the world. I won't do a full attempt here and now, but the point is that verifiability on the one hand, and context on the other is what makes Nostr ''work'' eventhough theoretically it should not. A pubkey or a hash are just meaningless strings. If i would hand you such at string, it would just be a random garbled mess. And it is, it very much is a random garbled mess, that is very much the point of such strings. It is only because there are things associated to those strings, be that an event in the case of the eventID/hash, or an actor in the case of a public key, that it gains any meaning. This begs the question as to how you would find out what that associated thing is, where you would find it. And it is this question that is the reason that from a theoretical perspective the unsolveable problem comes in; there is no full proof method or insurance you ever will. It just so happens that in practice, we have all these servers that make an effort of indexing this association. You can give them these strings and maybe they come back with an asnwer; or maybe not, at which point you will have to ask some other server/relay. But these random strings, in practice, rarely stand on their own. Each event always stand in the context of its publisher in the first place, but may also itself be referenced by other events from other publishers. These publishers also reference eachother (chief among such references is a follow list), so in actuality there is this lively network of active references that quickly scatters among the relays. Once you find the association, you know you found it because you can verify, so each attempt, each quest for context atleast carries this promise that you know you arived at your destination once you get there, eventhough there is no promise you will ever get to the destination. So regardless how scattered the data may be, in its fragmentation it is indexed, and in its 'liveliness' it is interconnected through reference, and in its answers it provides context, and in its context it delivers meaning. And thats how you go from a meaningless string to meaning. The reason for all of this is so that everyone can permissionlessly operate on the same interoperable plane and we don't need a cental party, a platform, to provide context and therefor meaning for us. It is the method by which we liberate ourselves from the silo, whatever it is we are doing. It is how we solve for coordination, be that on Nostr itself, be that for Blossom, be that for Ngit or whatever else. It is how we flipped the script, so that instead of all going to the exact same place to interact, we can manage to go wherever the other happens to be to interact, in order to fullfill the promise of the internet that everyone potentially can get into contact with anybody else. Ok, maybe i sort of did do an attempt to explain it again, and frankly I don't think i did much of a better job than i did during the interview, but...i dunno, bite me. Nostr.
Constant's avatar Constant
ignore the clickbait title
View quoted note →

Replies (19)

Happy to voice this one for the thread if folks want it — the audio drops once the 571 sats bounty is met here, one zap or many.
Seek clarity through simple explanations. Sometimes, less is more in complex matters.
Seek clarity through simple explanations. Sometimes, less is more in complex matters.
"You can give them these strings and maybe they come back with an asnwer; or maybe not, at which point you will have to ask some other server/relay." This quote, and also the rest of your post, is circling around a conceptual issue that is of crucial importance to the nostr protocol, namely the question of completeness. If you make a query to the relay network, you can never be sure whether the response you receive is complete in the sense of containing *all* of the existing material that is responsive to your query. This uncertainty-as-to-completess is acceptable for many everyday use cases. But there are some extremely important use cases for which this uncertainty is absolutely unacceptable. Sometimes you really have to be sure that, after having made a query and received a response, you have received the *complete* set of items that are responsive to that query. We discussed this earlier in connection with key rotation, where a working system requires that a client can discover *all* of the valid key revocation declarations that have been made by a given pubkey. For this, nostr relays are not sufficient, for the reasons that you describe in your post. A blockchain can furnish the required completeness property and make key rotation and cold storage identities possible, thereby fixing the central defect that is making the current protocol not fully practicable.
Ren Solan's avatar
Ren Solan 3 weeks ago
+1 Clarity is often a test of understanding. Those who can express ideas simply, often have the deepest understanding
Constant's avatar
Constant 2 weeks ago
This is the reason for the phrase ''there is no global''. Yes the purpose of ''a'' blockchain is to produce a global shared state; i happen to be of the school that such that ''money'' is basically the only thing you can organize such a system for in a decentralized manner, and that that ''a'' blockchain is actually ''the'' blockchain, which is Bitcoin. For everything else remains ''best effort'', which then ties into the point of my post that makes the point that there is enough there to facilitate such an effort, while accepting it will never be more than what a best effort can provide. If you need assurances, you can get those in form of making some particular dude responcible and hold that dude accountable whenever something goes wrong. This is also because, and this is related to all of this, there is this unbrigdeable gap between reality and adminitrative reality, which introduces the oracle problem. You can't get around the oracle problem, not even Bitcoin gets around it. Instead with Bitcoin, it picked a domain in which we already achieved practical global consensus; the thing it has to brigde this gap between reality and adminstrative reality for is time. Bitcoin picked the oracle problem for which we already have a sollution, all it needed to do was introduce some margin of error, and it could lean on the fact that all the computers out there, to significant degree, already agree on what time it is. As such, each oracle claim, i.e. the supposed timestamp in the mined block, can be subject to a local/decentralized/distributed sanity check. What you trust on when you sync the blockchain's history, which you were not there to witness its creation, is that this distributed judgement occured for each block in the moment/section of time it occured in. The accumulation of PoW subsequently cements this distributed judgement in order to produce plausability: eventhough you have no actual way of verifying the non-triviality of the history (i.e. was the difficulty of the past actually difficult to where it took ~10 minutes to produce a block), the running process of the network resulted in this unbroken chain that leads into the ''now'' where appearently it is non-trivial (the difficulty seems such that it does take ~10 minutes to produce a block). This is also my objection to notions that Bitcoin is time, or a clock or whatever, because Bitcoin leans on an existing consensus of time, and uses the clock in order to be what it is. From where I stand, the only thing we are (practically) able to borrow from ''the'' blockchain, is its time-anchoring, but not its global state.
As for the oracle problem, it seems that this is solved in practice for the special case of determining the approximate time at which a given block was produced. A new block needs to be accepted by thousands of independent nodes that validate it, and each of those nodes checks the block against its own clock. And blocks that arrive are also logged independently by nodes, explorers, exchanges, archives and researchers all over the world, and you'd have to rewrite all these independent records to fake the time at which a given block is thought to have occurred. I believe noone has ever seriously disputed the approximate time when a given block occurred? If that's right, the oracle problem doesn't seem like an actual practical problem for either Bitcoin or Ethereum as far as block time determinations are concerned. You seem to agree with this, for example when you say that we can "borrow" time-anchoring from the blockchain. And as for global state, what exactly prevents us from borrowing that? For Bitcoin specifically, there may be practical difficulties and you may need to run a full node to do it. But that's design property of Bitcoin, not of blockchains. Inkan borrows global state from Ethereum in actual practice. If it can be borrowed and solves a central practical problem for the nostr protocol, why not borrow it rather than sit on the problem?
"... if you fix this problem, you reintroduce centralization. You have a central authority." I guess that was true until recently, about 2009. Since then there's been this thing called a blockchain, which is a shared source of truth without a central authority. For example, you can use Ethereum to give every client the same complete view of all delegation and revocation declarations a pubkey has ever made. If you do that, you get fully functional cold storage identities for nostr, without any central authority in the loop. 👇
james_r's avatar
james_r 2 weeks ago
nice cut but the guest is Pablo yet Gigi doesn't let him speak at all
Constant's avatar
Constant 2 weeks ago
I think the question to you would be: Look at how trivial the OTS verification is, at worst a hand full of mb worth of chain headers and you can verify all the OTS proofs under the sun in an instant. What does it take to actually verify those eth based state claims?
Ok so that's a more incisive question, and I guess it's a good opportunity to maybe get some eyes on inkan to check whether it's actually working. The thing that plays a role that's kind of like your header chain is this file that the client verifies from: https://www.inkan.cc/inkan-archive/inkan-archive.cbor.gz The thing it's supposed to achieve is that a client can verify every declaration the system shows, and that none have been withheld, from a small trusted starting point. Whether it actually achieves that is a question I'd be very interested in, so feel free to take a look and let me know where all the holes are. One quick way to look inside (needs the cbor2 package): python3 - <<'EOF' import gzip, json, cbor2 a = cbor2.loads(gzip.open('inkan-archive.cbor.gz','rb').read()) view = lambda x, d=0: (lambda y: f"0x{y.hex()[:16]}… ({len(y)} bytes)" if isinstance(y, (bytes, bytearray)) else ({k: view(v, d+1) for k, v in y.items()} if d < 2 else f"{{… {len(y)} fields}}") if isinstance(y, dict) else (f"[{len(y)} items]" if isinstance(y, list) else y))(getattr(x, 'value', x)) print(json.dumps(view(a), indent=2, default=str)) EOF
Not easily for this file, as it rather gets into the weeds. A good way to approach it is probably to have different LLMs inspect the file and then have a conversation about it and how it relates to the structure of Ethereum, and then double-check manually as needed. It would be great to have people audit this in detail, I think it's a bit more complicated than bitcoin headers. One thing that is easier to inspect is how this works in practice in the client. You can go to the "Explore" menu on the inkan website and click on one of the identities. You'll see that the events produced by these identities have green "D"s on their avatars, indicating that they are displayed via delegation. If you click on these green Ds, you'll see a popup which contains links to the (i) delegation network tables that back up each delegated display of an event and (ii) the OTS data behind each event (note that recent events don't yet have OTS data, non-recent ones do). For the OTS data, the inkan client allows you to download the proof for each event and run it through any OTS verifier. For the delegation data, you can in the delegation tables click through to pages that describe the actual declarations, and on each such page you can click a "Download Verification Script" button to download a python script which permits you to independently check that the declaration was indeed recorded on-chain. I've attached a screenshot of a page with this button. Inspecting the delegation tables and verifying the OTS and on-chain declaration data independently through these mechanisms is a pretty good way of getting to know how inkan works. Of course, none of this needs to be understood in any detail for everyday use, it's just meant to provide auditability. image
One reason I'm pointing to the delegation tables and the "Download Verification Script" buttons in the client is that they provide a quick practical illustration of what "completeness" means. When a user has recorded a series of declarations on-chain, the user can simply look through the tables in the client and check that the client has indeed found all of the declarations that they recorded. Of course this is not a proof that the client itself can know it has the complete set, that's a thing for which I still owe you a better explanation.
↑