chore: improve README

Author: dpc

README.design.md

@@ -0,0 +1,37 @@
+# BFTE design
+
+*Some of these might make more sense if you already understand Fedimint*.
+
+In BFTE consensus is a central primitive, and near *everything* is part of the consensus history.
+
+Adding and removing peers, changes to configuration like adding new modules
+(applications), software upgrades, etc. are all implemented by consensus items agreed on
+and published on a shared ledger.
+
+Replicating, but not participating nodes are a first class primitive.
+Anyone can run an additional consensus history replicating node, without necessarily participating
+in consensus building.
+
+A simple consensus algorithm (Simplex) is used to perfectly match
+the needs of BFTE.
+
+Simplicity is achieved through interactions between few well
+thought general purpose pritmivites.
+
+Trying to avoid non-consensus APIs and state.
+
+Maintaining additional APIs, and client side state machines is just duplicating effort.
+The mutable part of the consensus state is typically small anyway and
+"clients" might maybe throw away the bulk data that they don't need anyway,
+as they not validate the consensus.
+
+Things like DKGs can just happen as a part of consensus. Mint module should support
+multiple keysets, and generating new ones on demand.
+
+Consensus items should be just module specific inputs/outputs, signed by the
+node itself. This allows things like conditional consensus items.
+
+Effect system as the only means of inter-module interactions. Modules processing consensus
+items can produce typed and serialized "effects", which other modules that happen to understand
+can act on.
+

README.md

@@ -3,7 +3,7 @@
 BTFE is a BFT consensus engine. A permissioned p2p blockchain to
 drive BFT applications in federated setup, including financial (Bitcoin) domains.
 
-### BFTE vs Fedimint
+## Introduction
 
 It's fair to say BFTE in its current form is a research on alternative
 implementation of a Fedimint-like system, and this project aims at the very similar *very-long*
@@ -42,43 +42,13 @@ compatibility etc.
 By ignoring all these ambitions, BFTE can focus first on honing the primary
 goal: becoming good general purpose modular consensus engine.
 
-### Design (Ideas):
+## Links
 
-*Some of these might make more sense if you already understand Fedimint*.
+* [BFTE Radicle site](https://app.radicle.xyz/nodes/radicle.dpc.pw/rad:zii8qFzZhN3vigh8BuxGCuEEp6z4) - BFTE uses [Radicle][radicle]  as primary distributed code collaboration platform.
+* [BFTE design document](./README.design.md)
 
-In BFTE consensus is a central primitive, and near *everything* is part of the consensus history.
+[radicle]: https://radicle.xyz
 
-Adding and removing peers, changes to configuration like adding new modules
-(applications), software upgrades, etc. are all implemented by consensus items agreed on
-and published on a shared ledger.
-
-Replicating, but not participating nodes are a first class primitive.
-Anyone can run an additional consensus history replicating node, without necessarily participating
-in consensus building.
-
-A simple consensus algorithm (Simplex) is used to perfectly match
-the needs of BFTE.
-
-Simplicity is achieved through interactions between few well
-thought general purpose pritmivites.
-
-Trying to avoid non-consensus APIs and state.
-
-Maintaining additional APIs, and client side state machines is just duplicating effort.
-The mutable part of the consensus state is typically small anyway and
-"clients" might maybe throw away the bulk data that they don't need anyway,
-as they not validate the consensus.
-
-Things like DKGs can just happen as a part of consensus. Mint module should support
-multiple keysets, and generating new ones on demand.
-
-Consensus items should be just module specific inputs/outputs, signed by the
-node itself. This allows things like conditional consensus items.
-
-Effect system as the only means of inter-module interactions. Modules processing consensus
-items can produce typed and serialized "effects", which other modules that happen to understand
-can act on.
-
-### License
+## License
 
 MPLE is licensed under MIT.