-
Notifications
You must be signed in to change notification settings - Fork 5
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
MessageCache and LightNode #59
base: main
Are you sure you want to change the base?
Conversation
26146b7
to
603afef
Compare
I started using v1 posts instead of v0 posts. I wonder why we did not earlier, as it seems a cleaner, albeit minimalistic, endpoint for getting posts. There should be no problem in changing back to v0 posts though. |
d2d3264
to
a99fa66
Compare
A few points on my ToDo list:
|
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.
Reviewed ~70% of it, some changes and questions.
778ae95
to
06fb6f9
Compare
06fb6f9
to
cd62d4c
Compare
Implemented all of the suggested changes by @odesenfans, highlights:
|
a146f5a
to
0e3102f
Compare
0e3102f
to
59d361d
Compare
Addressed issues, but Olivier can't review them anymore.
Failed to retrieve llama text: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) |
Context size not enough, I rate this PR manually as |
59d361d
to
6f286fc
Compare
A LightNode can synchronize on a subset, or domain, of aleph.im messages. It relies on the MessageCache, which manages a message database with peewee.
…ust `create_program` methods on `LightNode`
ac6a28c
to
77bdf1b
Compare
This PR adds +1,937 and -16 lines of code to the project. What is the impact of this PR on the test coverage ? |
It actually improved relatively, as the new code has more coverage than the existing one. |
ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate when using the function: AuthenticatedAlephHttpClient I searched on the internet for a way to solve this problem, but all the commands/advice given didn't work. So I thought it would be a good idea to give the user the option of specifying a specific SSL certificate if they wish. This worked in my case and gave me the option of continuing to use the SDK provided by Aleph.
I had the following problem: ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate when using the function: AuthenticatedAlephHttpClient I searched on the internet for a way to solve this problem, but all the commands/advice given didn't work. So I thought it would be a good idea to give the user the option of specifying a specific SSL certificate if they wish. This worked in my case and gave me the option of continuing to use the SDK provided by Aleph.
Co-authored-by: Mike Hukiewitz <[email protected]>
The problem was with the connector type: src/aleph/sdk/client/http.py:55:25 : error : Incompatible types in assignment (expression has type "UnixConnector", variable has type "Optional[TCPConnector]") I have therefore declared the connector as a union of possible BaseConnector or None types. This means it can be any aiohttp BaseConnector or None.
Users could not easily import or migrate accounts using their mnemonic representation. Solution: Add a static method `from_mnemonic` on the `ETHAccount` class. Discussion: This is a first step and this behaviour can be extended to more chains in the future.
Problem: Instances don't use program encodings. This argument was left from refactoring. Solution: Drop the argument.
Problem: Users of the SDK could not create instances with a specific payment method such as token streams. Solution: Add a new argument, `payment`, to `AuthenticatedAlephClient` and use it in the "Instance" messages generated. The argument is optional and defaults to "hold" on "ETH" for backward compatibility. Discussion: The argument is added just after mandatory arguments so it can be made mandatory in the future. This may however break backward compatibility with existing code that does not call the function using keywords arguments.
Problem: too strict aleph-message dependency Solution: loosen it to accept compatible versions to 0.4.2 Co-authored-by: mhh <[email protected]>
Problem: too strict aleph-message dependency Solution: loosen it to accept compatible versions to 0.4.2 Co-authored-by: Hugo Herter <[email protected]>
@@ -1,6 +1,6 @@ | |||
from pkg_resources import DistributionNotFound, get_distribution | |||
|
|||
from aleph.sdk.client import AlephHttpClient, AuthenticatedAlephHttpClient | |||
from aleph.sdk.client import AlephHttpClient, AuthenticatedAlephHttpClient, LightNode |
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.
Current discussion with @hoh : we might want to use another name for this class
Reopened with smaller scope from #31. Depends on #54.
Problem
Some apps require access to the same messages over and over again. This puts unnecessary strain on the CCN API and increases the latency of apps using Aleph Messages.
Solution
This pull request proposes a solution by introducing a message cache implemented with Peewee and an SQLite database in the Aleph SDK. The message cache effectively stores frequently accessed messages, eliminating the need for repetitive CCN API calls. With the message cache in place, apps utilizing the Aleph SDK will experience enhanced efficiency and responsiveness in accessing messages.