-
Notifications
You must be signed in to change notification settings - Fork 43
feat(sds): adds ephemeral messages, delivered message callback and event #2302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
size-limit report 📦
|
* @param payload - The payload to send. | ||
* @param callback - A callback function that returns a boolean indicating whether the message was sent successfully. | ||
*/ | ||
public sendEphemeralMessage( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generally curious why you separate ephemeral
from regular messages and not doing single send
entry?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially I tried that but decided that:
- the logic is different enough that it doesn't look clean in the code
- the concept is different enough that I want it to be as explicit/obvious as possible for the library consumer when an ephemeral message is being used. I don't believe it will be used often but we will see
5a3bc1b
to
a7f97b7
Compare
f43d4d9
to
3ba0f16
Compare
@@ -59,6 +59,7 @@ | |||
"node": ">=20" | |||
}, | |||
"dependencies": { | |||
"@libp2p/interface": "^2.7.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's make it strictly 2.7.0
3ba0f16
to
6b4848c
Compare
Problem / Description
Per the spec, SDS optionally supports ephemeral messages. These are messages that do not have the same persistence/reliability requirements as regular messages, and effectively skip the buffers.
Part of the requirement is that they are delivered right away upon receipt, which revealed that there's currently no way to notify the library consumer when a message reaches the delivered state.
Solution
Add a function for sending ephemeral messages.
Add an optional callback for delivered messages that is called whenever a message reaches that state.
Use libp2p event emitter to emit an event with the message ID when a message is delivered.
The number of optional arguments in the class constructor was getting large so I replaced it with a single options struct.
Notes
Checklist