forked from Peergos/nabu
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Merge upstream #19
Merged
Merged
Merge upstream #19
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
refactor EmbeddedIPFS to configure RAM version of stores.
add shutdown hook implicitly so client does not need to
connected peers before resorting to DHT findProviders
Optimise legacy bitswap usage
candidates for bitswap broadcast Make bitswap tolerate errors connecting to some peers disable TLS by default until it is less noisy (pun intended)
Improve bitswap peer selection
Update jvm-libp2p to remove DNSADDR logspam
with pre generated keys
Support resolving rsa ipns mappings
naturally, some things had been missed / messed up whilst merging and only statically analyzing desired behaviour, but alas - we managed to pass all the tests, so we must be good.
turned out later on that this refactor from the upstream is breaking for us since we need to use Nabu with custom protocol IDs which significantly diverge from the upstream's vision. Has been noted in a comment, too.
Issue was: when using transitive dependencies in Fruzhin (unfortunately, a lot of those have sneaked in, but we'll have to clean them out) there was a weird invalid signature exception. Solved using the answer here: https://stackoverflow.com/a/6743609/24275638
Add bulk get links call which can be used to efficiently mirror a whole DAG
This file doesn't belong in source control as a deterministic byproduct of the build process.
David-Petrov
force-pushed
the
chore/merge-upstream
branch
from
April 29, 2024 13:08
663427b
to
1b7d9f6
Compare
ablax
approved these changes
Apr 29, 2024
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The situation on the latter is as follows:
On the one side, we could minimize the Jar (as the original author initially intended). This leads to only partial "leaks" of transitive dependencies, which results in things like Apache Commons or Guava not leaking entirely into Fruzhin. This is good from a code hygiene (and efficiency) standpoint. However, when it comes to our use case, we're heavily relying on the public interface of
Netty
which is a direct dependency ofNabu
, but since the parts from Netty we need are not directly used in Nabu, they're stripped off and we'd have to go the manual way of re-implementing them or explicitly re-exporting them... which is a viable solution, nonetheless a little too random for now. In other words, particular solutions for this case are not worth it since the jar minimization from the shade plugin doesn't solve the issue of transitive dependency leaks in the first place.On the other side, a lot of dependencies are still leaking into Fruzhin and we'll have to manage duplications / version mismatches from there. The dev experience of having three kinds of
Pair
classes loaded into your classpath (for example), or similar issues, will continue to have to be resolved by inner-team conventions for now.So, we stick with option 1. for now...