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

Returning results from Relayer #1062

Open
JesseAbram opened this issue Sep 23, 2024 · 2 comments
Open

Returning results from Relayer #1062

JesseAbram opened this issue Sep 23, 2024 · 2 comments
Labels
Discussion Fix something that's not working as intended
Milestone

Comments

@JesseAbram
Copy link
Member

in #1050 we now have a relayer taking in the messages from all signers and passing it to the client.

The question is how should we handle that, how much pre processing and checking should we do.

What is the safest and best UX choice for the user

Some relevant comments

#1050 (comment)

#1050 (comment)

@frankiebee
Copy link
Contributor

frankiebee commented Oct 11, 2024

curent behaviors leave much to desire. previously we were able to read the stream response directly as json. that now returns undefined we have get as a utf8 blob which once decoded looks like this:

result string:

[
  {"Ok":["0su+wghEQsfw845m7A477mnt3pWRXgOPRFqmvHPusN9u7eOrY38q5IISe/ripZ6djxsHJf+H8dyTZYtSQunoPwA=","663476e2870f96d3e44b2b0a11f25cf9ac04ab3fbff916c7bddfaf87bed53822039eb78e26df3f1bdf23e5012fc48bc766de16b654b3e37aa61fb924a3dae881"]},
  {"Ok": ["0su+wghEQsfw845m7A477mnt3pWRXgOPRFqmvHPusN9u7eOrY38q5IISe/ripZ6djxsHJf+H8dyTZYtSQunoPwA=","1220344a1d5a4d0f47f366fc24baec97b9c0ba25d0532278ea913f55fe441b34ec13f32f4e65fda90175adb4c477917fa5e16cc3f294e2ba9b561dbd7cac438c"]}
]

desires:

  • the public key of the signer would be nice rather then blindly validating we can check to see if we have that public key then validate the "proof"
  • it would be nice to get an object back rather then a list. something like:
{
  signature: '0su+wghEQsfw845m7A477mnt3pWRXgOPRFqmvHPusN9u7eOrY38q5IISe/ripZ6djxsHJf+H8dyTZYtSQunoPwA=',
  proof: '1220344a1d5a4d0f47f366fc24baec97b9c0ba25d0532278ea913f55fe441b34ec13f32f4e65fda90175adb4c477917fa5e16cc3f294e2ba9b561dbd7cac438c', 
  signer_public_key: '0x123...',
}

Questions:

  1. why are there multiple signatures + proofs coming back?
  2. why are there 2 proofs, when we have 3 signers?
  3. if we only need to check one proof ... why are you sending 2?
    • what happens if one of the proofs is not validateable?
  4. these proof objects have "Ok" in them ... is there a "no Ok" or "Error" trype response?
  5. is there a reason you are streaming results? could you just collect and then send as one on your side? (because we wait and collect the stream on our side before decoding)
  6. is their documentation?

@JesseAbram
Copy link
Member Author

JesseAbram commented Oct 11, 2024

  1. the multiple signatures are from the signers that signed the message
  2. T = 2 signers = 3 only 2 signers sign
  3. that would be up to the client, the point in not selecting one is to not be opinionated or trusting of the relayer, here are the messages back
  4. "Err" see here for an example
  5. @ameba23 initially implemented it, and I was following that, idk could probably make it an object
  6. On the endpoint yes here for higher level documentation @johnnymatthews and I are working on it soon

As for sending the public key back ya sure if the client checks that, that key is in the signer however I would be worried they would just assume it is

@HCastano HCastano added Fix something that's not working as intended Discussion labels Oct 18, 2024
@HCastano HCastano added this to the v0.4.0 milestone Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Fix something that's not working as intended
Projects
Status: 📋 Backlog
Development

No branches or pull requests

3 participants