more headers (#2801)

Signed-off-by: HarHarLinks <[email protected]>

Author: HarHarLinks

content/blog/2025/06/2025-06-27-twim.md

@@ -121,8 +121,6 @@ Android Matrix messenger application using the Matrix Rust SDK and Jetpack Compo
 
 [Jorge](https://matrix.to/#/@jorgem:element.io) says
 
-> # Element X Android
-> 
 > This week we published [v25.06.3](https://github.com/element-hq/element-x-android/releases/tag/v25.06.3) as a stable version in the stores after a week of testing.
 > 
 > Some other stuff we worked on this week:
@@ -277,11 +275,9 @@ Your all-in-one toolkit for creating Matrix clients with Rust, from simple bots
 
 [Ivan 🦀](https://matrix.to/#/@mnt_io:matrix.org) announces
 
-> # `matrix-rust-sdk`
-> 
 > Hello in the wonderful world of Matrix Rust SDK where multiple things are happening simultaneously. It's hard to keep track of everything. I've tried to summarise the recent contributions, please don't feel offended if your great and valuable work isn't listed hereinbelow.
 > 
-> ## WebAssembly
+> #### WebAssembly
 > 
 > The work around WebAssembly is twofold at the moment.
 > 
@@ -299,21 +295,21 @@ Your all-in-one toolkit for creating Matrix clients with Rust, from simple bots
 > 
 > All the other contributions: [#5270](https://github.com/matrix-org/matrix-rust-sdk/pull/5270), [#5265](https://github.com/matrix-org/matrix-rust-sdk/pull/5265), [#5264](https://github.com/matrix-org/matrix-rust-sdk/pull/5264), [#5263](https://github.com/matrix-org/matrix-rust-sdk/pull/5263), [#5262](https://github.com/matrix-org/matrix-rust-sdk/pull/5262), [#5256](https://github.com/matrix-org/matrix-rust-sdk/pull/5256), [#5249](https://github.com/matrix-org/matrix-rust-sdk/pull/5249), [#5242](https://github.com/matrix-org/matrix-rust-sdk/pull/5242), [#5231](https://github.com/matrix-org/matrix-rust-sdk/pull/5231), [#5217](https://github.com/matrix-org/matrix-rust-sdk/pull/5217). The idea isn't to write a changelog but rather to give you an idea of all the subtle changes made here and there to provide you this really cool ability to run the `matrix-sdk-ffi` crate on WebAssembly!
 > 
-> ## Timeline and Event Cache
+> #### Timeline and Event Cache
 > 
 > The Timeline is heavily relying on the Event Cache. We are all humans, and bugs happen. And sometimes new features too.
 > 
 > * [#5271](https://github.com/matrix-org/matrix-rust-sdk/pull/5271) The Timeline has a lazy-pagination. It means that if the Event Cache sends 100\_000 new events to the Timeline, the Timeline will only render 20 of them at a time. Why? For performance reason. Each new Timeline item generates computations, and ultimately ends up sending a message onto an application, so it will, at some point, cross the FFI layer. Reducing the number of data crossing the FFI boundary is a good idea. That's why the Timeline has a lazy-pagination mechanism (see [#4594](https://github.com/matrix-org/matrix-rust-sdk/pull/4594)) to learn more, it involves the `Skip` higher-order stream, it's pretty fun!). However, the Event Cache has also its own pagination mechanism, which includes its own pagination status. This pagination status was shared to the Timeline, without taking into account the lazy-pagination of the Timeline, resulting in wrong status and weird Timeline behaviours. This bug is now fixed, phew.
 > * [#5247](https://github.com/matrix-org/matrix-rust-sdk/pull/5247) The Event Cache is cut into `RoomEventCache`s. As a user, it is possible to subscribe to each of them, and then start receiving `RoomEventCacheUpdate`. It's super nice. However, what happens when one wants to subscribe to _many_ rooms, only to get an idea of which room has been updated, regardless of the update details? It starts creating complications. It involves quite non-trivial async runtime optimisations to be efficient. That's why the new `EventCache::subscribe_to_room_generic_update` will generate `RoomEventCacheGenericUpdate`: subscribe once, get generic update for all rooms. This works was necessary for the new `LatestEvents` API being shape.
 > 
-> ## Widget
+> #### Widget
 > 
 > The Widget API has been improved mostly for Element Call:
 > 
 > * [#5286](https://github.com/matrix-org/matrix-rust-sdk/pull/5286) The `m.room.name` state event is now fetched, allowing widget embedders to know the room name,
 > * [#5283](https://github.com/matrix-org/matrix-rust-sdk/pull/5283) A widget can now receive a _header_ configuration. Not to be confused with the HTTP _header_, this is purely an interface configuration.
 > 
-> ## Encryption
+> #### Encryption
 > 
 > Encryption is a serious topic. It receives its batches of novelties:
 > 
@@ -322,15 +318,15 @@ Your all-in-one toolkit for creating Matrix clients with Rust, from simple bots
 > * [#5276](https://github.com/matrix-org/matrix-rust-sdk/pull/5276) The [MSC4268](https://github.com/matrix-org/matrix-spec-proposals/pull/4268) defines room key bundles. A new store has been created in `matrix-sdk-indexeddb` to store them.
 > * [#5288](https://github.com/matrix-org/matrix-rust-sdk/pull/5288) In the same vain of the previous item, the `OlmMachine`'s store provides a new `historic_room_key_stream` method to get a stream of room key bundles.
 > 
-> ## Room List
+> #### Room List
 > 
 > [#4741](https://github.com/matrix-org/matrix-rust-sdk/pull/4741) The Room List Service is using Sliding Sync to synchronize all the data. Sliding Sync is session-based, i.e. the first response receives from the server by the client contains a `pos` opaque value (for _position_). Each subsequent request must precise this `pos` value, it's a way to tell the server _eh, we already have this session opened! let's reuse this state_. So far, this `pos` wasn't persistent (well, actually, it was, but partially), i.e. when the Matrix Rust SDK was shutdown and restarted, the first sliding sync request made by the Room List Service wasn't containing a `pos`, and thus the server was restarting a new session. This is now a thing of the past. The impact is quite important. For large accounts, it means faster start up time, smaller network requests (notably saving the account data, fewer invites, faster encryption loop), and so on. On a very large account, it is approximately 20 times faster! We are still measuring the impact on the server, but it should save quite a noticeable amount of resources as the server no longer need to throw away a session to start another one.
 > 
-> ## Notification
+> #### Notification
 > 
 > [#5277](https://github.com/matrix-org/matrix-rust-sdk/pull/5277) The notification client wasn't configuring the `m.room.join_rules` correctly, resulting in all rooms being displayed as public.
 > 
-> ## Code coverage
+> #### Code coverage
 > 
 > [#5244](https://github.com/matrix-org/matrix-rust-sdk/pull/5244) This one is important for the contributors. We have switched from `tarpaulin` to `llvm-cov`. In order to measure the code coverage, the Matrix Rust SDK binary is instrumented to add “probes”. With `tarpaulin`, we were being hit by segmentation faults more and more frequently, until a point it was almost constant. We were sometimes forced to change our code just to avoid these segfaults introduced by `tarpaulin`. Well, now we are using `llvm-cov`. It's also faster to run in the CI. One stone, two computers.
 >