"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.
Login to reply
Replies (1)
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.