Skip to content
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

feat(rln-relay): abstract group management into its own api #1465

Merged
merged 18 commits into from
Jan 16, 2023

Conversation

rymnc
Copy link
Contributor

@rymnc rymnc commented Dec 14, 2022

Proposes a GroupManager, which will be a field on WakuRlnRelay, having a standard interface across all implementations. This aims to solve the issues related to readability of the code when it operates in different modes.

  • feat(rln-relay): group manager api

TODO (not exhaustive):

  • Implement event listener for onchain group manager
  • Move rln.nim into an ffi directory, with its wrapper procs (insertMember etc)
  • Move conversion utils into its own file
  • More tests for static group manager
  • clean up utils.nim

In follow up PR:

  • refactor mount to include group managers
  • move constants to appropriate locations

@rymnc rymnc added this to the Release 0.14.0 milestone Dec 14, 2022
@rymnc rymnc added track:maintenance track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications labels Dec 14, 2022
@rymnc rymnc self-assigned this Dec 14, 2022
@status-im-auto
Copy link
Collaborator

status-im-auto commented Dec 14, 2022

Jenkins Builds

Click to see older builds (4)
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ cfaf874 #1 2022-12-14 23:00:56 ~13 min macos 📦bin
82fd516 #2 2022-12-15 23:04:08 ~16 min macos 📄log
✔️ 134b664 #3 2022-12-16 23:01:55 ~14 min macos 📦bin
✔️ d864535 #4 2023-01-03 23:02:10 ~14 min macos 📦bin
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ 4135b87 #5 2023-01-12 23:04:08 ~16 min macos 📦bin
✔️ 776b616 #6 2023-01-13 23:01:19 ~13 min macos 📦bin

@rymnc
Copy link
Contributor Author

rymnc commented Dec 16, 2022

Note: imo we should create a separate PR to integrate these changes into the rln-relay itself. At the current moment, I have not removed any code from the utils.nim file, and left it as is for ease of review.
It's already 1500 loc :0

@rymnc rymnc marked this pull request as ready for review January 4, 2023 03:52
@rymnc rymnc requested review from LNSD and s1fr0 January 9, 2023 08:07
Copy link
Contributor

@LNSD LNSD left a comment

Choose a reason for hiding this comment

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

Please, check my comments 🙂

Comment on lines 10 to 17
export
rln,
ffi,
constants,
protocol_types,
protocol_metrics,
conversion_utils,
utils,
contract
Copy link
Contributor

Choose a reason for hiding this comment

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

Are the members of all these modules used outside the waku_rln_relay module?

Typically you only expose/export the APIs used outside of the module, nothing else. This prevents the misusage of the module.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, we do test even the ffi to ensure that breaking upstream changes are detected whenever we update submodules

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. But... One thing is the module APIs, and another thing is testing.

A clean API without exposing internal symbols (types, methods, etc.) helps prevent the library's misusage that could break the program. You'll still be able to test the different submodules by importing them explicitly in the test file/module at the moment of testing.

Said that, do you still think that we should expose everything in this module?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, we should just be functionally testing the logic. Tracking the fix - #1489

Comment on lines +44 to +54
proc appendLength*(input: openArray[byte]): seq[byte] =
## returns length prefixed version of the input
## with the following format [len<8>|input<var>]
## len: 8-byte value that represents the number of bytes in the `input`
## len is serialized in little-endian
## input: the supplied `input`
let
# the length should be serialized in little-endian
len = toBytes(uint64(input.len), Endianness.littleEndian)
output = concat(@len, @input)
return output
Copy link
Contributor

Choose a reason for hiding this comment

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

appendLength()

But:

... length prefixed version of the input ...


I would call this method something like encodeLengthPrefixed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will address when fixing #1487 :)

rootsBytes = concat(rootsBytes, @root)
return rootsBytes

proc serializeIdCommitments*(idComms: seq[IDCommitment]): seq[byte] =
Copy link
Contributor

Choose a reason for hiding this comment

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

The two methods above are named as simple as serialize; this is serializeIdCommitments. I think that we need to improve the consistency in the procs naming and use only one naming schema :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will address when fixing #1487 :)

Comment on lines +130 to +148
proc toIdentityCredentials*(groupKeys: seq[(string, string)]): RlnRelayResult[seq[
IdentityCredential]] =
## groupKeys is sequence of membership key tuples in the form of (identity key, identity commitment) all in the hexadecimal format
## the toIdentityCredentials proc populates a sequence of IdentityCredentials using the supplied groupKeys
## Returns an error if the conversion fails

var groupIdCredentials = newSeq[IdentityCredential]()

for i in 0..groupKeys.len-1:
try:
let
idSecretHash = hexToUint[IdentitySecretHash.len*8](groupKeys[i][0]).toBytesLE()
idCommitment = hexToUint[IDCommitment.len*8](groupKeys[i][1]).toBytesLE()
groupIdCredentials.add(IdentityCredential(idSecretHash: idSecretHash,
idCommitment: idCommitment))
except ValueError as err:
warn "could not convert the group key to bytes", err = err.msg
return err("could not convert the group key to bytes: " & err.msg)
return ok(groupIdCredentials)
Copy link
Contributor

Choose a reason for hiding this comment

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

This proc could be collocated with the IdentityCredential type. In the "utils" modules, which I abhor and avoid, you should keep only things that are common to everything (e.g. toHex(), encodeLengthPrefixed(), toEpoch() or fromEpoch()).

Please review this module and see if it makes sense to collocate other methods next to the types based on the module imports graph. This is: if you are importing this utils module to use that proc, and the proc is not used elsewhere, then the proc is not in the right module.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will address when fixing #1487 :)

Comment on lines 10 to 11
rln,
ffi,
Copy link
Contributor

Choose a reason for hiding this comment

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

Honestly, I prefer the rln name since it comes from librln. The ffi and wrapper names are too generic.

For example, I would name ffi a module that contains utilities to do ffi in an easier/opinionated way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would you prefer librln to be more explicit?

Copy link
Contributor

Choose a reason for hiding this comment

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

AFAIK in nim, the convention is to name the module after the library without the lib part (like in Rust, binding crates are appended with -sys). I prefer just rln, but I don't have a strong opinion as far as it is descriptive and not generic like ffi or wrapper :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in 0f6a3a9 and 42231ae (some gitignore shenanigans)

type GroupManagerResult*[T] = Result[T, string]

type
GroupManager*[Config] = ref object of RootObj
Copy link
Contributor

Choose a reason for hiding this comment

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

You declared the interface (the base object) here, but the associated procs are not using the method statement and the {.base.} pragma. Is there any reason for that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oops! looks like this change was pushed by mistake, Addressed in 4135b87, thanks!

@rymnc rymnc modified the milestones: Release 0.14.0, Release 0.15.0 Jan 12, 2023
@LNSD
Copy link
Contributor

LNSD commented Jan 12, 2023

One question/suggestion regarding the module's structure:

Would it be possible to move the rln (a.k.a. ffi in this PR) module to the waku/common folder? I see the RLN wrapper as a module that should be standalone, and the waku_rln_relay module should depend on this common module.

When doing the exercise to move the module to the common's folder, you have crossed dependencies (rln depending on waku_rln_relay and vice-versa), then there is something in the code layout that should be reviewed.

Disclaimer: I have not tried it. But from my experience, the likeliness is high when refactoring code and making it more modular.

@rymnc
Copy link
Contributor Author

rymnc commented Jan 16, 2023

@LNSD can I merge this now?

Copy link
Contributor

@LNSD LNSD left a comment

Choose a reason for hiding this comment

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

LGTM ✅

@rymnc rymnc merged commit 605cf1c into master Jan 16, 2023
@rymnc rymnc deleted the group-manager-api branch January 16, 2023 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants