prettify and add dev meeting

Author: sanity

hugo-site/content/donate/_index.md

@@ -17,11 +17,11 @@ special interests.
 #### Donate via Cryptocurrency
 
 Freenet is **not** a cryptocurrency, but we do accept cryptocurrency donations. For large donations
-(over \$5,000) please {{< email-protect "gro.teneerf@nai" "contact us" >}} before sending. For smaller
-donations, please use the following wallets:
+(over \$5,000) please {{< email-protect "gro.teneerf@nai" "contact us" >}} before sending. For
+smaller donations, please use the following wallets:
 
 | Cryptocurrency | Address                                      |
-|----------------|----------------------------------------------|
+| -------------- | -------------------------------------------- |
 | Bitcoin        | `3M3fbA7RDYdvYeaoR69cDCtVJqEodo9vth`         |
 | Zcash          | `t1VHw1PHgzvMqEEd31ZBt3Vyy2UrG4J8utB`        |
-| Ethereum       | `0x79158A5Dbd9C0737CB27411817BD2759f5b9a9Ae` |
+| Ethereum       | `0x79158A5Dbd9C0737CB27411817BD2759f5b9a9Ae` |

hugo-site/content/news/dev-meeting-2025-04-10.md

@@ -0,0 +1,47 @@
++++
+tags = ["dev-meeting", "front-page"]
+title = "Developer Meeting" 
+date = 2025-04-10
++++
+
+**Attendees:** Ian Clarke, Ignacio Duart
+
+In this week’s core team meeting, we made significant progress on two fronts:
+
+1. **Update Propagation Over the Network**  
+   Updates are now successfully propagating across Freenet peers, a key milestone toward stable
+   multi-node operation. Ignacio and Ector have been working together to finalize this, and although
+   there may still be an edge case affecting update propagation through intermediary peers, once
+   confirmed, we expect to release a new version shortly.
+
+2. **Delegate API & River Integration**  
+   Ian and Ignacio explored a subtle bug in River’s delegate integration. The issue stems from
+   ambiguity in how application messages are processed and returned. Specifically, marking a
+   delegate message as `processed` prevents it from being delivered to the application, even when a
+   reply is expected. This led to a deeper discussion about improving the delegate runtime API by
+   distinguishing between:
+
+   - _Intermediate messages_ (e.g. `GetSecret`), which expect a reply from the node, and
+   - _Terminal messages_, which are returned to the application.
+
+   The current approach, which relies on a `process` flag, is prone to confusion and bugs. Ignacio
+   proposed a cleaner design that uses distinct message types for intermediate and terminal steps.
+   This change would clarify delegate behavior and reduce potential developer error.
+
+   While this issue affects how delegate messages are handled internally, it **does not block** the
+   ability to demonstrate **River working over the live Freenet network**. River already functions
+   with a workaround, and delegates are primarily used for storing chat room metadata across
+   refreshes.
+
+3. **Executor Pool Refactor (Upcoming)**  
+   Ignacio also has an efficiency-focused PR in progress that addresses long-running contracts. Once
+   complete, it will allow better isolation of failing contracts by replacing execution workers
+   without crashing the process.
+
+---
+
+**Next Steps:**
+
+- Finalize testing of update propagation across multi-hop peer paths.
+- Consider refactoring the delegate API to make message flow and processing states more explicit.
+- Continue preparing for a public demonstration of River running on the live network.

hugo-site/content/news/weekly-dev-meeting-2025-02-07.md

@@ -4,47 +4,68 @@ title = "Weekly Developer Meeting"
 date = 2025-02-07
 +++
 
-#### **Attendees**  
-- Ian Clarke  
-- Ignacio Duart  
-
-#### **Key Updates & Discussion Points**  
-
-1. **Network Connection Fixes**  
-   - Most issues preventing stable peer connections have been fixed.  
-   - The network can now maintain multiple connections, resolving a previous issue where only two peers could connect at a time.  
-   - The root cause was a combination of:  
-     - The gateway not waiting long enough before cleaning transient connections.  
-     - A logic bug in packet receipt handling that caused repeated transmission loops.  
-   - A fix was implemented to send receipts after a time threshold, even if the packet count limit wasn't met.  
-
-2. **Remaining Network Issue**  
-   - There is still a logical issue in peer filtering when forwarding new connection requests.  
-   - Some peers are mistakenly being filtered out, preventing them from establishing connections.  
-   - Ignacio believes the issue stems from unintended state mutations in transaction forwarding logic.  
-
-3. **Ping Contract Debugging**  
-   - The team was testing the ping contract using a single peer for writes and others for reads.  
-   - An issue was discovered where state updates are not propagating, likely caused by a previous efficiency optimization that prevented redundant updates.  
-   - The get function may also not be retrieving the contract correctly.  
-
-4. **Persistent Contract Updates for Demo**  
-   - To ensure the contract is continuously updated, the team will run the ping contract on a gateway to keep activity visible.  
-
-5. **Code & Technical Adjustments**  
-   - Discussed removing an outdated connection filtering rule preventing multiple nodes on the same local network from connecting.  
-   - Ensured that the network can support multiple peers with the same location, using historical response times for routing decisions.  
-
-6. **River Chat Integration & Serialization Issue**  
-   - Ian is working on integrating River with Freenet.  
-   - Encountering a serialization error when sending messages via WebSockets.  
-   - Ignacio suggested debugging the contract execution process by adding logging inside the contract functions.  
-   - Suspected issue: The contract is failing to deserialize state data inside the WASM execution layer.  
-
-#### **Next Steps**  
-- **Ignacio** will continue debugging the contract issue and monitor network stability over the weekend.  
-- **Ian** will investigate the serialization error in River and implement contract logging to pinpoint the deserialization issue.  
-- **Both** will work toward a stable release early next week, with a recorded demo prepared by midweek.  
-
-#### **Closing Notes**  
-- Ignacio mentioned a tool for creating realistic AI-generated demo videos with avatars; he will follow up with Ian on its name.  
+#### **Attendees**
+
+- Ian Clarke
+- Ignacio Duart
+
+#### **Key Updates & Discussion Points**
+
+1. **Network Connection Fixes**
+
+   - Most issues preventing stable peer connections have been fixed.
+   - The network can now maintain multiple connections, resolving a previous issue where only two
+     peers could connect at a time.
+   - The root cause was a combination of:
+     - The gateway not waiting long enough before cleaning transient connections.
+     - A logic bug in packet receipt handling that caused repeated transmission loops.
+   - A fix was implemented to send receipts after a time threshold, even if the packet count limit
+     wasn't met.
+
+2. **Remaining Network Issue**
+
+   - There is still a logical issue in peer filtering when forwarding new connection requests.
+   - Some peers are mistakenly being filtered out, preventing them from establishing connections.
+   - Ignacio believes the issue stems from unintended state mutations in transaction forwarding
+     logic.
+
+3. **Ping Contract Debugging**
+
+   - The team was testing the ping contract using a single peer for writes and others for reads.
+   - An issue was discovered where state updates are not propagating, likely caused by a previous
+     efficiency optimization that prevented redundant updates.
+   - The get function may also not be retrieving the contract correctly.
+
+4. **Persistent Contract Updates for Demo**
+
+   - To ensure the contract is continuously updated, the team will run the ping contract on a
+     gateway to keep activity visible.
+
+5. **Code & Technical Adjustments**
+
+   - Discussed removing an outdated connection filtering rule preventing multiple nodes on the same
+     local network from connecting.
+   - Ensured that the network can support multiple peers with the same location, using historical
+     response times for routing decisions.
+
+6. **River Chat Integration & Serialization Issue**
+   - Ian is working on integrating River with Freenet.
+   - Encountering a serialization error when sending messages via WebSockets.
+   - Ignacio suggested debugging the contract execution process by adding logging inside the
+     contract functions.
+   - Suspected issue: The contract is failing to deserialize state data inside the WASM execution
+     layer.
+
+#### **Next Steps**
+
+- **Ignacio** will continue debugging the contract issue and monitor network stability over the
+  weekend.
+- **Ian** will investigate the serialization error in River and implement contract logging to
+  pinpoint the deserialization issue.
+- **Both** will work toward a stable release early next week, with a recorded demo prepared by
+  midweek.
+
+#### **Closing Notes**
+
+- Ignacio mentioned a tool for creating realistic AI-generated demo videos with avatars; he will
+  follow up with Ian on its name.

hugo-site/content/resources/manual/architecture/irouting.md

@@ -5,57 +5,48 @@ draft: false
 weight: 2
 ---
 
-Freenet's request routing mechanism plays a crucial role in the efficiency of
-the network.
+Freenet's request routing mechanism plays a crucial role in the efficiency of the network.
 
-It is responsible for deciding which peer to route a request to when attempting
-to read, create, or modify a contract's state. The mechanism is designed to
-select the peer that can complete the request the fastest, which may not always
-be the peer closest to the contract's location - the traditional approach for
-routing in a small-world network, known as [greedy
-routing](https://en.wikipedia.org/wiki/Small-world_routing#Greedy_routing).
+It is responsible for deciding which peer to route a request to when attempting to read, create, or
+modify a contract's state. The mechanism is designed to select the peer that can complete the
+request the fastest, which may not always be the peer closest to the contract's location - the
+traditional approach for routing in a small-world network, known as
+[greedy routing](https://en.wikipedia.org/wiki/Small-world_routing#Greedy_routing).
 
 ### Isotonic Regression
 
-Freenet uses [isotonic regression](https://github.com/sanity/pav.rs), a method
-for estimating a monotonically increasing or decreasing function given a set of
-data, to predict the response time from a peer based on its ring distance from
-the target location of the request.
+Freenet uses [isotonic regression](https://github.com/sanity/pav.rs), a method for estimating a
+monotonically increasing or decreasing function given a set of data, to predict the response time
+from a peer based on its ring distance from the target location of the request.
 
-This estimation is then adjusted by the average difference between the isotonic
-regression estimate and the actual response time from previous interactions with
-the peer. This process enables a form of adaptive routing that selects the peer
-with the lowest estimated response time.
+This estimation is then adjusted by the average difference between the isotonic regression estimate
+and the actual response time from previous interactions with the peer. This process enables a form
+of adaptive routing that selects the peer with the lowest estimated response time.
 
 ### Router Initialization and Event Handling
 
-When a new
-[Router](https://github.com/freenet/freenet-core/blob/main/crates/core/src/router.rs)
-is created, it's initialized with a history of routing events. These events are
-processed to generate the initial state of the isotonic estimators. For example,
-failure outcomes and success durations are computed for each event in the
-history and used to initialize the respective estimators. The average transfer
-size is also computed from the history.
+When a new [Router](https://github.com/freenet/freenet-core/blob/main/crates/core/src/router.rs) is
+created, it's initialized with a history of routing events. These events are processed to generate
+the initial state of the isotonic estimators. For example, failure outcomes and success durations
+are computed for each event in the history and used to initialize the respective estimators. The
+average transfer size is also computed from the history.
 
-The Router can add new events to its history, updating its estimators in the
-process. When a successful routing event occurs, the Router updates its response
-start time estimator, failure estimator, and transfer rate estimator based on
-the details of the event. If a failure occurs, only the failure estimator is
-updated.
+The Router can add new events to its history, updating its estimators in the process. When a
+successful routing event occurs, the Router updates its response start time estimator, failure
+estimator, and transfer rate estimator based on the details of the event. If a failure occurs, only
+the failure estimator is updated.
 
 ### Peer Selection
 
-To select a peer for routing a request, the Router first checks whether it has
-sufficient historical data. If not, it selects the peer with the minimum
-distance to the contract location. If it does have sufficient data, it predicts
-the outcome of routing the request to each available peer and selects the one
-with the best predicted outcome.
+To select a peer for routing a request, the Router first checks whether it has sufficient historical
+data. If not, it selects the peer with the minimum distance to the contract location. If it does
+have sufficient data, it predicts the outcome of routing the request to each available peer and
+selects the one with the best predicted outcome.
 
 ### Outcome Prediction
 
-To predict the outcome of routing a request to a specific peer, the Router uses
-its isotonic estimators to predict the time to the start of the response, the
-chance of failure, and the transfer rate. These predictions are used to compute
-an expected total time for the request, with the cost of a failure being assumed
-as a multiple of the cost of success. The peer with the lowest expected total
-time is selected for routing the request.
+To predict the outcome of routing a request to a specific peer, the Router uses its isotonic
+estimators to predict the time to the start of the response, the chance of failure, and the transfer
+rate. These predictions are used to compute an expected total time for the request, with the cost of
+a failure being assumed as a multiple of the cost of success. The peer with the lowest expected
+total time is selected for routing the request.

hugo-site/content/resources/manual/architecture/p2p-network.md

@@ -8,32 +8,32 @@ draft: false
 
 ## Small-World Network
 
-Freenet is structured as a decentralized peer-to-peer network, based on the idea of
-a [small-world network](https://en.wikipedia.org/wiki/Small-world_network). This
-network topology is scalable and efficient, allowing contract state to be found
-quickly and without any reliance on a central authority.
+Freenet is structured as a decentralized peer-to-peer network, based on the idea of a
+[small-world network](https://en.wikipedia.org/wiki/Small-world_network). This network topology is
+scalable and efficient, allowing contract state to be found quickly and without any reliance on a
+central authority.
 
 ![Small World Network](/p2p-network.svg)
 
 ## Freenet Peers
 
-In Freenet, a "peer" is any computer running the [Freenet
-Core](https://github.com/freenet/freenet-core) software. The peers are organized
-in a ring-like structure, with each peer assigned a specific numerical value
-between 0.0 and 1.0, indicating its location in the network's topology. This
-location is derived from the peer's IP address.
+In Freenet, a "peer" is any computer running the
+[Freenet Core](https://github.com/freenet/freenet-core) software. The peers are organized in a
+ring-like structure, with each peer assigned a specific numerical value between 0.0 and 1.0,
+indicating its location in the network's topology. This location is derived from the peer's IP
+address.
 
 ## Establishing Neighbor Connections
 
-Every Freenet peer, also referred to as a node, forms two-way connections with a
-set of other peers, termed "neighbors." These connections utilize the User
-Datagram Protocol (UDP) and can do [Firewall hole punching](<https://en.wikipedia.org/wiki/Hole_punching_(networking)>) when necessary. Peers manage their resource usage —
-bandwidth, memory, CPU, and storage — based on limits set by the user.
+Every Freenet peer, also referred to as a node, forms two-way connections with a set of other peers,
+termed "neighbors." These connections utilize the User Datagram Protocol (UDP) and can do
+[Firewall hole punching](<https://en.wikipedia.org/wiki/Hole_punching_(networking)>) when necessary.
+Peers manage their resource usage — bandwidth, memory, CPU, and storage — based on limits set by the
+user.
 
 ## Adaptive behavior
 
-Peers keep track of their neighbor's performance and learn to prefer faster
-connections over time.
+Peers keep track of their neighbor's performance and learn to prefer faster connections over time.
 
-Peers can also identify bad behavior by other peers like excess resource usage and
-will disconnect from them.
+Peers can also identify bad behavior by other peers like excess resource usage and will disconnect
+from them.