Skip to content

Conversation

@weboko
Copy link
Collaborator

@weboko weboko commented Aug 20, 2025

Problem / Description

Creation of unified Send method is needed.

Solution

Make sending a message over the network completely lean.

This PR adds:

  • to IWaku - new .send method that accepts lean data structure to route the message
  • navigating where to send message relies on present networkConfig on IWaku node
  • implements back-end for Subscribe functionality by creating AckManager facade
  • when message is sent - subscription automatically gets created

Notes


Checklist

  • Code changes are covered by unit tests.
  • Code changes are covered by e2e tests, if applicable.
  • Dogfooding has been performed, if feasible.
  • A test version has been published, if required.
  • All CI checks pass successfully.

@github-actions
Copy link

github-actions bot commented Sep 24, 2025

size-limit report 📦

Path Size Loading time (3g) Running time (snapdragon) Total time
Waku node 97.36 KB (+1.31% 🔺) 2 s (+1.31% 🔺) 693 ms (-13.4% 🔽) 2.7 s
Waku Simple Light Node 148.63 KB (+0.85% 🔺) 3 s (+0.85% 🔺) 819 ms (+47.15% 🔺) 3.8 s
ECIES encryption 22.56 KB (+0.25% 🔺) 452 ms (+0.25% 🔺) 207 ms (-13.05% 🔽) 658 ms
Symmetric encryption 22 KB (+0.4% 🔺) 440 ms (+0.4% 🔺) 161 ms (-41.72% 🔽) 601 ms
DNS discovery 52.11 KB (-0.08% 🔽) 1.1 s (-0.08% 🔽) 523 ms (-8.7% 🔽) 1.6 s
Peer Exchange discovery 52.83 KB (-0.15% 🔽) 1.1 s (-0.15% 🔽) 659 ms (+3.17% 🔺) 1.8 s
Peer Cache Discovery 46.58 KB (+0.02% 🔺) 932 ms (+0.02% 🔺) 597 ms (+27.23% 🔺) 1.6 s
Privacy preserving protocols 77.14 KB (+0.11% 🔺) 1.6 s (+0.11% 🔺) 713 ms (-30.67% 🔽) 2.3 s
Waku Filter 79.68 KB (-0.02% 🔽) 1.6 s (-0.02% 🔽) 985 ms (+35.4% 🔺) 2.6 s
Waku LightPush 77.79 KB (+0.02% 🔺) 1.6 s (+0.02% 🔺) 720 ms (+24.97% 🔺) 2.3 s
History retrieval protocols 83.56 KB (-0.06% 🔽) 1.7 s (-0.06% 🔽) 720 ms (-12.47% 🔽) 2.4 s
Deterministic Message Hashing 28.89 KB (-0.05% 🔽) 578 ms (-0.05% 🔽) 353 ms (+18.48% 🔺) 931 ms

@weboko weboko mentioned this pull request Sep 29, 2025
1 task
@weboko weboko mentioned this pull request Oct 6, 2025
8 tasks
@weboko weboko changed the title feat: send api feat: introduce Send API Oct 6, 2025
@weboko weboko marked this pull request as ready for review October 7, 2025 22:34
@weboko weboko requested a review from a team as a code owner October 7, 2025 22:34
@weboko
Copy link
Collaborator Author

weboko commented Oct 7, 2025

I still need to add some E2E Tests and better dogfooding example.

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting

@weboko weboko requested a review from Copilot October 7, 2025 23:00
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR introduces a unified Send API for Waku nodes, simplifying message sending by providing a lean interface that handles routing, acknowledgments, and retry logic internally.

  • Adds send method to IWaku interface that accepts simplified message data structure
  • Implements messaging backend with automatic acknowledgment tracking via filter and store protocols
  • Integrates retry logic and subscription management for reliable message delivery

Reviewed Changes

Copilot reviewed 23 out of 24 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
packages/interfaces/src/waku.ts Adds send method to IWaku interface and deprecation warnings
packages/interfaces/src/message.ts Defines ISendMessage and RequestId types for new API
packages/sdk/src/waku/waku.ts Integrates Messaging class into WakuNode implementation
packages/sdk/src/messaging/* Complete messaging system with sender, ack manager, and message store
packages/core/src/lib/light_push/* Extends light push to return proto messages for acknowledgment tracking
packages/interfaces/src/sender.ts Adds numPeersToUse option to ISendOptions

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

this.filterAckManager.subscribe(decoder),
this.storeAckManager.subscribe(decoder)
])
).some((success) => success);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is only one success sufficient?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we rely on background process of Filter to automatically recover subscriptions or Store to continue querying

if (this.toSubscribeContentTopics.size > 0) {

that's why enough to get confirmation for at least one successful in-place subscription
because later it will recover in async way

}
}

class StoreAckManager {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: splitting StoreAckManager and FilterAckManager into separate classes from AckManager seems overkill, unless there's a good reason for someone to use them outside of AckManager

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree, it seems logical to keep them separate and might be useful once we want to provide other ack mechanics such as SDS.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be useful

I would recommend avoiding introducing complexity for a might and just proceed with a refactoring once this complexity becomes necessary.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

once we want to provide other ack mechanics such as SDS.

We already provide those via ReliableChannel and I am not convinced we want to merge routing (Waku API) and application (Reliable Channel) level concepts in the same objects.

@fryorcraken
Copy link
Collaborator

Will wait for agreement on the spec before review of this PR.

contentTopic: string;
payload: Uint8Array;
ephemeral?: boolean;
rateLimitProof?: boolean;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the API consumer should be exposed to the rate limit proof, this sit behind the Waku API. see createNode spec for details.

* @param {ISendMessage} message - The message to send.
* @returns {Promise<RequestId>} A promise that resolves to the request ID
*/
send(message: ISendMessage): Promise<RequestId>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the Waku message Id must be exposed in the API to enable SDS's retrieval hints.

I strongly recommend for it to be returned by send to avoid issues with timestamp and pubsubtopic (both being used to calculate message id)

/**
* Send message data structure used in {@link IWaku.send}.
*/
export interface ISendMessage {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not convinced we need a type here, it just makes it harder to understand the API.

Just do

send: (
  contentTopic: string;
  payload: Uint8Array;
  ephemeral?: boolean;
  ) => Promise<Uint8Array | undefined>;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: implement Send API

3 participants