Add Send API to Waku API

[weboko]

Implementation - logos-messaging/js-waku#2583

[Ivansete-status]

Some niptick comments so far, thanks!

[Copilot]

Pull Request Overview

This PR adds a new Send API to the Waku API specification that enables sending messages through the Waku network. The addition provides a standardized interface for applications to publish messages with support for content topics, ephemeral messages, and rate limiting.

• Adds byte as a new primitive type to support binary message payloads
• Introduces SendMessage type definition with fields for content topic, payload, ephemeral flag, and rate limit proof
• Defines send function that accepts a message and returns a request ID or error

---

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

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

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

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

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

[fryorcraken]

(one of my comment was pending :( )

[fryorcraken]

I don't agree with some of the decisions but at the end of the day, API design must be informed by API usage.

Let's see how this holds when implement in nim and js, and used in the reliable channel layer (both in Nim and JS).

[weboko]

I am not merging till @Ivansete-status or @NagyZoltanPeter approves

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

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

[fryorcraken]

I am not sure I agree with this syntax. WDYM by default: "message:sent"? what other vale could it be?

I would suggest to opt for the syntax proposed in https://github.com/waku-org/specs/pull/86/files

The object that emit events, define the "topics" of the events (eg message:sent):

types:
  EventEmitter:
    type: event_emitter
    description: "An event emitter for general node events."
    events:
      "error:subscribe":
        type: string
        description: "Event emitted when subscription to a content topic irremediably fails. The event contains an error message."

And here, if you want you can have type: MessageSentEvent instead of type: string and defined MessageSentEvent with 2 fields: message_hash and request_id.

[weboko]

WDYM by default: "message:sent"

I meant that eventType is a property on an object that has value of message:sent

I don't understand this syntax:

events:
      "error:subscribe":
          type: string
          description: "..."

what is error:subscribe and how exactly it is a string and how to get access to it?

for the syntax I used message:sent is a value of eventType property that is defined on the type of MessageSent object

wdyt @fryorcraken

[fryorcraken]

• the yaml syntax for even types and emitting needs to be reworked,
• you need to actually define the send and event emitter fields on WakuNode type definition
• do as you think best re ephemeral
• We need to give the message_hash to the consumer: I suggest to return it along side the request_id on all events (message:sent, message:propagated, message:error). Could be optional so that we can use the same type across all event, and not set message_hash if not relevant.

[fryorcraken]

I am not merging till @Ivansete-status or @NagyZoltanPeter approves

I would recommend to have a nim PR first before merging the spec

[NagyZoltanPeter]

Approving it as IMO what's discussed is something Nim implementation can follow.

[NagyZoltanPeter]

I am not merging till @Ivansete-status or @NagyZoltanPeter approves

I would recommend to have a nim PR first before merging the spec

Ok, draft will be tere next week.

[Ivansete-status]

LGTM! Thanks for it! 💯
Just added some nitpicks that I hope you find useful

[fryorcraken]

I don't think the event syntax works. here is a proposed alternative: #94 (review)

[NagyZoltanPeter]

@weboko
I'm fine with the MessageEnvelop, more because it is better aligned with my current nim-ffi proposal :-).
But I think I missed the convo about the MessagePropagated vs MessageSent events diffs.
When do we emit which?

[weboko]

@NagyZoltanPeter added description to the events

@fryorcraken added your event emitter syntax with slight change (description is in the event object definition and not in event emitter)

[fryorcraken]

Merged with minor change:

• no need to introduced new "properties" section, instead, define the message_events field on WakuNode as it is not clear what "properties" are related to.
• some other minor fix after a quick LLM review