[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
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

Feature request: Include a timestamp in the return struct of the fetch_installation_keys RPC #61

Open
insipx opened this issue Feb 13, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@insipx
Copy link
Contributor
insipx commented Feb 13, 2024

Is your feature request related to a problem?

libxmtp filters installation keys by the timestamp they were committed

Describe the solution to the problem

We should return the block time in nanoseconds of the event in which the get_fetch_keys operation occurred, or add an extra field to that RPC to filter server-side

Describe the uses cases for the feature

allow libxmtp to get identity updates only after a certain time

Additional details

No response

@insipx insipx added the enhancement New feature or request label Feb 13, 2024
@insipx insipx self-assigned this Feb 13, 2024
@insipx insipx moved this to In Progress in D14N Work Feb 13, 2024
@jac18281828
Copy link
Contributor

Does it make sense to consider ‘seconds’ for this? Block times are seconds since epoch. These times can also differ from real time by a large delta. ‘Nanoseconds’ may lead to a belief that these times are more meaningful than they are.

@insipx
Copy link
Contributor Author
insipx commented Feb 15, 2024

Yeah I don't think it's a great metric by any means, but it's consistent with how libxmtp filters through installation_ids. I'll leave it in ns for the demo but it would make sense not to use timestamp at all in libxmtp and instead use block height and log index.

I think that seconds could be used instead of nanoseconds, libxmtp doesn't check for it, so I'll experiment with that too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

2 participants