2025-06-03 11:08:02 +02:00
|
|
|
import { createDecoder, createEncoder } from "@waku/core/lib/message/version_0";
|
|
|
|
|
import { IDecodedMessage } from "@waku/interfaces";
|
2025-02-11 15:28:00 +05:30
|
|
|
import {
|
|
|
|
|
generatePrivateKey,
|
|
|
|
|
generateSymmetricKey,
|
|
|
|
|
getPublicKey
|
|
|
|
|
} from "@waku/message-encryption";
|
|
|
|
|
import {
|
|
|
|
|
createDecoder as createAsymDecoder,
|
|
|
|
|
createEncoder as createAsymEncoder
|
|
|
|
|
} from "@waku/message-encryption/ecies";
|
|
|
|
|
import {
|
|
|
|
|
createDecoder as createSymDecoder,
|
|
|
|
|
createEncoder as createSymEncoder
|
|
|
|
|
} from "@waku/message-encryption/symmetric";
|
|
|
|
|
import { expect } from "chai";
|
|
|
|
|
|
|
|
|
|
import {
|
|
|
|
|
createRLNDecoder,
|
|
|
|
|
createRLNEncoder,
|
|
|
|
|
RLNDecoder,
|
|
|
|
|
RLNEncoder
|
|
|
|
|
} from "./codec.js";
|
2025-03-31 14:32:29 +05:30
|
|
|
import {
|
|
|
|
|
createTestMetaSetter,
|
|
|
|
|
createTestRLNCodecSetup,
|
2025-07-19 17:24:34 +10:00
|
|
|
EMPTY_PROTO_MESSAGE,
|
|
|
|
|
TEST_CONSTANTS,
|
2025-03-31 14:32:29 +05:30
|
|
|
verifyRLNMessage
|
|
|
|
|
} from "./codec.test-utils.js";
|
2025-02-11 15:28:00 +05:30
|
|
|
import { RlnMessage } from "./message.js";
|
|
|
|
|
import { epochBytesToInt } from "./utils/index.js";
|
|
|
|
|
|
|
|
|
|
describe("RLN codec with version 0", () => {
|
|
|
|
|
it("toWire", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const rlnEncoder = createRLNEncoder({
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
encoder: createEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
}),
|
2025-02-11 15:28:00 +05:30
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
});
|
|
|
|
|
const rlnDecoder = createRLNDecoder({
|
|
|
|
|
rlnInstance,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
decoder: createDecoder(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.contentTopic,
|
|
|
|
|
TEST_CONSTANTS.routingInfo
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
)
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
const bytes = await rlnEncoder.toWire({ payload });
|
|
|
|
|
|
|
|
|
|
expect(bytes).to.not.be.undefined;
|
|
|
|
|
const protoResult = await rlnDecoder.fromWireToProtoObj(bytes!);
|
|
|
|
|
expect(protoResult).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
protoResult!
|
|
|
|
|
))!;
|
|
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 0, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("toProtoObj", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
}),
|
2025-02-11 15:28:00 +05:30
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
2025-07-19 17:24:34 +10:00
|
|
|
createDecoder(TEST_CONSTANTS.contentTopic, TEST_CONSTANTS.routingInfo)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const proto = await rlnEncoder.toProtoObj({ payload });
|
|
|
|
|
|
|
|
|
|
expect(proto).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
proto!
|
2025-06-03 11:08:02 +02:00
|
|
|
)) as RlnMessage<IDecodedMessage>;
|
2025-02-11 15:28:00 +05:30
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 0, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("RLN codec with version 1", () => {
|
|
|
|
|
it("Symmetric, toWire", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
const symKey = generateSymmetricKey();
|
|
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
|
|
|
|
createSymEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo,
|
2025-02-11 15:28:00 +05:30
|
|
|
symKey
|
|
|
|
|
}),
|
|
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createSymDecoder(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.contentTopic,
|
|
|
|
|
TEST_CONSTANTS.routingInfo,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
symKey
|
|
|
|
|
)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const bytes = await rlnEncoder.toWire({ payload });
|
|
|
|
|
|
|
|
|
|
expect(bytes).to.not.be.undefined;
|
|
|
|
|
const protoResult = await rlnDecoder.fromWireToProtoObj(bytes!);
|
|
|
|
|
expect(protoResult).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
protoResult!
|
|
|
|
|
))!;
|
|
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 1, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Symmetric, toProtoObj", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
const symKey = generateSymmetricKey();
|
|
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
|
|
|
|
createSymEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo,
|
2025-02-11 15:28:00 +05:30
|
|
|
symKey
|
|
|
|
|
}),
|
|
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createSymDecoder(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.contentTopic,
|
|
|
|
|
TEST_CONSTANTS.routingInfo,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
symKey
|
|
|
|
|
)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const proto = await rlnEncoder.toProtoObj({ payload });
|
|
|
|
|
|
|
|
|
|
expect(proto).to.not.be.undefined;
|
2025-06-03 11:08:02 +02:00
|
|
|
const msg = await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
proto!
|
2025-06-03 11:08:02 +02:00
|
|
|
);
|
2025-02-11 15:28:00 +05:30
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 1, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Asymmetric, toWire", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
const privateKey = generatePrivateKey();
|
|
|
|
|
const publicKey = getPublicKey(privateKey);
|
|
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
|
|
|
|
createAsymEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo,
|
2025-02-11 15:28:00 +05:30
|
|
|
publicKey
|
|
|
|
|
}),
|
|
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createAsymDecoder(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.contentTopic,
|
|
|
|
|
TEST_CONSTANTS.routingInfo,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
privateKey
|
|
|
|
|
)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const bytes = await rlnEncoder.toWire({ payload });
|
|
|
|
|
|
|
|
|
|
expect(bytes).to.not.be.undefined;
|
|
|
|
|
const protoResult = await rlnDecoder.fromWireToProtoObj(bytes!);
|
|
|
|
|
expect(protoResult).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
protoResult!
|
|
|
|
|
))!;
|
|
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 1, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("Asymmetric, toProtoObj", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
const privateKey = generatePrivateKey();
|
|
|
|
|
const publicKey = getPublicKey(privateKey);
|
|
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
|
|
|
|
createAsymEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo,
|
2025-02-11 15:28:00 +05:30
|
|
|
publicKey
|
|
|
|
|
}),
|
|
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createAsymDecoder(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.contentTopic,
|
|
|
|
|
TEST_CONSTANTS.routingInfo,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
privateKey
|
|
|
|
|
)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const proto = await rlnEncoder.toProtoObj({ payload });
|
|
|
|
|
|
|
|
|
|
expect(proto).to.not.be.undefined;
|
2025-06-03 11:08:02 +02:00
|
|
|
const msg = await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
proto!
|
2025-06-03 11:08:02 +02:00
|
|
|
);
|
2025-02-11 15:28:00 +05:30
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 1, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("RLN Codec - epoch", () => {
|
|
|
|
|
it("toProtoObj", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
}),
|
2025-02-11 15:28:00 +05:30
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
2025-07-19 17:24:34 +10:00
|
|
|
createDecoder(TEST_CONSTANTS.contentTopic, TEST_CONSTANTS.routingInfo)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const proto = await rlnEncoder.toProtoObj({ payload });
|
|
|
|
|
|
|
|
|
|
expect(proto).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
proto!
|
2025-06-03 11:08:02 +02:00
|
|
|
)) as RlnMessage<IDecodedMessage>;
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const epochBytes = proto!.rateLimitProof!.epoch;
|
|
|
|
|
const epoch = epochBytesToInt(epochBytes);
|
|
|
|
|
|
|
|
|
|
expect(msg.epoch!.toString(10).length).to.eq(9);
|
|
|
|
|
expect(msg.epoch).to.eq(epoch);
|
|
|
|
|
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 0, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("RLN codec with version 0 and meta setter", () => {
|
|
|
|
|
it("toWire", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
|
|
|
|
const metaSetter = createTestMetaSetter();
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const rlnEncoder = createRLNEncoder({
|
2025-03-31 14:32:29 +05:30
|
|
|
encoder: createEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo,
|
2025-03-31 14:32:29 +05:30
|
|
|
metaSetter
|
|
|
|
|
}),
|
2025-02-11 15:28:00 +05:30
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
});
|
|
|
|
|
const rlnDecoder = createRLNDecoder({
|
|
|
|
|
rlnInstance,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
decoder: createDecoder(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.contentTopic,
|
|
|
|
|
TEST_CONSTANTS.routingInfo
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
)
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
const bytes = await rlnEncoder.toWire({ payload });
|
|
|
|
|
|
|
|
|
|
expect(bytes).to.not.be.undefined;
|
|
|
|
|
const protoResult = await rlnDecoder.fromWireToProtoObj(bytes!);
|
|
|
|
|
expect(protoResult).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
protoResult!
|
|
|
|
|
))!;
|
|
|
|
|
|
|
|
|
|
const expectedMeta = metaSetter({
|
2025-07-19 17:24:34 +10:00
|
|
|
...EMPTY_PROTO_MESSAGE,
|
2025-02-11 15:28:00 +05:30
|
|
|
payload: protoResult!.payload
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
expect(msg!.meta).to.deep.eq(expectedMeta);
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 0, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("toProtoObj", async function () {
|
2025-03-31 14:32:29 +05:30
|
|
|
const { rlnInstance, credential, index, payload } =
|
|
|
|
|
await createTestRLNCodecSetup();
|
|
|
|
|
const metaSetter = createTestMetaSetter();
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const rlnEncoder = new RLNEncoder(
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
createEncoder({
|
2025-07-19 17:24:34 +10:00
|
|
|
contentTopic: TEST_CONSTANTS.contentTopic,
|
|
|
|
|
routingInfo: TEST_CONSTANTS.routingInfo,
|
feat!: Introduce routing info concept
Concepts are being mixed up between the global network config (static vs auto sharding), that needs to be the same of all nodes in the network, individual node configuration (eg relay node subscribing to a given shard), and the routing characteristic of a specific message (eg pubsub topic, shard).
This stops proper configuration of nwaku post 0.36.0 because we know need to be deliberate on whether nwaku nodes are running with auto or static sharding.
It also included various back and forth conversions between shards, pubsub topics, etc.
With this change, we tidy up the network configuration, and make it explicit whether it is static or auto sharded.
We also introduce the concept of routing info, which is specific to a message, and tied to the overall network configuration.
Routing info abstract pubsub topic, shard, and autosharding needs. Which should lead to easier tidy up of the pubsub concept at a later stage.
# Conflicts:
# packages/core/src/lib/connection_manager/connection_manager.ts
# packages/core/src/lib/metadata/metadata.ts
# packages/interfaces/src/metadata.ts
# packages/interfaces/src/sharding.ts
# packages/relay/src/create.ts
# packages/sdk/src/filter/filter.ts
# packages/sdk/src/filter/types.ts
# packages/sdk/src/light_push/light_push.spec.ts
# packages/tests/tests/sharding/auto_sharding.spec.ts
# packages/tests/tests/sharding/static_sharding.spec.ts
# Conflicts:
# packages/sdk/src/store/store.ts
2025-07-11 13:33:45 +10:00
|
|
|
metaSetter
|
|
|
|
|
}),
|
2025-02-11 15:28:00 +05:30
|
|
|
rlnInstance,
|
|
|
|
|
index,
|
|
|
|
|
credential
|
|
|
|
|
);
|
|
|
|
|
const rlnDecoder = new RLNDecoder(
|
|
|
|
|
rlnInstance,
|
2025-07-19 17:24:34 +10:00
|
|
|
createDecoder(TEST_CONSTANTS.contentTopic, TEST_CONSTANTS.routingInfo)
|
2025-02-11 15:28:00 +05:30
|
|
|
);
|
|
|
|
|
|
|
|
|
|
const proto = await rlnEncoder.toProtoObj({ payload });
|
|
|
|
|
|
|
|
|
|
expect(proto).to.not.be.undefined;
|
|
|
|
|
const msg = (await rlnDecoder.fromProtoObj(
|
2025-07-19 17:24:34 +10:00
|
|
|
TEST_CONSTANTS.emptyPubsubTopic,
|
2025-02-11 15:28:00 +05:30
|
|
|
proto!
|
2025-06-03 11:08:02 +02:00
|
|
|
)) as RlnMessage<IDecodedMessage>;
|
2025-02-11 15:28:00 +05:30
|
|
|
|
|
|
|
|
const expectedMeta = metaSetter({
|
2025-07-19 17:24:34 +10:00
|
|
|
...EMPTY_PROTO_MESSAGE,
|
2025-02-11 15:28:00 +05:30
|
|
|
payload: msg!.payload
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
expect(msg!.meta).to.deep.eq(expectedMeta);
|
2025-07-19 17:24:34 +10:00
|
|
|
verifyRLNMessage(msg, payload, TEST_CONSTANTS.contentTopic, 0, rlnInstance);
|
2025-02-11 15:28:00 +05:30
|
|
|
});
|
|
|
|
|
});
|