feat!: Use Waku API for libwaku by fryorcraken · Pull Request #3490 · logos-messaging/logos-delivery

fryorcraken · 2025-07-03T06:40:50Z

Description

Demonstrate the Waku API defined in logos-messaging/specs#65 in libwaku.

Dependencies

Here are a list of changes to make this PR happen:

chore: use type for rate limit config #3489: enable instantiating the rate limit directly
chore!: make sharding configuration explicit #3468

Changes

...
...

fryorcraken · 2025-07-03T06:43:27Z

library/libwaku_conf.nim

+
+      ]
+    )
+nwakuCfg.RateLimits.Filter = &bindingscommon.RateLimit{Volume: 100, Period: 1, TimeUnit: bindingscommon.Second}


doing #3489 so that I can just instantiate the rate limits here.

github-actions · 2025-07-03T06:48:25Z

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3490

Built from df62371

fryorcraken · 2025-07-04T11:05:25Z

library/libwaku_conf.nim

+  AutoSharding
+  StaticSharding
+
+type AutoShadingConf* = object


Suggested change

type AutoShadingConf* = object

type AutoShardingConf* = object

Ivansete-status · 2025-07-04T15:52:03Z

library/libwaku_conf.nim

@@ -0,0 +1,66 @@
+import std/options, waku/factory/waku_conf, waku/factory/conf_builder


I think we need to rename this module to libwaku_sdk_conf.nim instead, to make it clearer it is aimed for the opinionated version of the library and not for the core libwaku

I would say this would only fix the tip of the iceberg.

I think waku folder should be named lib and library can be renamed sdk

One could argue that my new config should be in api folder.

Is this addressed by the "architecture and api" virtual offsite recommendation? I havent see a forum post.

Thanks for the suggestion! Let me share my 2cs in case of willing to rename folders.

I think waku folder should be named lib and library can be renamed sdk

waku folder is properly named IMHO. We cannot name it lib because it does not expose a library outside. Also, the current waku approach seems to be the idiomatic way of naming it. See for example: chronos chronicles

I would suggest keeping library folder and potentially create these folders as the need for that arises:

Create a new library/core/ folder and move the current library content there. libwaku-core will be compiled from there.

Create a new library/sdk folder that will host the opinionated libwaku-sdk. In that case, my original comment above would make much more sense.

summarizing: disregard my previous comment as it seems to be a premature optimization

Is this addressed by the "architecture and api" virtual offsite recommendation? I havent see a forum post.

We are working on it but I think this won't be covered there because that's a very specific for nwaku

I think we need to rename this module to libwaku_sdk_conf.nim instead, to make it clearer it is aimed for the opinionated version of the library and not for the core libwaku

"core libwaku" should not be exposed, and we should deprecate it. the Waku API should be the sole API exposed on FFI, do we agree?

"core libwaku" should not be exposed, and we should deprecate it. the Waku API should be the sole API exposed on FFI, do we agree?

I think it makes sense to only maintain Waku API, for the sake of optimizing resources. Nevertheless, core libwaku might be still relevant for future integrators. Then, IMHO we cannot strongly state that core libwaku should be deprecated. I think it will depend on its future demand.

fryorcraken · 2025-09-09T06:51:37Z

@waku-org/nwaku can I have feedback in terms of the location of the new artefacts?

fryorcraken · 2025-09-09T10:01:35Z

library/libwaku.nim


 import std/[json, atomics, strformat, options, atomics]
-import chronicles, chronos, chronos/threadsync
+import chronicles, chronos, chronos/threadsync, results


Need to revert

fryorcraken · 2025-09-09T10:03:18Z

library/libwaku.nim

@Ivansete-status I wonder if we should rename this file to libwaku_ffi.nim as it is more focused on FFI than actual library.

Yes, I think we can rename that

Ivansete-status

Some comments so far. Thanks! 🙌

Ivansete-status · 2025-09-09T10:07:57Z

library/libwaku.nim

Yes, I think we can rename that

Ivansete-status · 2025-09-09T12:26:48Z

library/libwaku_api.nim

+
+import ./libwaku_conf
+
+proc createNode*(config: LibWakuConf): Future[Result[Waku, string]] {.async.} =


It seems this createNode duplicates the following: https://github.com/waku-org/nwaku/blob/d74d29e2f1463289291769e2a2107c64868f9a04/library/waku_thread_requests/requests/node_lifecycle_request.nim#L96

The whole point here @Ivansete-status is to start a fresh Waku API, aligned with the spec logos-messaging/specs#65

There are 2 ways forward:

Modify existing functions

Create new functions

I went with (2) because until we have create, send, subscribe, it's going to be hard to dogfood. Also, makes it easier to not force upgrade to the new API in status-go integration, etc.

Ivansete-status · 2025-09-09T12:27:51Z

library/libwaku_conf.nim

@@ -0,0 +1,116 @@
+import


If possible, I would not add this file. It seems it adds an additional layer of possible bugs, when sending attributes between layers

We are defining a new API. These is the config for this new API. The existing API uses WakuNodeConf which is the CLI args one, and hence not adapted.

The intent is to move away from WakuNodeConf and have a config object that works for application developers.

fryorcraken · 2025-09-11T03:31:12Z

Superseded by #3564 due to nim-lang/nimble#1466

fryorcraken changed the base branch from master to waku-api/autosharding-config July 3, 2025 06:41

fryorcraken force-pushed the waku-api/network-config branch from c1cd55c to 23b3072 Compare July 3, 2025 06:42

fryorcraken commented Jul 3, 2025

View reviewed changes

Base automatically changed from waku-api/autosharding-config to master July 4, 2025 07:10

fryorcraken force-pushed the waku-api/network-config branch from 23b3072 to 19df60b Compare July 4, 2025 11:05

fryorcraken commented Jul 4, 2025

View reviewed changes

Ivansete-status reviewed Jul 4, 2025

View reviewed changes

fryorcraken mentioned this pull request Jul 16, 2025

Add nim-ffi suggestion logos-messaging/pm#325

Merged

fryorcraken force-pushed the waku-api/network-config branch from 19df60b to b56f0f0 Compare September 9, 2025 03:23

fryorcraken added 2 commits September 9, 2025 16:36

Waku API: create node

ca1b293

createNode

8cc1837

fryorcraken force-pushed the waku-api/network-config branch from b56f0f0 to 8cc1837 Compare September 9, 2025 06:50

fryorcraken added 2 commits September 9, 2025 19:30

test: use raiseAssert

5065ac4

move waku api to own file

7fa75cf

fryorcraken commented Sep 9, 2025

View reviewed changes

tests pass - validate conf

9fff57a

Ivansete-status reviewed Sep 9, 2025

View reviewed changes

fryorcraken added 6 commits September 10, 2025 12:19

missing import

119eadd

export Waku API

fd4feaa

remove dupe quic dependency (nim-libp2p is the one depending on it)

0eb2a46

revert changes

5f263f0

apply default values

b4d8dbf

match spec name (config)

84a4047

fryorcraken closed this Sep 11, 2025

	type AutoShadingConf* = object
	type AutoShardingConf* = object

		@@ -0,0 +1,66 @@
		import std/options, waku/factory/waku_conf, waku/factory/conf_builder


		import ./libwaku_conf

		proc createNode*(config: LibWakuConf): Future[Result[Waku, string]] {.async.} =

Conversation

fryorcraken commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Dependencies

Changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fryorcraken commented Sep 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ivansete-status left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fryorcraken commented Sep 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fryorcraken commented Jul 3, 2025 •

edited

Loading

github-actions bot commented Jul 3, 2025 •

edited

Loading