chore: fix broken links (#357)

2026-08-27 08:11:12 +00:00 · 2026-06-12 17:41:41 +03:00
parent bb9d20bdef
commit 124f895791
66 changed files with 277 additions and 249 deletions
@@ -23,6 +23,7 @@ pipeline {
  environment {
    GIT_COMMITTER_NAME = 'status-im-auto'
    GIT_COMMITTER_EMAIL = 'auto@status.im'
+    LIPS_GENERATE_HISTORY = '1'
  }

  stages {
@@ -52,6 +52,9 @@ python scripts/run_runtime_generators.py
 mdbook build
 ```

+History timelines are generated only in CI. Local generator runs skip
+`scripts/gen_history.py` unless `LIPS_GENERATE_HISTORY=1` is set.
+
 To serve locally:

 ```bash
@@ -66,7 +66,7 @@ The example URL from EIP-1459, adapted to the above scheme becomes:
 matree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2@peers.example.org
 ```

-Each entry within the Merkle tree MUST be contained within a [DNS TXT record](https://www.rfc-editor.org/rfc/rfc1035.txt)
+Each entry within the Merkle tree MUST be contained within a [DNS TXT record](https://datatracker.ietf.org/doc/html/rfc1035)
 and stored in a subdomain (except for the base URL `matree` entry).
 The content of any TXT record
 MUST be small enough to fit into the 512-byte limit imposed on UDP DNS packets,
@@ -37,7 +37,7 @@
 ## NOTE

 The content of this specification has been split between
-[ETH-MLS-OFFCHAIN](/anoncomms/raw/eth-mls-offchain.md) and [NOISE-X3DH-DOUBLE-RATCHET](/anoncomms/raw/noise-x3dh-double-ratchet.md)
+[ETH-MLS-OFFCHAIN](../raw/decentralized-mls-offchain-consensus.md) and [NOISE-X3DH-DOUBLE-RATCHET](../raw/noise-x3dh-double-ratchet.md)
 LIPs.

 ## Motivation
@@ -50,7 +50,7 @@ offering a robust solution to address these challenges.

 This specification outlines a private messaging service using the
 Ethereum blockchain as authentication service.
-Rooted in the existing [model](../../../messaging/draft/20/toy-eth-pm.md),
+Rooted in the existing [model](../../messaging/draft/20/toy-eth-pm.md),
 this proposal addresses the deficiencies related
 to forward privacy and authentication inherent
 in the current framework.
@@ -448,7 +448,7 @@ Credentials MUST follow the specifications of section 5.3 of

 Below follows the flow diagram for the generation of credentials.
 Users MUST generate key pairs by themselves.
-![figure1](/anoncomms/deleted/images/eth-secpm_credential.png)
+![figure1](images/eth-secpm_credential.png)

 ### Message framing

@@ -491,7 +491,7 @@ The nodes of a ratchet tree contain several types of data:
 Contents of each kind of node, and its structure MUST follow the
 indications described in
 sections 7.1 and 7.2 of
-[RFC9420](https://datatracker.ietf.org/docrfc9420/).
+[RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 ### Leaf node validation

@@ -791,10 +791,10 @@ CredentialType credential_types<V>;

 The flow diagram shows the procedure to fetch key material from other
 users:
-![figure2](/anoncomms/deleted/images/eth-secpm_fetching.png)
+![figure2](images/eth-secpm_fetching.png)

 Below follows the flow diagram for the creation of a group:
-![figure3](/anoncomms/deleted/images/eth-secpm_creation.png)
+![figure3](images/eth-secpm_creation.png)

 ### Group evolution

@@ -861,23 +861,23 @@ member who created the commit, or any group member processing such
 commit.
 The validation MUST be done according to one of the procedures
 described in Section 12.2 of
-[RFC9420](https://datatracker.ietf.orgdoc/rfc9420/).
+[RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 When creating or processing a Commit, a client applies a list of
 proposals to the ratchet tree and `GroupContext`.
 The client MUST apply the proposals in the list in the order described
-in Section 12.3 of [RFC9420](https://datatracker.ietf.org/docrfc9420/).
+in Section 12.3 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 Below follows the flow diagram for the addition of a member to a group:
-![figure4](/anoncomms/deleted/images/eth-secpm_add.png)
+![figure4](images/eth-secpm_add.png)

 The diagram below shows the procedure to remove a group member:

-![figure5](/anoncomms/deleted/images/eth-secpm_remove.png)
+![figure5](images/eth-secpm_remove.png)

 The flow diagram below shows an update procedure:

-![figure6](/anoncomms/deleted/images/eth-secpm_update.png)
+![figure6](images/eth-secpm_update.png)

 ### Commit messages

@@ -1045,7 +1045,7 @@ Format:

 - `scheme` OPTIONAL. The URI scheme of the origin of the request.
 Its value MUST be a
-[RFC 3986](https://datatracker.ietf.org/doc/htmlrfc3986)
+[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)
 URI scheme.

 - `domain` REQUIRED.
@@ -1064,7 +1064,7 @@ specified in ERC-55 where applicable.
 - `statement` OPTIONAL. A human-readable ASCII assertion that the user
 will sign which MUST NOT include '\n' (the byte 0x0a).
 - `uri` REQUIRED. An
-[RFC 3986](https://datatracker.ietf.org/doc/htmlrfc3986)
+[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)
 URI referring to the resource that is the subject of the
 signing.

@@ -1319,7 +1319,7 @@ and checks that it corresponds to an address contained in the ACL.
 7. Off-chain - Alice sends a welcome message to Bob.
 8. Off-chain - Alice SHOULD broadcasts a message announcing the
 addition of Bob to other users of the group.
-![figure7](/anoncomms/deleted/images/eth-secpm_onchain-register-1.png)
+![figure7](images/eth-secpm_onchain-register-1.png)

 #### Alice does not know Bob’s Ethereum address

@@ -1342,7 +1342,7 @@ contract.
 8. Off-chain - Alice SHOULD broadcasts a message announcing the
 addition of Bob to other users of the group.

-![figure8](/anoncomms/deleted/images/eth-secpm_onchain-register-2.png)
+![figure8](images/eth-secpm_onchain-register-2.png)

 ### Considerations regarding smart contracts

@@ -1362,7 +1362,7 @@ off-chain message.
  - The creator of the contract MUST update the ACL, and send
 messages to the group for key update.

-![figure9](/anoncomms/deleted/images/eth-secpm_onchain-update.png)
+![figure9](images/eth-secpm_onchain-update.png)

 > It is important to note that both
 user removal and updates of any kind
@@ -99,7 +99,7 @@ usually a financial or social stake is introduced.
 An example for financial stake is:

 For each registration a certain amount of ETH is required.
-An example for social stake is using [Interep](https://interep.link/) as a registry,
+An example for social stake is using [Interep](https://github.com/interep-project) as a registry,
 users need to prove that they have a highly reputable social media account.

 #### Implementation notes
@@ -793,7 +793,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References

 - [17/WAKU2-RLN-RELAY RFC](../../../messaging/draft/17/rln-relay.md)
- [Interep](https://interep.link/)
+- [Interep](https://github.com/interep-project)
 - [incremental Merkle tree algorithm](https://github.com/appliedzkp/incrementalquintree/blob/master/ts/IncrementalQuinTree.ts)
 - [Shamir's Secret sharing scheme](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
 - [Lagrange polynomials](https://en.wikipedia.org/wiki/Lagrange_polynomial)
@@ -216,7 +216,7 @@ bytes signature = 27;           // Signature of vote_hash
 The voting proposal MAY include adding a `node` or removing a `member`.
 After the `member` creates the voting proposal,
 it is emitted to the network via the MLS `Application message` with a lightweight,
-epoch based voting such as [hashgraphlike consensus.](https://github.com/logos-co/logos-lips/blob/consensus-hashgraph-like/vac/raw/consensus-hashgraphlike.md)
+epoch based voting such as [hashgraphlike consensus.](consensus-hashgraphlike.md)
 This consensus result MUST be finalized within the epoch as YES or NO.

 If the voting result is YES, this points out the voting proposal will be converted into
@@ -683,5 +683,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ### References

 - [MLS RFC 9420](https://datatracker.ietf.org/doc/rfc9420/)
- [Hashgraphlike Consensus](https://github.com/logos-co/logos-lips/blob/consensus-hashgraph-like/vac/raw/consensus-hashgraphlike.md)
+- [Hashgraphlike Consensus](consensus-hashgraphlike.md)
 - [vacp2p/de-mls](https://github.com/vacp2p/de-mls)
@@ -170,7 +170,7 @@ Credentials MUST follow the specifications of section 5.3 of

 Below follows the flow diagram for the generation of credentials.
 Users MUST generate key pairs by themselves.
-![figure1](images/eth-secpm_credential.png)
+![figure1](../deleted/images/eth-secpm_credential.png)

 ### Message framing

@@ -205,10 +205,10 @@ a message from that sender.
 ### Nodes contents

 > This section makes use of sections 4 and 7 of
-[RFC9420](https://datatracker.ietf.org/docrfc9420/).
+[RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 The nodes of a ratchet tree
-(Section 4 in [RFC9420](https://datatracker.ietf.org/docrfc9420/))
+(Section 4 in [RFC9420](https://datatracker.ietf.org/doc/rfc9420/))
 contain several types of data:

 - Leaf nodes describe individual members.
@@ -216,7 +216,7 @@ contain several types of data:

 Contents of each kind of node, and its structure MUST follow
 the indications described in sections 7.1 and 7.2 of
-[RFC9420](https://datatracker.ietf.org/docrfc9420/).
+[RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 ### Leaf node validation

@@ -514,11 +514,11 @@ struct {
 The flow diagram shows the procedure to fetch key material
 from other users:

-![figure2](images/eth-secpm_fetching.png)
+![figure2](../deleted/images/eth-secpm_fetching.png)

 Below follows the flow diagram for the creation of a group:

-![figure3](images/eth-secpm_creation.png)
+![figure3](../deleted/images/eth-secpm_creation.png)

 ### Group evolution

@@ -585,24 +585,24 @@ member who created the commit, or any group member processing
 such commit.
 The validation MUST be done according to one of the procedures
 described in Section 12.2 of
-[RFC9420](https://datatracker.ietf.orgdoc/rfc9420/).
+[RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 When creating or processing a Commit, a client applies a list of
 proposals to the ratchet tree and `GroupContext`.
 The client MUST apply the proposals in the list in the order described
-in Section 12.3 of [RFC9420](https://datatracker.ietf.org/docrfc9420/).
+in Section 12.3 of [RFC9420](https://datatracker.ietf.org/doc/rfc9420/).

 Below follows the flow diagram for the addition of a member to a group:

-![figure4](images/eth-secpm_add.png)
+![figure4](../deleted/images/eth-secpm_add.png)

 The diagram below shows the procedure to remove a group member:

-![figure5](images/eth-secpm_remove.png)
+![figure5](../deleted/images/eth-secpm_remove.png)

 The flow diagram below shows an update procedure:

-![figure6](images/eth-secpm_update.png)
+![figure6](../deleted/images/eth-secpm_update.png)

 ### Commit messages

@@ -680,7 +680,7 @@ confirming his Ethereum address and agreement to join.
 7. Off-chain: Alice sends a broadcast message to all group members,
 notifying them the addition of Bob.

-![figure8](images/eth-secpm_onchain-register-2.png)
+![figure8](../deleted/images/eth-secpm_onchain-register-2.png)

 ### Updates in groups

@@ -696,7 +696,7 @@ Alice sends it to the smart contract for registration.
 5. Off-chain: Alice sends a broadcast message
 communicating the update to all users.

-![figure9](images/eth-secpm_onchain-update.png)
+![figure9](../deleted/images/eth-secpm_onchain-update.png)

 ## Ethereum-based authentication protocol

@@ -789,7 +789,7 @@ in [EIP 4361](https://eips.ethereum.org/EIPS/eip-4361).

 - `scheme` OPTIONAL. The URI scheme of the origin of the request.
 Its value MUST be a
-[RFC 3986](https://datatracker.ietf.org/doc/htmlrfc3986)
+[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)
 URI scheme.

 - `domain` REQUIRED.
@@ -808,7 +808,7 @@ specified in ERC-55 where applicable.
 - `statement` OPTIONAL. A human-readable ASCII assertion that the user
 will sign which MUST NOT include '\n' (the byte 0x0a).
 - `uri` REQUIRED. An
-[RFC 3986](https://datatracker.ietf.org/doc/htmlrfc3986)
+[RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)
 URI referring to the resource that is the subject of the
 signing.

@@ -1007,7 +1007,7 @@ channels in a secure way. One of these situations is when a user A
 wants to add a new user B to an existing group.
 In such situations communications between users MUST be done following
 the instructions in this
-[specification](https://github.com/logos-co/logos-lips/blob/eth-secpm-splitted/vac/raw/eth-secure-channel.md)
+[specification](noise-x3dh-double-ratchet.md)
 describing the use of X3DH in combination with the double ratchet mechanism.

 ## Considerations with respect to decentralization
@@ -69,7 +69,7 @@ The approach specified in this document is fully backwards compatible.
 Gossipsub nodes that do not support Tor Push can receive and relay Tor Push messages,
 because Tor Push uses the same Protocol ID as gossipsub.

-Messages are sent over Tor via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928).
+Messages are sent over Tor via [SOCKS5](https://datatracker.ietf.org/doc/html/rfc1928).
 Tor Push uses a dedicated libp2p context to prevent information leakage.
 To significantly increase resilience and mitigate circuit failures,
 Tor Push establishes several connections,
@@ -136,7 +136,7 @@ Control messages of any kind, e.g. gossipsub graft, MUST NOT be sent via Tor Pus
 #### Connection Establishment

 Tp-nodes establish a `/meshsub/1.1.0` connection to tp-peers via
-[SOCKS5](https://www.rfc-editor.org/rfc/rfc1928) over [Tor](https://www.torproject.org/).
+[SOCKS5](https://datatracker.ietf.org/doc/html/rfc1928) over [Tor](https://www.torproject.org/).

 Establishing connections, which in turn establishes the respective Tor circuits,
 can be done ahead of time.
@@ -237,7 +237,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [libp2p pubsub](https://github.com/libp2p/specs/tree/master/pubsub)
 * [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message)
 * [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch)
-* [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928)
+* [SOCKS5](https://datatracker.ietf.org/doc/html/rfc1928)
 * [Tor](https://www.torproject.org/)
 * [33/WAKU2-DISCV5](../../messaging/draft/33/discv5.md)
 * [Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022)
@@ -484,7 +484,7 @@ to avoid coupling the protocol to specific formats

 ### Advertisement Encoding

-Advertisements in the `Register.advertisement` and `GetAds.advertisements` fields are encoded as `bytes`. Implementations are RECOMMENDED to use [ExtensiblePeerRecord (XPR)](https://github.com/logos-co/logos-lips/blob/d59c44477fcdc3c3b61655bea63068d6d94c51f6/vac/raw/extensible-peer-records.md) encoding.
+Advertisements in the `Register.advertisement` and `GetAds.advertisements` fields are encoded as `bytes`. Implementations are RECOMMENDED to use [ExtensiblePeerRecord (XPR)](extensible-peer-records.md) encoding.

 Alternative encodings MAY be used if they provide equivalent functionality
 and can be verified by discoverers.
@@ -448,7 +448,7 @@ Note that the reply key $`\tilde{k}`$ is $`\kappa`$ bytes in size as defined in

 ## 7. Sphinx Payload Processing

-Once the Sphinx packet is deserialized into ($`\alpha,\ \beta,\ \gamma,\ \delta`$) and the header is preprocessed as specified in the Mix protocol, the mix node performs the following steps depending on its role (as defined in the [Mix Protocol, Section 8.6.2](./mix/#862-node-role-determination)):
+Once the Sphinx packet is deserialized into ($`\alpha,\ \beta,\ \gamma,\ \delta`$) and the header is preprocessed as specified in the Mix protocol, the mix node performs the following steps depending on its role (as defined in the [Mix Protocol, Section 8.6.2](mix.md#862-node-role-determination)):

 ### 7.1 Intermediary Processing

@@ -353,7 +353,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ## References

- [libp2p mix protocol](https://github.com/logos-co/logos-lips/blob/cfc08e9f0e51de20fc5f24b77ad01163c113706e/vac/raw/mix.md/)
+- [libp2p mix protocol](mix.md)
 - [Rate Limiting Nullifiers (RLN)](https://vac.dev/rln)
 - [Rate Limiting Nullifiers v2](https://github.com/logos-co/logos-lips/blob/dabc31786b4a4ca704ebcd1105239faff7ac2b47/vac/raw/rln-v2.md)
 - [RLN v1](https://github.com/logos-co/logos-lips/blob/dabc31786b4a4ca704ebcd1105239faff7ac2b47/vac/32/rln-v1.md)
@@ -78,7 +78,7 @@ RLN-Diff introduces per-user rate limits. Therefore, **id_commitment** must depe
 0 ≤ `user_message_limit` ≤ `message_limit`.

 The user submits the same `identity_secret_hash` as in
-[32/RLN-V1](32/rln-v1.md), i.e.
+[32/RLN-V1](../draft/32/rln-v1.md), i.e.
 `poseidonHash(identity_secret)`, together with `user_message_limit` to a server or
 smart contract.

@@ -119,7 +119,7 @@ internal_nullifier = poseidonHash([a_1]);

 ### RLNv2 Verification/slashing

-Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](32/rln-v1.md).
+Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](../draft/32/rln-v1.md).
 The only difference that may arise is the `message_limit` check in RLN-Same,
 since it is now a public input of the Circuit.

@@ -235,5 +235,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### References

-* [RLNv1](32/rln-v1.md)
+* [RLNv1](../draft/32/rln-v1.md)
 * [RLNv2](rln-v2.md)
@@ -31,8 +31,8 @@

 ## Abstract

-This spec integrates [Interep](https://interep.link)
-into the [RLN](32/rln-v1.md) spec.
+This spec integrates [Interep](https://github.com/interep-project)
+into the [RLN](../draft/32/rln-v1.md) spec.
 Interep is a group management protocol
 that allows for the creation of groups of users and
 the management of their membership.
@@ -86,7 +86,7 @@ depicted in the [Semaphore documentation](https://semaphore.appliedzkp.org/docs/

 ### 2. Verify reputation and join Interep group

-Using the Interep app deployed on [Goerli](https://goerli.interep.link/),
+Using the Interep app deployed on Goerli,
 the user can check their reputation tier and join the corresponding group.
 This results in a transaction to the Interep contract, which adds them to the group.

@@ -121,11 +121,11 @@ in the RLN contract -

 ## Verification of messages

-Messages are verified the same way as in the [RLN spec](32/rln-v1.md#verification).
+Messages are verified the same way as in the [RLN spec](../draft/32/rln-v1.md#verification).

 ## Slashing

-The slashing mechanism is the same as in the [RLN spec](32/rln-v1.md#slashing).
+The slashing mechanism is the same as in the [RLN spec](../draft/32/rln-v1.md#slashing).
 It is important to note that the slashing
 may not have the intended effect on the user,
 since the only consequence is that they cannot send messages.
@@ -143,8 +143,8 @@ which integrates Interep with RLN.

 1. As mentioned in [Slashing](#slashing),
 the slashing mechanism may not have the intended effect on the user.
-2. This spec inherits the security considerations of the [RLN spec](32/rln-v1.md#security-considerations).
-3. This spec inherits the security considerations of [Interep](https://docs.interep.link/).
+2. This spec inherits the security considerations of the [RLN spec](../draft/32/rln-v1.md#appendix-a-security-considerations).
+3. This spec inherits the security considerations of [Interep](https://github.com/interep-project/docs).
 4. A user may make multiple registrations using the same Interep proofs but
 different identity commitments.
 The way to mitigate this is to check if the nullifier hash has been detected
@@ -152,10 +152,10 @@ previously in proof verification.

 ## References

-1. [RLN spec](32/rln-v1.md)
-2. [Interep](https://interep.link)
+1. [RLN spec](../draft/32/rln-v1.md)
+2. [Interep](https://github.com/interep-project)
 3. [Semaphore](https://semaphore.appliedzkp.org/)
 4. [Decentralized cloudflare using Interep](https://ethresear.ch/t/decentralised-cloudflare-using-rln-and-rich-user-identities/10774)
 5. [Interep contracts](https://github.com/interep-project/contracts)
 6. [RLN contract](https://github.com/vacp2p/rln-contract)
-7. [RLNP2P](https://rlnp2p.vac.dev/)
+7. [RLNP2P](https://github.com/vacp2p/rlnp2p.vac.dev)
@@ -38,7 +38,7 @@ to determine client eligibility for membership allocation.
 ## Motivation

 The Rate Limiting Nullifier (RLN) protocol, as specified in
-[32/RLN-V1](./32/rln-v1.md), requires users to register their
+[32/RLN-V1](../draft/32/rln-v1.md), requires users to register their
 identity commitments in a membership Merkle tree before
 participating in rate-limited anonymous signaling.
 In the standard registration flow, clients submit a transaction
@@ -103,7 +103,7 @@ A client MUST specify the authentication method to use in the
 A client MUST include a payload in the `authentication_payload` field,
 further defined by the authentication method.
 A client MUST include the
-[identity commitment](../32/rln-v1.md#user-identity) to register in the
+[identity commitment](../draft/32/rln-v1.md#user-identity) to register in the
 `identity_commitment` field.
 A client MAY include a `rate_limit` value specifying the requested
 per-epoch message rate limit for the membership; if omitted, the
@@ -219,7 +219,7 @@ message OnchainAuthenticationPayload {

 A membership provider MAY advertise that it offers membership allocation
 services by participating in the
-[Logos Capability Discovery protocol](./logos-capability-discovery.md).
+[Logos Capability Discovery protocol](logos-service-discovery.md).
 A membership provider SHOULD include a list of supported authentication
 methods in the metadata field of the `Advertisement` message.
 A membership provider MUST use the protocol ID `/rln/membership/<version>`
@@ -239,6 +239,6 @@ Copyright and related rights waived via

 ## References

- [32/RLN-V1](./32/rln-v1.md)
+- [32/RLN-V1](../draft/32/rln-v1.md)
 - [RLN Stealth Commitments](rln-stealth-commitments.md)
- [Logos Capability Discovery protocol](./logos-capability-discovery.md)
+- [Logos Capability Discovery protocol](logos-service-discovery.md)
@@ -30,11 +30,11 @@

 This specification describes the usage of stealth commitments
 to add prospective users to a network-governed
-[32/RLN-V1](32/rln-v1.md) membership set.
+[32/RLN-V1](../draft/32/rln-v1.md) membership set.

 ## Motivation

-When [32/RLN-V1](32/rln-v1.md) is enforced in [10/Waku2](../../messaging/draft/10/waku2.md),
+When [32/RLN-V1](../draft/32/rln-v1.md) is enforced in [10/Waku2](../../messaging/draft/10/waku2.md),
 all users are required to register to a membership set.
 The membership set will store user identities
 allowing the secure interaction within an application.
@@ -47,14 +47,14 @@ to register identities on the user's behalf,
 while maintaining the user's anonymity.

 This document specifies a privacy-preserving mechanism,
-allowing a counterparty to utilize [32/RLN-V1](32/rln-v1.md)
+allowing a counterparty to utilize [32/RLN-V1](../draft/32/rln-v1.md)
 to register an `identityCommitment` on-chain.
 Counterparties will be able to register members
 to a RLN membership set without exposing the user's private keys.

 ## Background

-The [32/RLN-V1](32/rln-v1.md) protocol,
+The [32/RLN-V1](../draft/32/rln-v1.md) protocol,
 consists of a smart contract that stores a `idenitityCommitment`
 in a membership set.
 In order for a user to join the membership set,
@@ -63,17 +63,17 @@ A set of public keys is used to compute a stealth commitment for a user,
 as described in [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564).
 This specification is an implementation of the
 [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) scheme,
-tailored to the curve that is used in the [32/RLN-V1](32/rln-v1.md) protocol.
+tailored to the curve that is used in the [32/RLN-V1](../draft/32/rln-v1.md) protocol.

 This can be used in a couple of ways in applications:

 1. Applications can add users
-to the [32/RLN-V1](32/rln-v1.md) membership set in a batch.
+to the [32/RLN-V1](../draft/32/rln-v1.md) membership set in a batch.
 2. Users of the application
-can register other users to the [32/RLN-V1](32/rln-v1.md) membership set.
+can register other users to the [32/RLN-V1](../draft/32/rln-v1.md) membership set.

 This is useful when the prospective user does not have access to funds
-on the network that [32/RLN-V1](32/rln-v1.md) is deployed on.
+on the network that [32/RLN-V1](../draft/32/rln-v1.md) is deployed on.

 ## Wire Format Specification

@@ -141,5 +141,5 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References

 - [10/Waku2](../../messaging/draft/10/waku2.md)
- [32/RLN-V1](32/rln-v1.md)
+- [32/RLN-V1](../draft/32/rln-v1.md)
 - [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564)
@@ -30,9 +30,9 @@

 ## Abstract

-The protocol specified in this document is an improvement of [32/RLN-V1](32/rln-v1.md),
+The protocol specified in this document is an improvement of [32/RLN-V1](../draft/32/rln-v1.md),
 being more general construct, that allows to set various limits for an epoch
-(it's 1 message per epoch in [32/RLN-V1](32/rln-v1.md))
+(it's 1 message per epoch in [32/RLN-V1](../draft/32/rln-v1.md))
 while remaining almost as simple as it predecessor.
 Moreover, it allows to set different rate-limits
 for different RLN app users based on some public data,
@@ -40,7 +40,7 @@ e.g. stake or reputation.

 ## Motivation

-The main goal of this RFC is to generalize [32/RLN-V1](32/rln-v1.md) and
+The main goal of this RFC is to generalize [32/RLN-V1](../draft/32/rln-v1.md) and
 expand its applications.
 There are two different subprotocols based on this protocol:

@@ -53,7 +53,7 @@ because their `internal_nullifiers` will not be repeated until they exceed the l

 ## Flow

-As in [32/RLN-V1](32/rln-v1.md), the general flow can be described by three steps:
+As in [32/RLN-V1](../draft/32/rln-v1.md), the general flow can be described by three steps:

 1. Registration
 2. Signaling
@@ -64,14 +64,14 @@ hence are defined separately.

 ### Important note

-All terms and parameters used remain the same as in [32/RLN-V1](32/rln-v1.md),
-more details [here](32/rln-v1.md#technical-overview)
+All terms and parameters used remain the same as in [32/RLN-V1](../draft/32/rln-v1.md),
+more details [here](../draft/32/rln-v1.md#technical-overview)

 ## RLN-Same flow

 ### Registration

-The registration process in the RLN-Same subprotocol does not differ from [32/RLN-V1](32/rln-v1.md).
+The registration process in the RLN-Same subprotocol does not differ from [32/RLN-V1](../draft/32/rln-v1.md).

 Signalling

@@ -117,7 +117,7 @@ internal_nullifier = poseidonHash([a_1])

 Registration

-**id_commitment** in [32/RLN-V1](32/rln-v1.md) is equal to `poseidonHash(identity_secret)`.
+**id_commitment** in [32/RLN-V1](../draft/32/rln-v1.md) is equal to `poseidonHash(identity_secret)`.
 The goal of RLN-Diff is to set different rate-limits for different users.
 It follows that **id_commitment** must somehow depend
 on the `user_message_limit` parameter,
@@ -128,7 +128,7 @@ There are few ways to do that:
 and zk proof that `user_message_limit` is valid (is in the right range).
 This approach requires zkSNARK verification,
 which is an expensive operation on the blockchain.
-2. Sending the same `identity_secret_hash` as in [32/RLN-V1](32/rln-v1.md)
+2. Sending the same `identity_secret_hash` as in [32/RLN-V1](../draft/32/rln-v1.md)
 (`poseidonHash(identity_secret)`) and a user_message_limit publicly to a server
 or smart-contract where
 `rate_commitment` = `poseidonHash(identity_secret_hash, userMessageLimit)` is calculated.
@@ -162,13 +162,13 @@ The Output is calculated in the same way as the RLN-Same sub-protocol.

 ### Verification and slashing

-Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](32/rln-v1.md).
+Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](../draft/32/rln-v1.md).
 The only difference that may arise is the `message_limit` check in RLN-Same,
 since it is now a public input of the Circuit.

 ### ZK Circuits specification

-The design of the [32/RLN-V1](32/rln-v1.md) circuits
+The design of the [32/RLN-V1](../draft/32/rln-v1.md) circuits
 is different from the circuits of this protocol.
 RLN-v2 requires additional algebraic constraints.
 The membership proof and Shamir's Secret Sharing constraints remain unchanged.
@@ -241,7 +241,7 @@ Outputs
 ## Appendix A: Security considerations

 Although there are changes in the circuits,
-this spec inherits all the security considerations of [32/RLN-V1](32/rln-v1.md).
+this spec inherits all the security considerations of [32/RLN-V1](../draft/32/rln-v1.md).

 ## Copyright

@@ -251,4 +251,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 * [1](https://zkresear.ch/t/rate-limit-nullifier-v2-circuits/102)
 * [2](https://github.com/Rate-Limiting-Nullifier/rln-circuits-v2)
-* [3](32/rln-v1.md#technical-overview)
+* [3](../draft/32/rln-v1.md#technical-overview)
@@ -116,4 +116,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ## References

- [logos service discovery](https://github.com/logos-co/logos-lips/blob/155c310d7bfad6ea3cd9f68e45c68dad731ff629/docs/anoncomms/raw/logos-service-discovery.md)
+- [logos service discovery](logos-service-discovery.md)
@@ -312,7 +312,7 @@ verifier module MUST extracts the `secret-hash` from two different message with
 (see [RLN Specification](https://lip.logos.co/anoncomms/raw/rln-v2.html)), and invoke the `Karma contract`
 for slashing which maps user’s Karma to `MinK-1` then adds the `user` to `denylist`.

-Note that, Zerokit contains [a function named comput_id_secret](https://github.com/vacp2p/zerokit/blob/master/rln/src/protocol.rs#L526)
+Note that, Zerokit contains [a function named comput_id_secret](https://github.com/vacp2p/zerokit/tree/master/rln/src/protocol)
 for extracting the secret-hash for a given two recurring `internal_nullifier`.

 ## 3. Smart Contracts
@@ -40,7 +40,7 @@ are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.tx

 ### Important Note

-All terms and parameters used remain the same as in [RLN-V2](rln-v2.md) and [RLN-V1](32/rln-v1.md#technical-overview).
+All terms and parameters used remain the same as in [RLN-V2](rln-v2.md) and [RLN-V1](../draft/32/rln-v1.md#technical-overview).

 ### Architecture Overview

@@ -171,7 +171,7 @@ but only one variant is compiled and available at runtime based on the enabled f
 `RLN::new_with_params(zkey_data)` - *Available in WASM | Stateless mode*

 - Creates a new stateless RLN instance for WASM with pre-loaded zkey data.
- Graph data is not required as witness calculation is handled externally in WASM environments (e.g., using [witness_calculator.js](https://github.com/vacp2p/zerokit/blob/master/rln-wasm/resources/witness_calculator.js)).
+- Graph data is not required as witness calculation is handled externally in WASM environments (e.g., using [witness_calculator.js](https://github.com/vacp2p/zerokit/tree/master/rln-wasm)).

 ### Key Generation

@@ -501,14 +501,14 @@ implement safeguards to prevent accidental violations.

 ### Normative

- [RLN-V1 Specification](32/rln-v1.md) - Rate Limit Nullifier V1 protocol
+- [RLN-V1 Specification](../draft/32/rln-v1.md) - Rate Limit Nullifier V1 protocol

 ### Informative

 - [Zerokit GitHub Repository](https://github.com/vacp2p/zerokit) - Reference implementation
 - [RLN-V2 Specification](rln-v2.md) - Rate Limit Nullifier V2 protocol
 - [Sled Database](https://sled.rs) - Embedded database for persistent Merkle tree storage
- [Witness Calculator](https://github.com/vacp2p/zerokit/blob/master/rln-wasm/resources/witness_calculator.js) - JavaScript witness calculator for WASM environments
+- [Witness Calculator](https://github.com/vacp2p/zerokit/tree/master/rln-wasm) - JavaScript witness calculator for WASM environments

 ## Copyright

@@ -553,7 +553,7 @@ The algorithm only requires that nodes have computed the drift of
 observation of the passage of local time, not that that they have
 coordinated an absolute time with their peers.  For an implementation
 of a phase locked-loop feedback to measure local clock drift see
-[NTP](https://www.rfc-editor.org/rfc/rfc5905.html).
+[NTP](https://datatracker.ietf.org/doc/html/rfc5905).

 ## Further points

@@ -746,7 +746,7 @@ they should be of stable interest no matter if Claro isn't.

 ## Normative References

-0. [Claro](<https://rdf.logos.co/protocol/Claro/1/0/0/raw>)
+0. [Claro](#consensus-claro)

 1. [n3](<https://www.w3.org/DesignIssues/Notation3.html>)

@@ -138,7 +138,7 @@ The matrix representation has $k$ columns which include $\ell$ chunks each.
 The row and column numbers used in the representation are decided
 based on the size of the block data and the number of DA nodes.

-![Data Matrix Structure](da-cryptographic-protocol/assets/da-data-matrix.png)
+![Data Matrix Structure](../raw/da-cryptographic-protocol/assets/da-data-matrix.png)

 *Figure 1: Data matrix structure showing chunks and columns.
 Each chunk is a 31-byte element, and each column contains $\ell$ chunks.*
@@ -181,7 +181,7 @@ The current design of DA Network uses an expansion factor of 2,
 but it can also work with different factors.
 This expanded data matrix has rows of length $2k$.

-![Extended Data Matrix](da-cryptographic-protocol/assets/da-extended-matrix.png)
+![Extended Data Matrix](../raw/da-cryptographic-protocol/assets/da-extended-matrix.png)

 *Figure 2: Extended data matrix showing original data ($k$ columns)
 and extended data ($2k$ columns total) after Reed-Solomon expansion.*
@@ -197,7 +197,7 @@ a more efficient technique using random linear combinations of row polynomials i
 allowing only one proof to be generated per column
 while still ensuring the validity of all underlying row data.

-![Encoding Pipeline](da-cryptographic-protocol/assets/da-encoding-pipeline.png)
+![Encoding Pipeline](../raw/da-cryptographic-protocol/assets/da-encoding-pipeline.png)

 *Figure 3: Complete encoding pipeline showing row commitments (step 1),
 RS-encoding (step 2), and combined row commitment with column data (step 3).*
@@ -265,7 +265,7 @@ to every other node in the subnet.
 A DA node that receives the column information described above
 performs the following checks:

-![Dispersal and Verification](da-cryptographic-protocol/assets/da-dispersal-verification.png)
+![Dispersal and Verification](../raw/da-cryptographic-protocol/assets/da-dispersal-verification.png)

 *Figure 4: Dispersal and verification flow from Encoder to DA Node.
 The DA Node receives row commitments, column data, and combined proof,
@@ -301,7 +301,7 @@ A sampling client, such as a light node, selects a random column index $`s \in \
 It sends a request for column $s$ to a DA node hosting that column's data.
 The DA node sends the client the column data $`data^{s}_{i}`$ and the combined proof $`\pi_s`$.

-![Sampling](da-cryptographic-protocol/assets/da-sampling.png)
+![Sampling](../raw/da-cryptographic-protocol/assets/da-sampling.png)

 *Figure 5: Sampling flow between DA Node and Sampling Client.
 The client requests a random column index $s$, receives the column data and proof,
@@ -582,7 +582,7 @@ $$`e(a * g_1, b * g_2) = e(g_1, g_2)^{ab}`$$
 [rfc-2119]: https://www.ietf.org/rfc/rfc2119.txt
 [origin-ref]: da-cryptographic-protocol.md
 [bls12-381]: https://hackmd.io/@benjaminion/bls12-381
-[ec-pairings]: https://vitalik.ca/general/2017/01/14/exploring_ecp.html
+[ec-pairings]: https://vitalik.eth.limo/general/2017/01/14/exploring_ecp.html

 ## Copyright

@@ -112,7 +112,7 @@ and replicated data.

 ### DA Network Registration

-Entities wishing to participate in DA Network must declare their role via [SDP](bedrock-service-declaration-protocol.md) (Service Declaration Protocol).
+Entities wishing to participate in DA Network must declare their role via [SDP](../raw/bedrock-service-declaration-protocol.md) (Service Declaration Protocol).
 Once declared, they're accounted for in the subnetwork construction.

 This enables participation in:
@@ -183,7 +183,7 @@ Replication occurs once per blob; subsequent validations of the same blob are di
 2. The node selects `sample_size` random subnetworks
 and queries each for the availability of the corresponding column for the sampled blob. Sampling is deemed successful only if all queried subnetworks respond affirmatively.

- If `num_subnets` is 2048, `sample_size` is [20 as per the sampling research](analysis-resilience-and-anonymity/appendices/analysis-of-rewarding-in-data-availability-network.md)
+- If `num_subnets` is 2048, `sample_size` is [20 as per the sampling research](../raw/analysis-resilience-and-anonymity/appendices/analysis-of-rewarding-in-data-availability-network.md)

 ```mermaid
 sequenceDiagram
@@ -258,9 +258,9 @@ ensures the overlay node distribution is scalable for networks of any size.
 - [DA Network Sampling](da-network.md#sampling)
 - [DA Network Reconstruction](da-network.md)
 - [DA Network Indexing](da-network.md)
- [SDP](bedrock-service-declaration-protocol.md)
+- [SDP](../raw/bedrock-service-declaration-protocol.md)
 - [invoked based on the node's current role](da-network.md#sampling)
- [20 as per the sampling research](analysis-resilience-and-anonymity/appendices/analysis-of-rewarding-in-data-availability-network.md)
+- [20 as per the sampling research](../raw/analysis-resilience-and-anonymity/appendices/analysis-of-rewarding-in-data-availability-network.md)
 - [multiplexed](https://docs.libp2p.io/concepts/transports/quic/#quic-native-multiplexing)
 - [QUIC](https://docs.libp2p.io/concepts/transports/quic/)

@@ -416,8 +416,8 @@ to guarantee rewards for malicious nodes.

 [rfc-2119]: https://www.ietf.org/rfc/rfc2119.txt
 [origin-ref]: da-rewarding.md
-[sdp]: bedrock-service-declaration-protocol.md
-[sampling-analysis]: analysis-resilience-and-anonymity/appendices/analysis-of-rewarding-in-data-availability-network.md
+[sdp]: ../raw/bedrock-service-declaration-protocol.md
+[sampling-analysis]: ../raw/analysis-resilience-and-anonymity/appendices/analysis-of-rewarding-in-data-availability-network.md

 ## Copyright

@@ -238,7 +238,7 @@ Kiayias, A., Russell, A., David, B. and Oliynykov, R. (2016). *Ouroboros: A Prov
 Kohlweiss, M., Madathil, V., Nayak, K. and Scafuro, A. (2021). On the Anonymity Guarantees of Anonymous Proof-of-Stake Protocols. *Edinburgh Research Explorer (University of Edinburgh)*. doi:[https://doi.org/10.1109/sp40001.2021.00107](https://doi.org/10.1109/sp40001.2021.00107).
 Logos.co. (2025). *Logos - A Declaration of Independence in Cyberspace | Logos Network*. [online] Available at: [https://logos.co/](https://logos.co/) [Accessed 21 May 2025].
 Neuder, M. and Drake, J. (2023). *Execution Tickets*. [online] Ethereum Research. Available at: [https://ethresear.ch/t/execution-tickets/17944](https://ethresear.ch/t/execution-tickets/17944) [Accessed 21 May 2025].
-RISC Zero. (2025). *RISC Zero*. [online] Available at: [http://risc0.com](http://risc0.com) [Accessed 21 May 2025].
+RISC Zero. (2025). *RISC Zero*. [online] Available at: [https://www.risc0.com/](https://www.risc0.com/) [Accessed 21 May 2025].
 Sun Yin, A. (2023). *An Introduction to Intents and Intent-centric Architectures | Research - Anoma*. [online] Anoma.net. Available at: [https://anoma.net/blog/an-introduction-to-intents-and-intent-centric-architectures](https://anoma.net/blog/an-introduction-to-intents-and-intent-centric-architectures) [Accessed 21 May 2025].
 Syverson, P. (2009). *Why I’m Not an Entropist*. [online] *<https://gwern.net/doc/cs/security/2009-syverson.pdf>*. Available at: [https://gwern.net/doc/cs/security/2009-syverson.pdf](https://gwern.net/doc/cs/security/2009-syverson.pdf) [Accessed 20 May 2025].
 Waku.org. (2024). *Waku is Uncompromising Web3 Communication at Scale | Waku*. [online] Available at: [https://waku.org/](https://waku.org/) [Accessed 21 May 2025].
@@ -202,7 +202,7 @@ If adoption grows and the burning rate exceeds $`I_{max}`$, then the token suppl

 [HackMDMinimum Viable Issuance - HackMD](https://notes.ethereum.org/@anderselowsson/MinimumViableIssuance)

-[Titania ResearchExploring Minimum Viable Issuance (MVI)](https://titaniaresear.ch/minimum-viable-issuance)
+[Titania ResearchExploring Minimum Viable Issuance (MVI)](https://notes.ethereum.org/@anderselowsson/MinimumViableIssuance)

 [HackMDProperties of issuance level (part 1) - HackMD](https://notes.ethereum.org/@anderselowsson/HyUIqjo_6)

@@ -179,7 +179,7 @@ EdDSA is a digital-signature scheme built on twisted Edwards curves. Ed25519 is
 Technical Details:

 - Curve: Twisted Edwards curve Edwards25519 (it is birationally equivalent to Curve25519):
-    $`(x,y) \in \big(\mathbb{Z}/(2^{255}-19) \mathbb{Z}\big)^2`$ such that $`-x^2 + y^2 = 1 - (121665/121666)x^2y^2`$.
+  $`(x,y) \in \big(\mathbb{Z}/(2^{255}-19) \mathbb{Z}\big)^2`$ such that $`-x^2 + y^2 = 1 - (121665/121666)x^2y^2`$.
 - Signature Size: 64 bytes.
 - Public Key Size: 32 bytes.
 - Security Level: Approximately 128 bits.
@@ -10,6 +10,7 @@
 | Source | [logos-blockchain/logos-execution-zone docs/specs.md](https://github.com/logos-blockchain/logos-execution-zone/blob/schouhy/add-specs/docs/specs.md) |


+
 ## LEE v0.3 basic types and constants

 ```rust
@@ -81,12 +81,12 @@ struct Foo

 Logos Blockchain messages are encoded using bincode - a compact binary serialization format with zero overhead. The format is defined as "a compact encoder/decoder pair that uses a binary zero-fluff encoding scheme." Bincode has been battle-tested in other blockchain protocol implementations, making it production-ready.

-The complete specification can be found in the [official documentation](https://git.sr.ht/~stygianentity/bincode/tree/trunk/item/docs/spec.md).
+The complete specification can be found in the [official documentation](https://docs.rs/bincode/latest/bincode/).

 # Reference

 - [C structure layout](https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Structure-Layout.html)
 - [Rust](https://doc.rust-lang.org/nomicon/other-reprs.html#reprc)[repr(c)](https://doc.rust-lang.org/nomicon/other-reprs.html#reprc)
- [Bincode serialization specification](https://git.sr.ht/~stygianentity/bincode/tree/trunk/item/docs/spec.md)
+- [Bincode serialization specification](https://docs.rs/bincode/latest/bincode/)
 - [Bincode rust crate docs](https://docs.rs/bincode/2.0.1/bincode/)

@@ -93,17 +93,17 @@ RPC call to query historical messages.
 this field MAY be filled out to signify the starting point of the queried time window.
 This field holds the Unix epoch time in nanoseconds.  
 The `messages` field of the corresponding
-[`HistoryResponse`](../draft/13/store.md#HistoryResponse)
+[`HistoryResponse`](../draft/13/store.md#store-query-response)
 MUST contain historical waku messages whose
-[`timestamp`](../stable/14/message.md#Payloads)
+[`timestamp`](../stable/14/message.md#message-attributes)
 is larger than or equal to the `start_time`.
 - `end_time`:
 this field MAY be filled out to signify the ending point of the queried time window.
 This field holds the Unix epoch time in nanoseconds.
 The `messages` field of the corresponding
-[`HistoryResponse`](../draft/13/store.md#HistoryResponse)
+[`HistoryResponse`](../draft/13/store.md#store-query-response)
 MUST contain historical waku messages whose
-[`timestamp`](../stable/14/message.md#Payloads) is less than or equal to the `end_time`.
+[`timestamp`](../stable/14/message.md#message-attributes) is less than or equal to the `end_time`.

 A time-based query is considered valid if
 its `end_time` is larger than or equal to the `start_time`.
@@ -122,7 +122,7 @@ then the history query SHOULD be made for `[start_time: l - 20s, end_time: r + 2

 Note that `HistoryQuery` preserves `AND` operation among the queried attributes.
 As such, the `messages` field of the corresponding
-[`HistoryResponse`](../draft/13/store.md#HistoryResponse)
+[`HistoryResponse`](../draft/13/store.md#store-query-response)
 MUST contain historical waku messages that satisfy the indicated  `pubsubtopic` AND
 `contentFilters` AND the time range [`start_time`, `end_time`].

@@ -134,4 +134,4 @@ Copyright and related rights waived via
 ## References

 - [13/WAKU2-STORE](../draft/13/store.md)
- [`timestamp`](../stable/14/message.md#Payloads)
+- [`timestamp`](../stable/14/message.md#message-attributes)
@@ -470,7 +470,7 @@ The following structured types are defined for use on the Filter API:
 ### `post_waku_v2_filter_v1_subscription`

 The `post_waku_v2_filter_v1_subscription` method creates a subscription in a
-[light node](../../draft/12/filter.md#rationale) for messages that matches a content filter
+[light node](../../draft/12/filter.md) for messages that matches a content filter
 and, optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor).

 Parameters
@@ -488,7 +488,7 @@ an [error](https://www.jsonrpc.org/specification#error_object) on failure.
 `delete_waku_v2_filter_v1_subscription`

 The `delete_waku_v2_filter_v1_subscription` method removes subscriptions
-in a [light node](../../draft/12/filter.md#rationale) matching a content filter and,
+in a [light node](../../draft/12/filter.md) matching a content filter and,
 optionally, a [PubSub `topic`](https://github.com/libp2p/specs/blob/master/pubsub/README.md#the-topic-descriptor).

 Parameters
@@ -76,7 +76,7 @@ A node SHOULD relay messages to all connected nodes
 if an envelope matches their PoW and bloom filter settings.
 If a node works in light mode, it MAY choose not to forward envelopes.
 A node MUST NOT send expired envelopes,
-unless the envelopes are sent as a [mailserver](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/waku-mailserver.md) response.
+unless the envelopes are sent as a [mailserver](../../stable/8/mail.md) response.
 A node SHOULD NOT send a message to a peer that it has already sent before.

 ## Wire Specification
@@ -87,7 +87,7 @@ All Waku messages are sent as devp2p RLPx transport protocol,
 version 5[^1] packets.
 These packets MUST be RLP-encoded arrays of data containing two objects:
 packet code followed by another object (whose type depends on the packet code).
- See [informal RLP spec](https://github.com/ethereum/wiki/wiki/RLP) and
+ See [informal RLP spec](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) and
 the [Ethereum Yellow Paper, appendix B](https://ethereum.github.io/yellowpaper/paper.pdf)
 for more details on RLP.

@@ -413,7 +413,7 @@ a corresponding confirmation is broadcast by one or more peers.
 #### P2P Request

 This packet is used for sending Dapp-level peer-to-peer requests,
-e.g. Waku Mail Client requesting old messages from the [Waku Mail Server](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/waku-mailserver.md).
+e.g. Waku Mail Client requesting old messages from the [Waku Mail Server](../../stable/8/mail.md).

 #### P2P Message

@@ -453,7 +453,7 @@ Here we list these capabilities, how they are identified,
 what properties they have and what invariants they must maintain.

 Additionally there is the capability of a mailserver
-which is documented in its on [specification](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/waku-mailserver.md).
+which is documented in its on [specification](../../stable/8/mail.md).

 ### Light node

@@ -592,7 +592,7 @@ when receiving `status-options` with unknown option keys.
 There are several security considerations to take into account when running Waku.
 Chief among them are: scalability, DDoS-resistance and privacy.
 These also vary depending on what capabilities are used.
-The security considerations for extra capabilities such as [mailservers](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/waku-mailserver.md#security-considerations)
+The security considerations for extra capabilities such as [mailservers](../../stable/8/mail.md#security-considerations)
 can be found in their respective specifications.

 ### Scalability and UX
@@ -672,8 +672,8 @@ See libp2p and Tor's Pluggable Transport for how this can be improved.

 | Client | Spec supported | Details |
 |--------|----------------|---------|
-| **Status-go** | 0.5 | [details](https://github.com/status-im/status-go/blob/develop/WAKU.md) |
-| **Nimbus** | 0.4 | [details](https://github.com/status-im/nimbus/tree/8747fe1ecd36fe778bb92b97634db84d364fede8/waku) |
+| **Status-go** | 0.5 | [details](https://github.com/status-im/status-go) |
+| **Nimbus** | 0.4 | [details](https://github.com/status-im/nimbus-eth1) |

 ### Recommendations for clients

@@ -702,13 +702,13 @@ Known static nodes MAY also be used.

 ### Version 0.6

-Released [April 21,2020](https://github.com/vacp2p/specs/commit/9e650995f24179844857520c68fa3e8f6018b125)
+Released [April 21,2020](https://github.com/vacp2p/specs)

 - Mark spec as Deprecated mode in terms of its lifecycle.

 ### Version 0.5

-Released [March 17,2020](https://github.com/vacp2p/specs/commit/7b9dc562bc50c6bb844ac575cb221ec9cda2530a)
+Released [March 17,2020](https://github.com/vacp2p/specs)

 - Clarify the preferred way of handling unknown keys
 in the `status-options` association list.
@@ -717,7 +717,7 @@ Change RLP keys to be the their int values in order to reflect production behavi

 ### Version 0.4

-Released [February 21, 2020](https://github.com/vacp2p/specs/commit/17bd066e317bbe33af07146b721d73f24de47e88).
+Released [February 21, 2020](https://github.com/vacp2p/specs).

 - Simplify implementation matrix with latest state
 - Introduces a new required packet code Status Code (`0x22`)
@@ -729,7 +729,7 @@ Topic interest (`0x21`) - all superseded by the new Status Code (`0x22`)

 ### Version 0.3

-Released [February 13, 2020](https://github.com/vacp2p/specs/commit/73138d6ba954ab4c315e1b8d210ac7631b6d1428).
+Released [February 13, 2020](https://github.com/vacp2p/specs).

 - Recommend DNS based node discovery over other Discovery methods.
 - Mark spec as Draft mode in terms of its lifecycle.
@@ -742,7 +742,7 @@ specifying options as association list.

 ### Version 0.2

-Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/waku.md).
+Released [December 10, 2019](https://github.com/vacp2p/specs).

 - General style improvements.
 - Fix ABNF grammar.
@@ -761,7 +761,7 @@ implementation matrix across various clients with breakdown per capability.

 ### Version 0.1

-Initial version. Released [November 21, 2019](https://github.com/vacp2p/specs/blob/b59b9247f2ac1bf45c75bd3227a2e5dd87b6d7b0/waku.md).
+Initial version. Released [November 21, 2019](https://github.com/vacp2p/specs).

 ### Differences between shh/6 and waku/0

@@ -457,7 +457,7 @@ of their connections and remove peers with a low score.

 Confidentiality can be addressed through data encryption whereas integrity and
 authenticity are achievable through digital signatures.
-These features are provided for in [14/WAKU2-MESSAGE (version 1)](/messaging/stable/14/message.md#version-1)`
+These features are provided for in [14/WAKU2-MESSAGE (version 1)](../../stable/14/message.md#payload-encryption)`
 through payload encryption as well as encrypted signatures.

 ### Security Considerations
@@ -491,9 +491,9 @@ the security features of each layer-->

 There are multiple implementations of Waku and its protocols:

- [nim-waku (Nim)](https://github.com/status-im/nim-waku/)
+- [nim-waku (Nim)](https://github.com/logos-messaging/logos-delivery/)
 - [go-waku (Go)](https://github.com/status-im/go-waku/)
- [js-waku (NodeJS and Browser)](https://github.com/status-im/js-waku/)
+- [js-waku (NodeJS and Browser)](https://github.com/logos-messaging/logos-delivery-js/)

 Below you can find an overview of the specifications that they implement
 as they relate to Waku.
@@ -630,11 +630,11 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 27. [GossipSub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md)

-28. [nim-waku (Nim)](https://github.com/status-im/nim-waku/)
+28. [nim-waku (Nim)](https://github.com/logos-messaging/logos-delivery/)

 29. [go-waku (Go)](https://github.com/status-im/go-waku/)

-30. [js-waku (NodeJS and Browser)](https://github.com/status-im/js-waku/)
+30. [js-waku (NodeJS and Browser)](https://github.com/logos-messaging/logos-delivery-js/)

 31. [8/WAKU-MAIL](/messaging/stable/8/mail.md)

@@ -103,7 +103,7 @@ If Bob's private key is compromised, past and future messages could be decrypted
 A solution combining regular [X3DH](https://www.signal.org/docs/specifications/x3dh/)
 bundle broadcast with [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
 encryption would remove these limitations;
-See the [Status secure transport specification](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/secure-transport.md)
+See the [Status secure transport specification](https://github.com/status-im/status-specs)
 for an example of a protocol that achieves this in a peer-to-peer setting.

 Bob MUST decide to participate in the protocol before Alice can send him a message.
@@ -286,7 +286,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [Waku Message Version 1](../26/payload.md)
 - [X3DH](https://www.signal.org/docs/specifications/x3dh/)
 - [Double Ratchet](https://signal.org/docs/specifications/doubleratchet/)
- [Status secure transport specification](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/secure-transport.md)
+- [Status secure transport specification](https://github.com/status-im/status-specs)
 - [EIP-712](https://eips.ethereum.org/EIPS/eip-712)
 - [13/WAKU2-STORE](/messaging/draft/13/store.md)
 - [The Graph](https://thegraph.com/)
@@ -37,9 +37,9 @@ This protocol is mainly used to:
 2. Show an example of how to use Waku v2.

 Currently, all main Waku v2 implementations support the toy chat protocol:
-[nim-waku](https://github.com/status-im/nim-waku/blob/master/examples/v2/chat2.nim),
-js-waku ([NodeJS](https://github.com/status-im/js-waku/tree/main/examples/cli-chat)
- and [web](https://github.com/status-im/js-waku/tree/main/examples/web-chat))
+[nim-waku](https://github.com/logos-messaging/logos-delivery),
+js-waku ([NodeJS](https://github.com/logos-messaging/logos-delivery-js)
+ and [web](https://github.com/logos-messaging/logos-delivery-js))
 and [go-waku](https://github.com/status-im/go-waku/tree/master/examples/chat2).

 Note that this is completely separate from the protocol the Status app
@@ -68,10 +68,10 @@ in a hierarchical way as well.

 > *Note*: In previous versions of this document, the structure was `/waku/2/{topic-name}/{encoding}`.
 The now deprecated `/{encoding}` was always set to `/proto`,
-which indicated that the [data field](/messaging/stable/11/relay.md#protobuf-definition)
+which indicated that the [data field](../../stable/11/relay.md#protobuf-definitions)
 in pubsub is serialized/encoded as protobuf.
 The inspiration for this format was taken from
-[Ethereum 2 P2P spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#topics-and-messages).
+[Ethereum 2 P2P spec](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#topics-and-messages).
 However, because the payload of messages transmitted over [11/WAKU2-RELAY](/messaging/stable/11/relay.md)
 must be a [14/WAKU2-MESSAGE](/messaging/stable/14/message.md),
 which specifies the wire format as protobuf,`/proto` is the only valid encoding.
@@ -154,7 +154,7 @@ and depends on the problem domain.
 It can be hierarchical, for instance to separate content, or
 to indicate different bandwidth and privacy guarantees.
 The encoding field indicates the serialization/encoding scheme
-for the [WakuMessage payload](/messaging/stable/14/message.md#payloads) field.
+for the [WakuMessage payload](../../stable/14/message.md#message-attributes) field.

 ### Content Topic usage guidelines

@@ -224,7 +224,7 @@ Copyright and related rights waived via
 - [10/WAKU2 spec](/messaging/draft/10/waku2.md)
 - [11/WAKU2-RELAY](/messaging/stable/11/relay.md)
 - [RELAY-SHARDING](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/raw/relay-sharding.md)
- [Ethereum 2 P2P spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#topics-and-messages)
+- [Ethereum 2 P2P spec](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#topics-and-messages)
 - [14/WAKU2-MESSAGE](/messaging/stable/14/message.md)
 - [12/WAKU2-FILTER](/messaging/draft/12/filter.md)
 - [13/WAKU2-STORE](/messaging/draft/13/store.md)
@@ -39,7 +39,7 @@ This specification describes how Waku provides confidentiality, authenticity, an
 integrity, as well as some form of unlinkability.
 Specifically, it describes how encryption, decryption and
 signing works in [6/WAKU1](../../stable/6/waku1.md) and
-in [10/WAKU2](../10/waku2.md) with [14/WAKU-MESSAGE](../../stable/14/message.md#version1).
+in [10/WAKU2](../10/waku2.md) with [14/WAKU-MESSAGE](../../stable/14/message.md#payload-encryption).

 This specification effectively replaces [7/WAKU-DATA](../../stable/7/data.md)
 as well as [6/WAKU1 Payload encryption](../../stable/6/waku1.md#payload-encryption)
@@ -230,11 +230,11 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 1. [6/WAKU1](../../stable/6/waku1.md)
 2. [10/WAKU2 spec](../10/waku2.md)
-3. [14/WAKU-MESSAGE version 1](../../stable/14/message.md#version1)
+3. [14/WAKU-MESSAGE version 1](../../stable/14/message.md#payload-encryption)
 4. [7/WAKU-DATA](../../stable/7/data.md)
 5. [EIP-627: Whisper spec](https://eips.ethereum.org/EIPS/eip-627)
 6. [RLPx Transport Protocol spec (ECIES encryption)](https://github.com/ethereum/devp2p/blob/master/rlpx.md#ecies-encryption)
-7. [Status 5/SECURE-TRANSPORT](https://github.com/status-im/status-specs/tree/master/specs/status/deprecated/secure-transport.md)
+7. [Status 5/SECURE-TRANSPORT](https://github.com/status-im/status-specs)
 8. [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234)
 9. [Ethereum "Yellow paper": Appendix F Signing transactions](https://ethereum.github.io/yellowpaper/paper.pdf)
 10. [authenticated encryption](https://en.wikipedia.org/wiki/Authenticated_encryption)
@@ -184,7 +184,7 @@ We define a `waku2` field key:
 - A Waku node MAY choose to populate the `waku2` field for enhanced discovery capabilities,
  such as indicating supported protocols.
  Such a node MAY indicate support for any specific protocol by setting the corresponding flag to `true`.
- Waku nodes that want to participate in [Node Discovery Protocol v5](https://github.com/logos-co/logos-lips/blob/main/waku/standards/core/33/discv5.md) [[4]](#references), however,
+- Waku nodes that want to participate in [Node Discovery Protocol v5](../33/discv5.md) [[4]](#references), however,
  MUST implement the `waku2` key with at least one flag set to `true`.
 - Waku nodes that discovered other participants using Discovery v5,
  MUST filter out participant records that do not implement this field or
@@ -200,7 +200,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References

 - [1](../10/waku2.md)
- [2](https://github.com/status-im/nim-waku/pull/690)
+- [2](https://github.com/logos-messaging/logos-delivery/pull/690)
 - [3](https://github.com/vacp2p/rfc/issues/462#issuecomment-943869940)
 - [4](https://eips.ethereum.org/EIPS/eip-778)
 - [5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)
@@ -114,7 +114,7 @@ This protocol uses the following cryptographic primitives:
  - Elliptic curve Diffie-Hellman key exchange (Curve25519)
  - AES-256-CTR with HMAC-SHA-256 and IV derived alongside an encryption key

-    The node achieves key derivation using [HKDF](https://www.rfc-editor.org/rfc/rfc5869).
+    The node achieves key derivation using [HKDF](https://datatracker.ietf.org/doc/html/rfc5869).

 ### Pre-keys

@@ -332,7 +332,7 @@ Copyright and related rights waived via
 - [Protobuf](https://developers.google.com/protocol-buffers/)
 - [Off-the-Record protocol](https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html)
 - [The Waku v2 protocol](/messaging/draft/10/waku2.md)
- [HKDF](https://www.rfc-editor.org/rfc/rfc5869)
+- [HKDF](https://datatracker.ietf.org/doc/html/rfc5869)
 - [2/ACCOUNT](https://specs.status.im/spec/2#x3dh-prekey-bundles)
 - [reference wire format](https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L12)
 - [Symmetric key ratchet](https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet)
@@ -402,4 +402,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 * [14/WAKU2-MESSAGE](../../stable/14/message.md)
 * [gossipsub v1.1 validation](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators)
 * [WAKU2-RELAY-SHARDING](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/raw/relay-sharding.md)
-* [The Waku Network Config](https://github.com/waku-org/nwaku/blob/master/waku/factory/networks_config.nim#L31)
+* [The Waku Network Config](https://github.com/logos-messaging/logos-delivery)
@@ -10,6 +10,8 @@
 | Tags | chat |
 | Editor | Jazz Alyxzander <jazz@status.im> |

+
+
 # Abstract

 This specification defines a modular communication protocol framework for describing chat protocols. It introduces abstraction boundaries, and a component model for describing chat protocol functionality.
@@ -9,6 +9,8 @@
 | Category | Standards Track |
 | Editor | Jazzz <jazz@status.im> |

+
+
 ## Abstract

 This specification defines ContentFrame, a self-describing message format for decentralized chat networks.
@@ -24,7 +24,7 @@
 This document specifies a deanonymization mitigation technique,
 based on [Dandelion](https://arxiv.org/abs/1701.04439) and [Dandelion++](https://arxiv.org/abs/1805.11060),
 for Waku Relay.
-It mitigates mass deanonymization in the [multi-node (botnet) attacker model](../../../informational/adversarial-models.md/#multi-node),
+It mitigates mass deanonymization in the [multi-node (botnet) attacker model](adversarial-models.md#multi-node),
 even when the number of malicious nodes is linear in the number of total nodes in the network.

 Based on the insight that symmetric message propagation makes deanonymization easier,
@@ -118,7 +118,7 @@ This does not include relaying messages originated in $v$, for which $v$ SHOULD

 On startup and when a new epoch starts,
 node $v$ randomly selects a number $r$ between 0 and 1.
-If $r < q$, for $q = 0.2$, the node enters fluff state, otherwise, it enters stem state.
+If $`r \lt q`$, for $q = 0.2$, the node enters fluff state, otherwise, it enters stem state.

 New epochs start when `unixtime` (in seconds) $\equiv 0 \mod 600$,
 corresponding to 10 minute epochs.
@@ -153,7 +153,7 @@ because these messages are only handed to gossipsub once they enter fluff phase.

 #### Fail Safe

-Nodes $v$ in stem state SHOULD store messages attached with a random timer between $t_1 = 5 * 100ms$ and $t_2 = 2 * t_1$.
+Nodes $v$ in stem state SHOULD store messages attached with a random timer between $`t_1 = 5 * 100ms`$ and $`t_2 = 2 * t_1`$.
 This time interval is chosen because

 - we assume $100\,ms$ as an average per hop delay, and
@@ -182,7 +182,7 @@ If this is the case, they have to be implemented on the libp2p gossipsub layer.

 ### Denial of Service: Black Hole Attack

-In a [black hole attack](../../../informational/adversarial-models.md/#black-hole-internal), malicious nodes prevent messages from being spread,
+In a [black hole attack](adversarial-models.md#black-hole-internal), malicious nodes prevent messages from being spread,
 metaphorically not allowing messages to leave once they entered.
 This requires the attacker to control nodes on all dissemination paths.
 Since the number of dissemination paths is significantly reduced in the stem phase,
@@ -195,7 +195,7 @@ The fail-safe mechanism specified in this document (proposed in the Dandelion pa
 #### Attacker Model and Anonymity Goals

 WAKU2-DANDELION provides significant mitigation against mass deanonymization in the
-passive [scaling multi node model](../../../informational/adversarial-models.md/#scaling-multi-node).
+passive [scaling multi node model](adversarial-models.md#scaling-multi-node).
 in which the attacker controls a certain percentage of nodes in the network.
 WAKU2-DANDELION provides significant mitigation against mass deanonymization
 even if the attacker knows the network topology, i.e. the anonymity graph and the relay mesh graph.
@@ -298,14 +298,14 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 - [Dandelion](https://arxiv.org/abs/1701.04439)
 - [Dandelion++](https://arxiv.org/abs/1805.11060)
- [multi-node (botnet) attacker model](../../../informational/adversarial-models.md/#multi-node)
+- [multi-node (botnet) attacker model](adversarial-models.md#multi-node)
 - [Waku Relay](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/stable/11/relay.md)
 - [Waku v2](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/10/waku2.md)
 - [d-regular graph](https://en.wikipedia.org/wiki/Regular_graph)
 - [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
 - [Waku Privacy and Anonymity Analysis](https://vac.dev/wakuv2-relay-anon).
 - [On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies](https://arxiv.org/pdf/2201.11860.pdf)
- [Adversarial Models](../../../informational/adversarial-models.md)
+- [Adversarial Models](adversarial-models.md)
 - [14/WAKU2-MESSAGE](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/stable/14/message.md)
 - [29/WAKU-CONFIG](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/29/config.md)
 - [19/WAKU2-LIGHTPUSH](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/19/lightpush.md)
@@ -267,7 +267,7 @@ TransferPhase:
 ### Messages Nametag Derivation

 To reduce metadata leakages and increase devices's anonymity over the p2p network,
-[WAKU2-NOISE](noise.md#session-states) suggests to use some common secrets `mntsInbound, mntsOutbound` (e.g. `mntsInbound, mntsOutbound = HKDF(h)`
+[WAKU2-NOISE](noise-sessions.md#session-states) suggests to use some common secrets `mntsInbound, mntsOutbound` (e.g. `mntsInbound, mntsOutbound = HKDF(h)`
 where `h` is the [handshake hash value](https://noiseprotocol.org/noise.html#overview-of-handshake-state-machine) of the Handshake State at some point of the pairing phase)
 in order to frequently and deterministically change the `messageNametag` of messages exchanged during the pairing and transfer phase -
 ideally, at each message exchanged.
@@ -380,7 +380,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### Normative

- [35/WAKU2-NOISE](noise.md#session-states)
+- [35/WAKU2-NOISE](noise-sessions.md#session-states)
 - [WAKU2-NOISE-SESSIONS](noise-sessions.md)

 ### Informative
@@ -212,7 +212,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### normative

- A high-level [incentivization outline](https://github.com/waku-org/research/blob/master/incentivization.md)
+- A high-level [incentivization outline](https://github.com/logos-messaging/research)
 - [19/WAKU2-LIGHTPUSH](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/19/lightpush.md) (for Lightpush-specific sections)

 ### informative
@@ -10,6 +10,8 @@
 | Tags | core, encoding |
 | Editor | Patryk <patryk@status.im>, Jazzz <jazz@status.im> |

+
+
 ## Abstract

 This specification defines the encoding format for Introduction Bundles — the
@@ -146,9 +148,9 @@ Copyright and related rights waived via [CC0].
 ## References

 - [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) — Key words for use in RFCs
- [RFC 4648 §5](https://www.rfc-editor.org/rfc/rfc4648#section-5) — Base 64 Encoding with URL and Filename Safe Alphabet
+- [RFC 4648 §5](https://datatracker.ietf.org/doc/html/rfc4648#section-5) — Base 64 Encoding with URL and Filename Safe Alphabet
 - [CC0](https://creativecommons.org/publicdomain/zero/1.0/) — Creative Commons Zero Public Domain Dedication

 [RFC 2119]: https://www.ietf.org/rfc/rfc2119.txt
-[RFC 4648 §5]: https://www.rfc-editor.org/rfc/rfc4648#section-5
+[RFC 4648 §5]: https://datatracker.ietf.org/doc/html/rfc4648#section-5
 [CC0]: https://creativecommons.org/publicdomain/zero/1.0/
@@ -336,7 +336,7 @@ If the `mode` set is `edge`, the initialised `WakuNode` SHOULD use:
 - [STORE](https://lip.logos.co/messaging/draft/13/store.html) as client
 - [METADATA](https://lip.logos.co/messaging/draft/66/metadata.html) as client
 - [PEER-EXCHANGE](https://lip.logos.co/messaging/draft/34/peer-exchange.html) as client
- [P2P-RELIABILITY](/standards/application/p2p-reliability.md)
+- [P2P-RELIABILITY](p2p-reliability.md)

 If the `mode` set is `core`, the initialised `WakuNode` SHOULD use:

@@ -345,7 +345,7 @@ If the `mode` set is `core`, the initialised `WakuNode` SHOULD use:
 - [FILTER](https://lip.logos.co/messaging/draft/12/filter.html) as service node
 - [STORE](https://lip.logos.co/messaging/draft/13/store.html) as client
 - [METADATA](https://lip.logos.co/messaging/draft/66/metadata.html) as client and service node
- [P2P-RELIABILITY](/standards/application/p2p-reliability.md)
+- [P2P-RELIABILITY](p2p-reliability.md)
 - [DISCV5](https://lip.logos.co/messaging/draft/33/discv5.html)
 - [PEER-EXCHANGE](https://lip.logos.co/messaging/draft/34/peer-exchange.html) as client and service node
 - [RENDEZVOUS](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/raw/rendezvous.md) as client and service node
@@ -454,7 +454,7 @@ functions:

 A first `message` sent with a certain `contentTopic` SHOULD trigger a subscription for such `contentTopic` as described in the `Subscriptions` section.

-The node uses [P2P-RELIABILITY](/standards/application/p2p-reliability.md) strategies to ensure message delivery.
+The node uses [P2P-RELIABILITY](p2p-reliability.md) strategies to ensure message delivery.

 ### Subscriptions

@@ -503,9 +503,9 @@ functions:

 **`mode`**:

-If the `mode` set is `edge`, `subscribe` SHOULD trigger set up a subscription using [FILTER](https://lip.logos.co/messaging/draft/12/filter.html) as client and [P2P-RELIABILITY](/standards/application/p2p-reliability.md).
+If the `mode` set is `edge`, `subscribe` SHOULD trigger set up a subscription using [FILTER](https://lip.logos.co/messaging/draft/12/filter.html) as client and [P2P-RELIABILITY](p2p-reliability.md).

-If the `mode` set is `core`, `subscribe` SHOULD trigger set up a subscription using [RELAY](https://lip.logos.co/messaging/stable/11/relay.html) and [P2P-RELIABILITY](/standards/application/p2p-reliability.md).
+If the `mode` set is `core`, `subscribe` SHOULD trigger set up a subscription using [RELAY](https://lip.logos.co/messaging/stable/11/relay.html) and [P2P-RELIABILITY](p2p-reliability.md).
 This MAY trigger joining a new shard if not already set.

 Only messages on subscribed content topics SHOULD be emitted by a `MessageEvents` event source, meaning messages received via `RELAY` SHOULD be filtered by content topics before emission.
@@ -515,7 +515,7 @@ Only messages on subscribed content topics SHOULD be emitted by a `MessageEvents
 Only irremediable failures should lead to synchronously returning a subscription error for failed subscribe or unsubscribe operations.

 Failure to reach nodes can be omitted, and should be handled via the health events;
-[P2P-RELIABILITY](/standards/application/p2p-reliability.md) SHOULD handle automated re-subscriptions and redundancy.
+[P2P-RELIABILITY](p2p-reliability.md) SHOULD handle automated re-subscriptions and redundancy.

 Examples of irremediable failures are:

@@ -59,7 +59,7 @@ A Noise session corresponding to a certain `session-id`:

 - is always **active** as long as it is not marked as **stale**.
  For an active `session-id`, new messages are published on the content topic `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto`;
- is marked as **stale** if a [session termination message](noise.md#session-termination-message) containing `Hash(session-id)` is published on the content topic `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto`.
+- is marked as **stale** if a [session termination message](#session-states) containing `Hash(session-id)` is published on the content topic `/{application-name}/{application-version}/wakunoise/1/sessions/{ct-id}/proto`.
  Session information relative to stale sessions MAY be deleted from users' device, unless required for later channel binding purposes.

 When a Noise session is marked as stale, it means that one party requested its termination while being online,
@@ -99,9 +99,9 @@ messages should be encrypted and decrypted within the Noise session instantiated

 This is achieved through two main supported session management mechanisms that we called `N11M` and `NM`, respectively.

-### The $N11M$ session management mechanism
+### The `N11M` session management mechanism

-In a $N11M$ setting, each party's device shares the same Noise session information used to encrypt and decrypt messages exchanged with the other party.
+In an `N11M` setting, each party's device shares the same Noise session information used to encrypt and decrypt messages exchanged with the other party.

 ![N11M session management](images/N11M.png)

@@ -132,9 +132,9 @@ where encryption keys are changed every time a new message is exchanged.

 This session management mechanism is loosely based on the paper ["Multi-Device for Signal"](https://eprint.iacr.org/2019/1363.pdf).

-## The $NM$ session management mechanism
+## The `NM` session management mechanism

-In a $NM$ setting, we require all of $N$ Alice's devices to have an active Noise session with each of Bob's $M$ devices,
+In an `NM` setting, we require all of $N$ Alice's devices to have an active Noise session with each of Bob's $M$ devices,
 for a total of $NM$ concurrently active Noise sessions between Alice and Bob.

 ![NM session management](images/NM.png)
@@ -9,6 +9,8 @@
 | Category | Standards Track |
 | Editor | Jazz Alyxzander (@Jazzz) |

+
+
 # Abstract

 This specification defines PRIVATE1, a conversation protocol for establishing secure, full-duplex encrypted communication channels between two participants. PRIVATE1 provides end-to-end encryption with forward secrecy and post-compromise security using the Double Ratchet algorithm, combined with reliable message delivery via Scalable Data Sync (SDS) and efficient segmentation for transport-constrained environments.
@@ -65,8 +65,8 @@ but the discovery of these shards is managed by Waku.
 This is the RECOMMENDED default format for shards chosen by an app protocol.

 Static shards are managed in shard clusters of 1024 shards per cluster.
-Waku static sharding can manage $2^{16}$ shard clusters.
-Each shard cluster is identified by its index (between $0$ and $2^{16}-1$).
+Waku static sharding can manage $`2^{16}`$ shard clusters.
+Each shard cluster is identified by its index (between $0$ and $`2^{16}-1`$).

 It is RECOMMENDED that, for simplification of configuration and various APIs,
 all app-level protocols only interact with `cluster` and `shard`
@@ -77,7 +77,7 @@ A specific shard cluster is either globally available to all apps,
 specific for an app protocol,
 or reserved for automatic sharding (see next section).

-> _Note:_ This leads to $2^{16} * 1024 = 2^{26}$ shards for which Waku manages discovery.
+> _Note:_ This leads to $`2^{16} * 1024 = 2^{26}`$ shards for which Waku manages discovery.

 App protocols can either choose to use global shards, or app specific shards.

@@ -89,7 +89,7 @@ shard clusters are divided into ranges:
 | 0 - 15        | reserved             |
 | 16 - 65535    | app-defined networks |

-The informational RFC [WAKU2-RELAY-STATIC-SHARD-ALLOC](../../../informational/relay-static-shard-alloc.md) lists the current index allocations.
+The informational RFC [WAKU2-RELAY-STATIC-SHARD-ALLOC](relay-static-shard-alloc.md) lists the current index allocations.

 The global shard with index 0 and the "all app protocols" range are treated in the same way,
 but choosing shards in the global cluster has a higher probability of sharing the shard with other apps.
@@ -121,18 +121,18 @@ for shard 43 of the Status app (which has allocated index 16).
 Waku v2 supports the discovery of peers within static shards,
 so app protocols do not have to implement their own discovery method.

-Nodes add information about their shard participation in their [WAKU2-ENR](./enr.md).
+Nodes add information about their shard participation in their [WAKU2-ENR](../draft/31/enr.md).
 Having a static shard participation indication as part of the ENR allows nodes
 to discover peers that are part of shards via [33/WAKU2-DISCV5](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/33/discv5.md) as well as via DNS.

 > _Note:_ In the current version of this document,
 > sharding information is directly added to the ENR.
-> (see Ethereum ENR sharding bit vector [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata)
+> (see Ethereum ENR sharding bit vector [here](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/p2p-interface.md#metadata)
 > Static relay sharding supports 1024 shards per cluster, leading to a flag field of 128 bytes.
 > This already takes half (including index and key) of the ENR space of 300 bytes.
 > For this reason, the current specification only supports a single shard cluster per node.
 > In future versions, we will add further (hierarchical) discovery methods.
-> We will update [WAKU2-ENR](./enr.md) accordingly, once this RFC moves forward.
+> We will update [WAKU2-ENR](../draft/31/enr.md) accordingly, once this RFC moves forward.

 This document specifies two ways of indicating shard cluster participation.
 The index list SHOULD be used for nodes that participante in fewer than 64 shards,
@@ -172,8 +172,8 @@ The ENR key is `rsv`.
 The value is comprised of a two-byte shard cluster index in network byte order concatenated with a 128-byte wide bit vector.
 The bit vector indicates which shards of the respective shard cluster the node is part of.
 The right-most bit in the bit vector represents shard `0`, the left-most bit represents shard `1023`.
-The representation in the ENR is inspired by [Ethereum shard ENRs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#sync-committee-subnet-stability)),
-and [this](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#sync-committee-subnet-stability)).
+The representation in the ENR is inspired by [Ethereum shard ENRs](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/validator.md#sync-committee-subnet-stability)),
+and [this](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/validator.md#sync-committee-subnet-stability)).

 Example:

@@ -300,7 +300,7 @@ The transition to the second method will be seamless and fully backwards compati

 ## Security/Privacy Considerations

-See [WAKU2-ADVERSARIAL-MODELS](../../../informational/adversarial-models.md), especially the parts on k-anonymity.
+See [WAKU2-ADVERSARIAL-MODELS](adversarial-models.md), especially the parts on k-anonymity.
 We will add more on security considerations in future versions of this document.

 ### Receiver Anonymity
@@ -318,11 +318,11 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [11/WAKU2-RELAY](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/stable/11/relay.md)
 - [Unstructured P2P network](https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks)
 - [33/WAKU2-DISCV5](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/33/discv5.md)
- [WAKU2-ENR](./enr.md)
+- [WAKU2-ENR](../draft/31/enr.md)
 - [23/WAKU2-TOPICS](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/23/topics.md)
- [Ethereum ENR sharding bit vector](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#metadata)
+- [Ethereum ENR sharding bit vector](https://github.com/ethereum/consensus-specs/blob/master/specs/altair/p2p-interface.md#metadata)
 - [Ethereum discv5 specification](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md)
 - [Research log: Waku Discovery](https://vac.dev/wakuv2-apd)
- [WAKU2-RELAY-STATIC-SHARD-ALLOC](../../../informational/relay-static-shard-alloc.md)
+- [WAKU2-RELAY-STATIC-SHARD-ALLOC](relay-static-shard-alloc.md)
 - [14/WAKU2-MESSAGE](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/stable/14/message.md)
 - [64/WAKU2-NETWORK](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/64/network.md)
@@ -202,7 +202,7 @@ This API considers the types defined by [MESSAGING-API](messaging-api.md) plus t
 ### Channel lifecycle

 This point assumes that a WakuNode instance is created beforehand. See `createNode` function
-in [MESSAGING-API](/standards/application/messaging-api.md).
+in [MESSAGING-API](messaging-api.md).

 ```yaml
 functions:
@@ -255,7 +255,7 @@ and the membership set SHOULD be migrated.

 ### Membership Set Implementation

-The membership set MAY be implemented as a Merkle tree, such as an [Incremental Merkle Tree](https://zkkit.pse.dev/modules/_zk_kit_imt.html) (IMT).
+The membership set MAY be implemented as a Merkle tree, such as an [Incremental Merkle Tree](https://github.com/zk-kit/zk-kit) (IMT).

 ### Choosing Which _Expired_ Memberships to Reuse

@@ -105,7 +105,7 @@ Each contruct MUST include the keypair:
 The `membershipHash` SHOULD be generated by nodes participating in a membership group, 
 as decribed in [32/RLN-V1](https://github.com/logos-co/logos-lips/blob/master/docs/anoncomms/draft/32/rln-v1.md).
 Each node SHOULD register to the group using an `identity_commitment` stored in a Merkle tree.
-The RECOMMENDED cryptographic hash function used to generate the `membershipHash` is [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt),
+The RECOMMENDED cryptographic hash function used to generate the `membershipHash` is [SHA256](https://datatracker.ietf.org/doc/html/rfc4634),
 other hash functions MAY be used.
 The hash function SHOULD be defined in the `verison` attribute.
 A `membershipHash` MUST NOT already exist in the keystore.
@@ -180,7 +180,7 @@ The `WakuCredential` will store values used for encrypting and decrypting a node

 - it MUST be used for password verification.
 - it MUST follow [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335)
- it SHOULD use [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt) as the hash function
+- it SHOULD use [SHA256](https://datatracker.ietf.org/doc/html/rfc4634) as the hash function

 #### KDF

@@ -237,7 +237,7 @@ cipher parameters described in the KDF used in the keystore.

 RLN uses Poseidon hash algorithm to generate the `identityCredential`, 
 as described in [Poseidon Paper](https://eprint.iacr.org/2019/458.pdf).
-The keystore hash algorithm used is [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt).
+The keystore hash algorithm used is [SHA256](https://datatracker.ietf.org/doc/html/rfc4634).

 #### Input:

@@ -327,7 +327,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 ## References
 1. [32/RLN-V1](https://github.com/logos-co/logos-lips/blob/master/docs/anoncomms/draft/32/rln-v1.md)
 2. [17/WAKU2-RLN-RELAY](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/draft/17/rln-relay.md)
-3. [SHA256](https://www.rfc-editor.org/rfc/rfc4634.txt)
+3. [SHA256](https://datatracker.ietf.org/doc/html/rfc4634)
 4. [EIP155](https://eips.ethereum.org/EIPS/eip-155)
 5. [Poseidon Paper](https://eprint.iacr.org/2019/458.pdf)
 6. [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335)
@@ -10,6 +10,8 @@
 | Category | Standards Track |
 | Tags | segmentation |

+
+
 ## Abstract

 This specification defines an application-layer protocol for **segmentation** and **reconstruction** of messages carried over a transport/delivery service with a message-size limitation, when the original payload exceeds said limitation.
@@ -21,7 +23,7 @@ All messages are wrapped in a `SegmentMessageProto`, including those that fit in
 ## Motivation

 Many message transport and delivery protocols impose a maximum message size that restricts the size of application payloads.
-For example, Waku Relay typically propagates messages up to **150 KB** as per [64/WAKU2-NETWORK - Message](../core/64/network.md#message-size).
+For example, Waku Relay typically propagates messages up to **150 KB** as per [64/WAKU2-NETWORK - Message](../draft/64/network.md#message-size).
 To support larger application payloads, a segmentation layer is required.
 This specification enables larger messages by partitioning them into multiple envelopes and reconstructing them at the receiver.
 Erasure-coded parity segments provide resilience against partial loss or reordering.
@@ -191,7 +193,7 @@ To mitigate resource exhaustion:
  - When sender identity is available, apply the same two limits per sender
 - Enforce timeouts and size caps
 - Validate segment counts (≤ 256)
- Consider rate-limiting at the transport layer (for example, via [17/WAKU2-RLN-RELAY](../core/17/rln-relay.md) on Waku)
+- Consider rate-limiting at the transport layer (for example, via [17/WAKU2-RLN-RELAY](../draft/17/rln-relay.md) on Waku)

 ---

@@ -215,10 +217,10 @@ To mitigate resource exhaustion:

 ## References

-1. [10/WAKU2 – Waku](../core/10/waku2.md)
-2. [11/WAKU2-RELAY – Relay](../core/11/relay.md)
-3. [14/WAKU2-MESSAGE – Message](../core/14/message.md)
-4. [64/WAKU2-NETWORK](../core/64/network.md#message-size)
+1. [10/WAKU2 – Waku](../draft/10/waku2.md)
+2. [11/WAKU2-RELAY – Relay](../stable/11/relay.md)
+3. [14/WAKU2-MESSAGE – Message](../stable/14/message.md)
+4. [64/WAKU2-NETWORK](../draft/64/network.md#message-size)
 5. [nim-leopard](https://github.com/status-im/nim-leopard) – Nim bindings for Leopard-RS (Reed–Solomon)
 6. [Leopard-RS](https://github.com/catid/leopard) – Fast Reed–Solomon erasure coding library
 7. [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) – Key words for use in RFCs to Indicate Requirement Levels
@@ -266,7 +266,7 @@ Applications using [10/WAKU2](/messaging/draft/10/waku2.md) messages’ `timesta
 are RECOMMENDED to use additional methods for more robust message ordering.
 An example of how to deal with message ordering against adversarial message timestamps
 can be found in the Status protocol,
-see [62/STATUS-PAYLOADS](https://github.com/status-im/status-specs/tree/master/specs/status/62/payloads.md#clock-vs-timestamp-and-message-ordering).
+see [62/STATUS-PAYLOADS](../../draft/26/payload.md).

 ### Reliability of the `ephemeral` attribute

@@ -291,4 +291,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [protocol buffers v3](https://developers.google.com/protocol-buffers/)
 - [26/WAKU-PAYLOAD](/messaging/draft/26/payload.md)
 - [WAKU2-NOISE](https://github.com/logos-co/logos-lips/blob/master/docs/messaging/raw/noise.md)
- [62/STATUS-PAYLOADS](https://github.com/status-im/status-specs/tree/master/specs/status/62/payloads.md#clock-vs-timestamp-and-message-ordering)
+- [62/STATUS-PAYLOADS](../../draft/26/payload.md)
@@ -67,7 +67,7 @@ They MUST have some way of connecting to other nodes.
 Node discovery is largely out of scope for this spec,
 but see the appendix for some suggestions on how to do this.

-This protocol needs to advertise the `waku/1` [capability](https://ethereum.gitbooks.io/frontier-guide/devp2p.html).
+This protocol needs to advertise the `waku/1` [capability](https://github.com/ethereum/devp2p/blob/master/rlpx.md#capability-messaging).

 ### Gossip based routing

@@ -101,7 +101,7 @@ The default values are `1.5mb` for the RLPx Packet and `1mb` for a Waku envelope
 All Waku packets are sent as devp2p RLPx transport protocol, version 5[^1] packets.
 These packets MUST be RLP-encoded arrays of data containing two objects:
 packet code followed by another object (whose type depends on the packet code).
-See [informal RLP spec](https://github.com/ethereum/wiki/wiki/RLP) and
+See [informal RLP spec](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) and
 the [Ethereum Yellow Paper, appendix B](https://ethereum.github.io/yellowpaper/paper.pdf)
 for more details on RLP.

@@ -545,7 +545,7 @@ settlements and disconnect logic.
 ### General principles and policy

 The currently advertised capability is `waku/1`.
-This needs to be advertised in the `hello` `ÐΞVp2p` [packet](https://ethereum.gitbooks.io/frontier-guide/devp2p.html).
+This needs to be advertised in the `hello` `ÐΞVp2p` [packet](https://github.com/ethereum/devp2p/blob/master/rlpx.md#hello-0x00).
 If a node supports multiple versions of `waku`, those needs to be explicitly advertised.
 For example if both `waku/0` and `waku/1` are supported,
 both `waku/0` and `waku/1` MUST be advertised.
@@ -737,8 +737,8 @@ See libp2p and Tor's Pluggable Transport for how this can be improved.

 | Client | Spec supported | Details |
 |--------|----------------|---------|
-| **Status-go** | 0.5 | [details](https://github.com/status-im/status-go/blob/develop/WAKU.md) |
-| **Nim-waku** | 1.0 | [details](https://github.com/status-im/nim-waku/blob/master/README.md) |
+| **Status-go** | 0.5 | [details](https://github.com/status-im/status-go) |
+| **Nim-waku** | 1.0 | [details](https://github.com/logos-messaging/logos-delivery/blob/master/README.md) |

 ### Recommendations for clients

@@ -766,7 +766,7 @@ Known static nodes MAY also be used.

 ## Changelog

-### [Initial Release](https://github.com/vacp2p/specs/commit/bc7e75ebb2e45d2cbf6ab27352c113e666df37c8)
+### [Initial Release](https://github.com/vacp2p/specs)

 - Add section on P2P Request Complete packet and update packet code table.
 - Correct the header hierarchy for the status-options fields.
@@ -776,13 +776,13 @@ Known static nodes MAY also be used.

 ### Version 1.1

-Released [June 09, 2020](https://github.com/vacp2p/specs/commit/33b8d7304c9ebece90ea94e601f11080a8ac2c4d)
+Released [June 09, 2020](https://github.com/vacp2p/specs)

 - Add rate limit per bytes

 ### Version 1.0

-Released [April 21,2020](https://github.com/vacp2p/specs/commit/9e650995f24179844857520c68fa3e8f6018b125)
+Released [April 21,2020](https://github.com/vacp2p/specs)

 - Removed `version` from handshake
 - Changed `RLP` keys from 48,49.. to 0,1..
@@ -790,13 +790,13 @@ Released [April 21,2020](https://github.com/vacp2p/specs/commit/9e650995f2417984

 ### Version 0.6

-Released [April 21,2020](https://github.com/vacp2p/specs/commit/9e650995f24179844857520c68fa3e8f6018b125)
+Released [April 21,2020](https://github.com/vacp2p/specs)

 - Mark spec as Deprecated mode in terms of its lifecycle.

 ### Version 0.5

-Released [March 17,2020](https://github.com/vacp2p/specs/commit/7b9dc562bc50c6bb844ac575cb221ec9cda2530a)
+Released [March 17,2020](https://github.com/vacp2p/specs)

 - Clarify the preferred way of handling unknown keys
 in the `status-options` association list.
@@ -805,7 +805,7 @@ Change RLP keys to be the their int values in order to reflect production behavi

 ### Version 0.4

-Released [February 21, 2020](https://github.com/vacp2p/specs/commit/17bd066e317bbe33af07146b721d73f24de47e88).
+Released [February 21, 2020](https://github.com/vacp2p/specs).

 - Simplify implementation matrix with latest state
 - Introduces a new required packet code Status Code (`0x22`)
@@ -817,7 +817,7 @@ all superseded by the new Status Code (`0x22`)

 ### Version 0.3

-Released [February 13, 2020](https://github.com/vacp2p/specs/commit/73138d6ba954ab4c315e1b8d210ac7631b6d1428).
+Released [February 13, 2020](https://github.com/vacp2p/specs).

 - Recommend DNS based node discovery over other Discovery methods.
 - Mark spec as Draft mode in terms of its lifecycle.
@@ -830,7 +830,7 @@ specifying options as association list.

 ### Version 0.2

-Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/waku.md).
+Released [December 10, 2019](https://github.com/vacp2p/specs).

 - General style improvements.
 - Fix ABNF grammar.
@@ -849,7 +849,7 @@ implementation matrix across various clients with breakdown per capability.

 ### Version 0.1

-Initial version. Released [November 21, 2019](https://github.com/vacp2p/specs/blob/b59b9247f2ac1bf45c75bd3227a2e5dd87b6d7b0/waku.md).
+Initial version. Released [November 21, 2019](https://github.com/vacp2p/specs).

 ### Differences between shh/6 and waku/1

@@ -112,7 +112,7 @@ Historic envelopes MUST be sent to a peer as a packet with a P2P Message code (`
 followed by an array of Waku envelopes.
 A Mailserver MUST limit the amount of messages sent,
 either by the `Limit` specified in the request or
-limited to the maximum [RLPx packet size](../../README.md#maximum-packet-size),
+limited to the maximum RLPx packet size,
 whichever limit comes first.

 In order to receive historic envelopes from a mailserver,
@@ -178,9 +178,9 @@ This means a malicious or malfunctioning mailserver can overwhelm an individual

 | Version                                                                                        | Comment |
 | :--------------------------------------------------------------------------------------------: | ------- |
-| [1.0.0](https://github.com/vacp2p/specs/commit/bc7e75ebb2e45d2cbf6ab27352c113e666df37c8)       | marked stable as it is in use.                                                   |
+| [1.0.0](https://github.com/vacp2p/specs)       | marked stable as it is in use.                                                   |
 | 0.2.0                                                                                          | Add topic interest to reduce bandwidth usage |
-| [0.1.0](https://github.com/vacp2p/specs/blob/06d4c736c920526472a507e5d842212843a112ed/wms.md)  | Initial Release |
+| [0.1.0](https://github.com/vacp2p/specs)  | Initial Release |

 ### Difference between wms 0.1 and wms 0.2

@@ -473,7 +473,7 @@ an [error](https://www.jsonrpc.org/specification#error_object) on failure.

 | Version                                                                                 | Comment          |
 | :--------------------------------------------------------------------------------------:| ---------------- |
-| [1.0.0](https://github.com/vacp2p/specs/commit/bc7e75ebb2e45d2cbf6ab27352c113e666df37c8)| Initial release. |
+| [1.0.0](https://github.com/vacp2p/specs)| Initial release. |

 ## Copyright

@@ -47,7 +47,7 @@ It is equivalent except for some areas:
 - recommending the use of a permissive licenses,
 such as CC0 (with the exception of this document);
 - miscellaneous metadata, editor, and format/link updates;
- more inheritance from the [IETF Standards Process](https://www.rfc-editor.org/rfc/rfc2026.txt),
+- more inheritance from the [IETF Standards Process](https://datatracker.ietf.org/doc/html/rfc2026),
  e.g. using RFC categories: Standards Track, Informational, and Best Common Practice;
 - standards track specifications SHOULD
 follow a specific structure that both streamlines editing,
@@ -160,7 +160,7 @@ documents clearly its current status.
 For a specification to receive a lifecycle status,
 a new specification SHOULD be presented by the team of the sub-domain.
 After discussion amongst the contributors has reached a rough consensus,
-as described in [RFC7282](https://www.rfc-editor.org/rfc/rfc7282.html),
+as described in [RFC7282](https://datatracker.ietf.org/doc/html/rfc7282),
 the specification MAY begin the process to upgrade its status.

 A specification has eight possible states that reflect its maturity and
@@ -331,7 +331,7 @@ editing a specification, and
 promoting the status of a specification along with other tasks.
 Once a specification reaches some level of maturity by rough consensus,
 the specification SHOULD enter the [Logos LIP](https://lip.logos.co/) process.
-Similar to the IETF working group adoption described in [RFC6174](https://www.rfc-editor.org/rfc/rfc6174.html),
+Similar to the IETF working group adoption described in [RFC6174](https://datatracker.ietf.org/doc/html/rfc6174),
 the Logos LIP process SHOULD facilitate all updates to the specification.

 Specifications are introduced by projects,
@@ -347,7 +347,7 @@ When a specification is promoted to *draft* status,
 the number that is assigned MAY be incremental
 or by the *sub-domain* and the Logos LIP process.
 Standards track specifications MUST be based on the
-[Logos LIP template](../../template.md) before obtaining a new status.
+[Logos LIP template](https://github.com/logos-co/logos-lips/blob/master/docs/anoncomms/template.md) before obtaining a new status.
 All changes, comments, and contributions SHOULD be documented.

 ### Document Types
@@ -134,7 +134,7 @@ A client has two primary responsibilities:

 When a user prompts the client node to create a storage request, the client node SHOULD receive the input parameters for the storage request from the user.

-To create a request to persist a dataset on the Codex network, client nodes MUST split the dataset into data chunks, $(c_1, c_2, c_3, \ldots, c_{n})$. Using the erasure coding method and the provided input parameters, the data chunks are encoded and distributed over a number of slots. The applied erasure coding method MUST use the [Reed-Solomon algorithm](https://hackmd.io/FB58eZQoTNm-dnhu0Y1XnA). The final slot roots and other metadata MUST be placed into a `Manifest` (TODO: Manifest RFC). The CID for the `Manifest` MUST then be used as the `cid` for the stored dataset.
+To create a request to persist a dataset on the Codex network, client nodes MUST split the dataset into data chunks, $`(c_1, c_2, c_3, \ldots, c_{n})`$. Using the erasure coding method and the provided input parameters, the data chunks are encoded and distributed over a number of slots. The applied erasure coding method MUST use the [Reed-Solomon algorithm](https://hackmd.io/FB58eZQoTNm-dnhu0Y1XnA). The final slot roots and other metadata MUST be placed into a `Manifest` (TODO: Manifest RFC). The CID for the `Manifest` MUST then be used as the `cid` for the stored dataset.

 After the dataset is prepared, a client node MUST call the smart contract function `requestStorage(request)`, providing the desired request parameters in the `request` parameter. The `request` parameter is of type `Request`:

@@ -172,9 +172,9 @@ The table below provides the description of the `Request` and the associated typ
 | `content` | `Content` | The dataset that will be hosted with the storage request. |
 | `expiry` | `uint64` | Timeout in seconds during which all the slots have to be filled, otherwise Request will get cancelled. The final deadline timestamp is calculated at the moment the transaction is mined. |
 | `nonce` | `bytes32` | Random value to differentiate from other requests of same parameters. It SHOULD be a random byte array. |
-| `pricePerBytePerSecond` | `uint256` | Amount of tokens that will be awarded to SPs for finishing the storage request. It MUST be an amount of tokens offered per slot per second per byte. The Ethereum address that submits the `requestStorage()` transaction MUST have [approval](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#IERC20-approve-address-uint256-) for the transfer of at least an equivalent amount of full reward (`pricePerBytePerSecond * duration * slots * slotSize`) in tokens. |
+| `pricePerBytePerSecond` | `uint256` | Amount of tokens that will be awarded to SPs for finishing the storage request. It MUST be an amount of tokens offered per slot per second per byte. The Ethereum address that submits the `requestStorage()` transaction MUST have [approval](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#IERC20-approve-address-uint256-) for the transfer of at least an equivalent amount of full reward (`pricePerBytePerSecond * duration * slots * slotSize`) in tokens. |
 | `collateralPerByte` | `uint256` | The amount of tokens per byte of slot's size that SPs submit when they fill slots. Collateral is then slashed or forfeited if SPs fail to provide the service requested by the storage request (more information in the [Slashing](#### Slashing) section). |
-| `proofProbability` | `uint256` | Determines the average frequency that a proof is required within a period: $\frac{1}{proofProbability}$. SPs are required to provide proofs of storage to the marketplace contract when challenged. To prevent hosts from only coming online when proofs are required, the frequency at which proofs are requested from SPs is stochastic and is influenced by the `proofProbability` parameter. |
+| `proofProbability` | `uint256` | Determines the average frequency that a proof is required within a period: $`\frac{1}{proofProbability}`$. SPs are required to provide proofs of storage to the marketplace contract when challenged. To prevent hosts from only coming online when proofs are required, the frequency at which proofs are requested from SPs is stochastic and is influenced by the `proofProbability` parameter. |
 | `duration` | `uint64` | Total duration of the storage request in seconds. It MUST NOT exceed the limit specified in the configuration `config.requestDurationLimit`. |
 | `slots` | `uint64` | The number of requested slots. The slots will all have the same size. |
 | `slotSize` | `uint64` | Amount of storage per slot in bytes. |
@@ -245,7 +245,7 @@ When the proof is ready, the SP MUST call `fillSlot()` on the smart contract wit
 - `slotIndex` - the slot index that the node wants to fill.
 - `proof` - the `Groth16Proof` proof structure, generated over the slot data.

-The Ethereum address of the SP node from which the transaction originates MUST have [approval](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#IERC20-approve-address-uint256-) for the transfer of at least the amount of tokens required as collateral for the slot (`collateralPerByte * slotSize`).
+The Ethereum address of the SP node from which the transaction originates MUST have [approval](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#IERC20-approve-address-uint256-) for the transfer of at least the amount of tokens required as collateral for the slot (`collateralPerByte * slotSize`).

 If the proof delivered by the SP is invalid or the slot was already filled by another SP, then the transaction will revert. Otherwise, a `SlotFilled(requestId, slotIndex)` event is emitted. If the transaction is successful, the SP SHOULD transition into the **proving** state, where it will need to submit proof of data possession when challenged by the smart contract.

@@ -806,8 +806,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### Informative

- [Codex Implementation](https://github.com/codex-storage/nim-codex) - Reference implementation in Nim
- [Codex market implementation](https://github.com/codex-storage/nim-codex/blob/master/codex/market.nim) - Marketplace module implementation
+- [Codex Implementation](https://github.com/logos-storage/logos-storage-nim) - Reference implementation in Nim
+- [Codex market implementation](https://github.com/logos-storage/logos-storage-nim) - Marketplace module implementation
 - [Codex Sales Component Spec](https://github.com/codex-storage/codex-docs-obsidian/blob/main/10%20Notes/Specs/Component%20Specification%20-%20Sales.md) - Storage Provider implementation details
 - [Codex Purchase Component Spec](https://github.com/codex-storage/codex-docs-obsidian/blob/main/10%20Notes/Specs/Component%20Specification%20-%20Purchase.md) - Client implementation details
 - [Nim Chronos](https://github.com/status-im/nim-chronos) - Async/await framework for Nim
@@ -25,7 +25,7 @@
 ## Abstract

 This specification defines the Merkle tree implementation
-for [Codex](https://github.com/codex-storage/nim-codex).
+for [Codex](https://github.com/logos-storage/logos-storage-nim).
 The purpose of this component is to deal with Merkle trees
 (and Merkle trees only;
 except that certain arithmetic hashes constructed via the sponge construction
@@ -440,7 +440,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### normative

- **Codex Merkle Tree Implementation**: [GitHub - codex-storage/nim-codex](https://github.com/codex-storage/nim-codex)
+- **Codex Merkle Tree Implementation**: [GitHub - codex-storage/nim-codex](https://github.com/logos-storage/logos-storage-nim)

 ### informative

@@ -25,7 +25,7 @@
 ## Abstract

 This specification defines the Proving module for
-[Codex](https://github.com/codex-storage/nim-codex),
+[Codex](https://github.com/logos-storage/logos-storage-nim),
 which provides a succinct, publicly verifiable way to check that storage
 providers still hold the data they committed to.
 The proving module samples cells from stored slots,
@@ -37,7 +37,7 @@ to manage incentives such as payments and slashing.
 ## Background / Rationale / Motivation

 In decentralized storage networks such as
-[Codex](https://github.com/codex-storage/nim-codex),
+[Codex](https://github.com/logos-storage/logos-storage-nim),
 one of the main challenges is ensuring durability and availability of data
 stored by storage providers.
 To achieve durability, random sampling combined with erasure coding is used
@@ -529,7 +529,7 @@ Storage providers must submit valid proofs within the proof window deadline. Thi

 ## Rationale

-This specification is based on the Proving module component specification from the [Codex project](https://github.com/codex-storage/nim-codex).
+This specification is based on the Proving module component specification from the [Codex project](https://github.com/logos-storage/logos-storage-nim).

 ### Probabilistic Verification

@@ -572,7 +572,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### Normative

- **Codex**: [GitHub - codex-storage/nim-codex](https://github.com/codex-storage/nim-codex)
+- **Codex**: [GitHub - codex-storage/nim-codex](https://github.com/logos-storage/logos-storage-nim)
 - **Codex Prover Specification**: [Codex Docs - Component Specification - Prover](https://github.com/codex-storage/codex-docs-obsidian/blob/main/10%20Notes/Specs/Component%20Specification%20-%20Prover.md)
 - **CODEX-SLOT-BUILDER**: Codex Slot Builder specification (defines `SlotsBuilder`
  and slot commitment construction)
@@ -96,11 +96,11 @@ In the classical situation, like for example SHA2 or SHA3, the leaves are just b

 #### 1. Layer abuse attacks

-Using traditional functions like SHA256, one could express the compression `C(a,b)` as `H(f(a,b))`, where `f` is just concatenation: `f(a,b) = a || b` (Fig. 1(a)). This creates a type of symmetry one can then exploit - since a naive Merkle tree root does not encode its depth, one could pretend that `f(a,b)` is actually data, and construct a shorter (that is, less deep) Merkle tree which evaluates to the same root as before (Fig. 1(b)); i.e., $T^{\prime}_3$ in the second tree is the same as $T_7$ in the original tree.
+Using traditional functions like SHA256, one could express the compression `C(a,b)` as `H(f(a,b))`, where `f` is just concatenation: `f(a,b) = a || b` (Fig. 1(a)). This creates a type of symmetry one can then exploit - since a naive Merkle tree root does not encode its depth, one could pretend that `f(a,b)` is actually data, and construct a shorter (that is, less deep) Merkle tree which evaluates to the same root as before (Fig. 1(b)); i.e., $`T^{\prime}_3`$ in the second tree is the same as $`T_7`$ in the original tree.

-![layer abuse attack](images/layer-abuse.png)
+![layer abuse attack](../raw/images/layer-abuse.png)

-**Figure 1.** **(a)** original Merkle tree; **(b)** a different Merkle tree with the same Merkle root as the original; i.e., $T^{\prime}_3 = T_7$, constructed from a layer abuse attack.
+**Figure 1.** **(a)** original Merkle tree; **(b)** a different Merkle tree with the same Merkle root as the original; i.e., $`T^{\prime}_3 = T_7`$, constructed from a layer abuse attack.

 #### 2. Padding attacks

@@ -108,7 +108,7 @@ A layer of a (binary) Merkle trees can be incomplete, when the number of leaves

 If done carelessly, this can potentially allow an attacker to replace the padding with some fake data below that is equivalent to such padding (Fig. 2(b)), and again generate the same Merkle root from data that is different from what had been intended.

-![padding attack](images/padding.png)
+![padding attack](../raw/images/padding.png)

 **Figure 2.** **(a)** Original padded Merkle tree, and **(b)** a Merkle tree with the same root as the original built from a padding attack.

@@ -203,7 +203,7 @@ In that context, each such _data block_[^3] (of size `b`) then undergoes hashing

 For hashing functions which do not take bytestrings as input - like  Poseidon2, which operates on sequences of finite field elements - we must _encode_ our data blocks into the proper type first (Figure 3(b)).

-![encoding](images/encoding.png)
+![encoding](../raw/images/encoding.png)

 **Figure 3.** **(a)** A byte string (raw data), split into data blocks which are also bytestrings. **(b)** Data blocks after undergoing encoding.

@@ -21,7 +21,7 @@
 ## Abstract

 This specification describes the Store Module,
-the core storage abstraction in [Codex](https://github.com/codex-storage/nim-codex),
+the core storage abstraction in [Codex](https://github.com/logos-storage/logos-storage-nim),
 providing a unified interface for storing and retrieving content-addressed blocks
 and associated metadata.

@@ -463,7 +463,7 @@ QuotaUsage* {.serialize.} = object

 The Store Module does not define a wire format specification.
 It provides an internal storage abstraction
-for [Codex](https://github.com/codex-storage/nim-codex)
+for [Codex](https://github.com/logos-storage/logos-storage-nim)
 and relies on underlying datastore implementations for serialization
 and persistence.

@@ -518,7 +518,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public

 ### normative

- [Codex](https://github.com/codex-storage/nim-codex)
+- [Codex](https://github.com/logos-storage/logos-storage-nim)
 - [Component Specification - Store](https://github.com/codex-storage/codex-docs-obsidian/blob/main/10%20Notes/Specs/Component%20Specification%20-%20Store.md)

 ### informative
@@ -528,4 +528,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [chronos](https://github.com/status-im/nim-chronos) - Async runtime
 - [libp2p](https://github.com/status-im/nim-libp2p) - P2P networking and CID types
 - [questionable](https://github.com/codex-storage/questionable) - Error handling
- [lrucache](https://github.com/status-im/lrucache) - LRU cache implementation
+- [lrucache](https://github.com/status-im/nim-minilru) - LRU cache implementation
@@ -270,7 +270,7 @@ The `content_Topic` of that special channel follows the following format:
 ```

 All messages sent with this special channel's `content_Topic` MUST be instances of `ApplicationMetadataMessage`,
-with a [62/STATUS-PAYLOADS](https://github.com/status-im/status-specs/tree/master/specs/status/62/payloads.md) of `CommunityMessageArchiveIndex`.
+with a [62/STATUS-PAYLOADS](../../messaging/draft/26/payload.md) of `CommunityMessageArchiveIndex`.

 Only the control node MAY post to the special channel.
 Other messages on this specified channel MUST be ignored by clients.
@@ -310,7 +310,7 @@ Two RECOMMENDED scenarios in which community member nodes can receive such a mag
 (this is the case when a new community member joins a community.)
 3. Downloading message archives

-When community member nodes receive a message with a `CommunityMessageHistoryArchive` [62/STATUS-PAYLOADS](https://github.com/status-im/status-specs/tree/master/specs/status/62/payloads.md),
+When community member nodes receive a message with a `CommunityMessageHistoryArchive` [62/STATUS-PAYLOADS](../../messaging/draft/26/payload.md),
 they MUST extract the `magnet_uri`.
 Then SHOULD pass it to their underlying BitTorrent client to fetch the latest message history archive index,
 which is the index file of the torrent, see [Creating message archive torrents].
@@ -388,4 +388,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 - [10/WAKU2](../../messaging/draft/10/waku2.md)
 - [11/WAKU2-RELAY](../../messaging/stable/11/relay.md)
 - [14/WAKU2-MESSAGE](../../messaging/stable/14/message.md)
- [62/STATUS-PAYLOADS](https://github.com/status-im/status-specs/tree/master/specs/status/62/payloads.md)
+- [62/STATUS-PAYLOADS](../../messaging/draft/26/payload.md)
@@ -150,7 +150,7 @@ from the received manifest data.
 - [Codex Manifest Spec][origin-ref] - Original specification

 [rfc-2119]: https://www.ietf.org/rfc/rfc2119.txt
-[merkle-tree]: ./merkle-tree.md
+[merkle-tree]: ../draft/merkle-tree.md
 [codex-dht]: ./dht.md
 [bep3]: http://bittorrent.org/beps/bep_0003.html
 [cidv1]: https://github.com/multiformats/cid#cidv1
@@ -4,21 +4,31 @@ Run all generators in sequence.
 """
 from __future__ import annotations

+import os
 import subprocess
 import sys
 from pathlib import Path

 ROOT = Path(__file__).resolve().parent.parent
+HISTORY_SCRIPT = "scripts/gen_history.py"
 SCRIPTS = [
    "scripts/validate_metadata.py",
    "scripts/validate_rendering.py",
-    "scripts/gen_history.py",
+    HISTORY_SCRIPT,
    "scripts/gen_rfc_index.py",
    "scripts/gen_summary.py",
    "scripts/validate_generated_outputs.py",
 ]


+def should_generate_history() -> bool:
+    if os.environ.get("LIPS_GENERATE_HISTORY") in {"1", "true", "TRUE", "yes", "YES"}:
+        return True
+
+    ci_markers = ("CI", "GITHUB_ACTIONS", "JENKINS_URL", "BUILD_ID", "BUILD_NUMBER")
+    return any(os.environ.get(name) for name in ci_markers)
+
+
 def run(script: str) -> None:
    parts = script.split()
    path = ROOT / parts[0]
@@ -31,6 +41,9 @@ def run(script: str) -> None:

 def main() -> None:
    for script in SCRIPTS:
+        if script == HISTORY_SCRIPT and not should_generate_history():
+            print("[INFO] Skipping history generation outside CI")
+            continue
        run(script)