-
Notifications
You must be signed in to change notification settings - Fork 224
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: indexer resolution #476
Conversation
behaviour is now merged into the FullResolver
This is largely reviewed-and-vetted (but not well tested) code written by @dignifiedquire that we don't want to let get too stale. Feel free to put as much or as little time into review as necessary. I can provide context on indexers & whatnot if needed |
It is weird for a p2p system to do such things: call gateways and indexer nodes via http. Might as well put the data on s3. But it seems to do what it advertises... |
iroh-resolver/src/indexer.rs
Outdated
{ | ||
let mut bytes = unsigned_varint::encode::u32_buffer(); | ||
unsigned_varint::encode::u32(*t as u32, &mut bytes); | ||
serializer.serialize_str(&base64::encode(&bytes)) |
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.
probably want to make stable clippy happy here and remove the &
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.
It seems to do what is advertised.
I find it weird, so let's do it for now and try to get rid of it at some point. Not this code - the whole concept of a p2p system using centralised indexer nodes and gateways...
See the comments for some minor improvements.
iroh-api/src/api.rs
Outdated
FullLoaderConfig { | ||
http_gateways: config | ||
.http_resolvers | ||
.clone() |
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.
.iter()
.flatten()
instead of
.clone()
.unwrap_or_default()
.into_iter()
would avoid having to clone things.
iroh-gateway/src/bad_bits.rs
Outdated
let loader_config = FullLoaderConfig { | ||
http_gateways: config | ||
.http_resolvers | ||
.as_ref() |
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.
This is just a test, but
.iter()
.flatten()
.map(|u| GatewayUrl::from_str(u).unwrap())
would look less weird.
iroh-gateway/src/core.rs
Outdated
let loader_config = FullLoaderConfig { | ||
http_gateways: config | ||
.http_resolvers | ||
.as_ref() |
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.
.iter()
.flatten()
.map(|s| &s[..]) | ||
.unwrap_or(&[][..]) | ||
.iter() | ||
.map(|u| u.parse().unwrap()) |
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.
Can we collect into an anyhow::Result and do the unwrap outside? If the strings are unparseable, this whole method will panic, right?
Ah, right, this is only used from tests. Then it is OK I guess. Although I usually also use anyhow::Result<()> in tests.
async fn fetch_car_recursive() -> anyhow::Result<()> {
will fail the test if an error is returned.
iroh-gateway/src/main.rs
Outdated
FullLoaderConfig { | ||
http_gateways: config | ||
.http_resolvers | ||
.clone() |
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.
.iter().flatten()
iroh-one/src/main.rs
Outdated
http_gateways: config | ||
.gateway | ||
.http_resolvers | ||
.clone() |
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.
.iter().flatten()
Probably not the place to discuss this, but anyway: I don't see IPFS primarily as a p2p system, but as a content based addressing stack. The beauty of that is that you can rely on whatever transport and should use the most efficient one in all situations, which p2p often is not... |
supersedes #416. Using a separate PR to keep things comparable. Updating this branch changed a lifetime parameter that has me somewhat concerned.