Restyled by prettier-markdown

README.md

@@ -17,8 +17,9 @@ The purpose of this branch - as the name suggests - is to introduce `no_std` com
 
 We have been successful in this endeavour. The library now only requires Rust `core` and runs on e.g. ESP32 baremental Rust targets.
 When `matter-rs` is used on targets that do not support the Rust Standard Library, user is expected to provide the following:
+
 - A `rand` function that can fill a `&[u8]` slice with random data
-- An `epoch` function (a "current time" utility); note that since this utility is only used for measuring timeouts, it is OK to provide a function that e.g. measures elapsed millis since system boot, rather than something that tries to adhere to the UNIX epoch (1/1/1970)  
+- An `epoch` function (a "current time" utility); note that since this utility is only used for measuring timeouts, it is OK to provide a function that e.g. measures elapsed millis since system boot, rather than something that tries to adhere to the UNIX epoch (1/1/1970)
 - An MCU-specific UDP stack that the user would need to connect to the `matter-rs` library
 
 Besides just having `no_std` compatibility, the `no_std` branch does not need an allocator. I.e. all structures internal to the `matter-rs` librarty are statically allocated.
@@ -28,12 +29,13 @@ Last but not least, the `no_std` branch by itself does **not** do any IO. In oth
 ### [sequential](https://github.com/project-chip/matter-rs/tree/sequential)
 
 The `sequential` branch builds on top of the work implemented in the `no_std` branch by utilizing code implemented as `async` functions and methods. Committing to `async` has multiple benefits:
-* (Internal for the library) We were able to turn several explicit state machines into implicit ones (after all, `async` is primarily about generating state machines automatically based on "sequential" user codee that uses the async/await language constructs - hence the name of the branch)
-* (External, for the user) The ergonomics of the Exchange API in this branch (in other words, the "transport aspect of the Matter CSA spec) is much better, approaching that of dealing with regular TCP/IP sockets in the Rust Standard Library. This is only possible by utilizing async functions and methods, because - let's not forget - `matter-rs` needs to run on MCUs where native threading and task scheduling capabilities might not even exist, hence "sequentially-looking" request/response interaction can only be expressed asynchronously, or with explicit state machines.
-* Certain pending concepts are much easier to implement via async functions and methods:
- * Re-sending packets which were not acknowledged by the receiver yet (the MRP protocol as per the Matter spec)
- * The "initiator" side of an exchange (think client clusters)
-* This branch provides facilities to implement asynchronous read, write and invoke handling for server clusters, which is beneficial in certain scenarios (i.e. brdige devices)
+
+- (Internal for the library) We were able to turn several explicit state machines into implicit ones (after all, `async` is primarily about generating state machines automatically based on "sequential" user codee that uses the async/await language constructs - hence the name of the branch)
+- (External, for the user) The ergonomics of the Exchange API in this branch (in other words, the "transport aspect of the Matter CSA spec) is much better, approaching that of dealing with regular TCP/IP sockets in the Rust Standard Library. This is only possible by utilizing async functions and methods, because - let's not forget - `matter-rs` needs to run on MCUs where native threading and task scheduling capabilities might not even exist, hence "sequentially-looking" request/response interaction can only be expressed asynchronously, or with explicit state machines.
+- Certain pending concepts are much easier to implement via async functions and methods:
+- Re-sending packets which were not acknowledged by the receiver yet (the MRP protocol as per the Matter spec)
+- The "initiator" side of an exchange (think client clusters)
+- This branch provides facilities to implement asynchronous read, write and invoke handling for server clusters, which is beneficial in certain scenarios (i.e. brdige devices)
 
 The `async` metaphor however comes with a bit higher memory usage, due to not enough optimizations being implemented yet in the rust language when the async code is transpiled to state machines.