Removed the blockchain ambitions from the README.

README.md

@@ -1,12 +1,16 @@
 # BFT-CRDT PoC
 
-This is a proof of concept implementation of a [BFT-CRDT](https://jzhao.xyz/posts/bft-json-crdt) blockchain-like system. It is willfully, wildly insecure as a blockchain right now. Think of it as an experiment which is strictly for fun and poking at ideas.
+This is a proof of concept implementation of a [BFT-CRDT](https://jzhao.xyz/posts/bft-json-crdt) system.
 
 This code is based on the ideas of [Martin Kleppmann](https://martin.kleppmann.com/papers/bft-crdt-papoc22.pdf) and the ideas and code of [Jacky Zhao](https://jzhao.xyz/). Have a read, they are both excellent writers and have some of the most interesting computing ideas I've run across in quite a while.
 
 It is not clear what this thing is for, yet. It's not a blockchain. It makes a kind of secure DAG. It uses BFT-CRDTs to make a Sybil-proof and secure information transmission system for messages, with eventual consistency guarantees.
 
-The idea that it could be possible to set up a secure Sybil-proof system, negating the energy burn required for proof of work, the financially exclusionary proof of stake, or the meat space hassle of a proof of personhood ceremony, is too attractive to ignore. At least, if you're interested in cool P2P systems.
+Initially I was thinking it could perhaps be used to make a kind of opt-in blockchain, but I don't think it'll work (and reading up on things like e.g. vector clocks, which I had initially thought about for ordering, the literature goes out of its way to note that they can't work in Byzantine environments).
+
+So if it can't be a blockchain, what can it be? Is it useful at all?
+
+Potentially, yes. There are lots of things in crypto land which do not necessarily need consensus and/or a Total Global Ordering. Some brainstormed ideas for these are in the `docs/` folder.
 
 ## Prerequisites
 
@@ -45,6 +49,10 @@ You can then type directly into each of the Crdt Node consoles. Messages will be
 
 What we have here is a very simple system comprised of two parts: the Crdt Node, and the Crdt Relayer.
 
+It is pretty cool in the sense that it is actually Sybil-proof. But you can't get a Total Global Ordering out of it, so you can't use it for e.g. account transfers in a blockchain.
+
+However, there may be other cases that
+
 ### Crdt Node(s)
 
 The Crdt Nodes make up a system of BFT-CRDT-producing nodes that can make a sort of wildly insecure blockchain. Currently, they can reliably send transactions to each other in a secure way, such that all nodes they communicate with can tell whether received transactions are obeying the rules of the system.
@@ -53,9 +61,9 @@ The Crdt Node does not download any chain state, and if one goes off-line it wil
 
 ### Crdt Relayer
 
-The Crdt Relayer replicates transactions between nodes using a websocket. We aim to eliminate this component from the architecture, but for the moment it simplifies networking and consensus agreement while we experiment with higher-value concepts.
+The Crdt Relayer replicates transactions between nodes using a websocket. We aim to eliminate this component from the architecture, but for the moment it simplifies networking while we experiment with higher-value concepts.
 
-Later, we will aim to remove the Crdt Relayer from the architecture, by (a) moving to pure P2P transactions between Crdt Nodes, and (b) doing leader election of a Crdt Node to reach agreement on the submitted block.
+Later, we will aim to remove the Crdt Relayer from the architecture, by (a) moving to pure P2P transactions between Crdt Nodes
 
 ## Possible uses
 
@@ -69,15 +77,13 @@ It is not necessarily the case that e.g. signer participants and Cosmos validato
 
 Might the ability to be part of multiple consensus groups at once provide new opportunities for cross-chain transfers?
 
+### Others
+
+There are some brainstormed ideas in `docs/` and `examples/` as well as an ai-generated example in `crates/oracle-demo`. Have a look.
+
 ## Next dev tasks:
 
-- [ ] we don't need a relayer, the first crdt node can act as a leader until people decide they don't want to trust it any more
-- [ ] the leader node can have a timer in it for block creation
-- [ ] code up the ability to switch leaders (can be a human decision at first, later an (optional) automated choice)
 - [ ] pick a commit and reveal scheme to remove MEV. One thing to investigate is [single-use seals](https://docs.rgb.info/distributed-computing-concepts/single-use-seals)
-- [ ] enable Crdt Nodes should download current P2P chain/dag state so that they start - out with a consistent copy of transaction data, and also do catch-up after going off-line
+- [ ] enable Crdt Nodes should download current P2P dag state so that they start out with a consistent copy of dag data, and also do catch-up after going off-line
 - [ ] remove the proc macro code from bft-json-crdt, it's not really needed in this implementation
-- [ ] add smart contract execution engine (CosmWasm would be a good first choice)
-- [ ] enable Crdt Nodes to download contract code for a given contract
-- [ ] enable Crdt Nodes to download current contract state for a given contract
 - [ ] switch to full P2P messaging instead of websockets