IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When including rust-ipfs as a dependency in any crate, it fails with the following error:
```
error: failed to select a version for the requirement `aesni = "^0.7"`
candidate versions found which didn't match: 0.99.99, 0.10.0, 0.9.0, ...
location searched: crates.io index
required by package `aes v0.4.0`
... which is depended on by `aes-gcm v0.6.0`
... which is depended on by `snow v0.7.1`
... which is depended on by `libp2p-noise v0.30.0 (/home/alexander/dev/misc/rust-libp2p/transports/noise)`
... which is depended on by `libp2p v0.37.1 (/home/alexander/dev/misc/rust-libp2p)`
... which is depended on by `libp2p-relay v0.2.0 (/home/alexander/dev/misc/rust-libp2p/protocols/relay)`
```
This fix updates the libp2p version into one that has a fix for this dependency and now it compiles fine
Includes replacing `upgrade::{write_one, read_one}` with `upgrade::{write_length_prefixed, read_length_prefixed}` respectively, which is a direct consequence of [PR2111](https://github.com/libp2p/rust-libp2p/pull/2111).
this was not set originally because probably mpart-async sets it, but
the code in `ipfs` assumed `std` feature was enabled and thus the from
conversion was accessible.
not a nice thing to do but there remains an issue with the dependencies,
and the libp2p tokio-mdns feature is gone. there are also some conflicts
remaining.
353: Implement /dns and /resolve r=ljedrz a=ljedrz
Add a rudimentary implementation of the `/dns` and `/resolve` endpoints; putting it out there already, as due to the similarity of these two endpoints I'm not 100% sure how much we want to "condense" their inner workings.
This upgrades or conformance suite stats from
```
170 passing
50 pending
```
to
```
178 passing
42 pending
```
Co-authored-by: ljedrz <ljedrz@gmail.com>
359: This PR uses libp2p dns, so that /dns4 and /dns6 multiaddrs can be dialed. r=koivunej a=rklaehn
Not quite sure how to best test this without having a test that uses the dns of the CI server. Any ideas?
Co-authored-by: Rüdiger Klaehn <rklaehn@protonmail.com>
concurrent writers will not retry if the first one fails. writing is now
done through tempfile which might be better, but relies on filesystem
being journalled and ordering the rename after fsync correctly.
349: Continued pinning r=koivunej a=koivunej
This PR adds the remaining `pin/*` APIs, with a bad implementation of recursive pinning. Aim is to inch forward to see a more proper implementation.
Compared to older pin storage implementations in go-ipfs at least this jumps right into using a "datastore" similar to the previous implementation. However I quickly found that the pin storage could not work on the simple datastore API. Instead of turning the datastore API into versioned and Repo level pin operations retryable on races this adds a version of `PinStore` which assumes locked access.
Recursive pinning is the slowest and most space inefficient variant: store all indirect pins. It doesn't seem wise but I am inclided to keep that at least for this PR. When adding a recursive pin, first the root is marked as `Recursive::Intent`, followed by marking all references as pinned `Indirect` from this root, followed by marking the root as `Recursive::Count(number_of_references)`. Writing down the indirect pins is likely not a proper way to do implement this, as this scheme requires all of the machinery only recording the recursive pinning for the root would require, but has some additional steps, and space use. It does not however require inmemory caching as the storage space is the cache.
There will be a long way to go towards a proper transactional, persistent pin storage (or even supporting one) after this PR but I aim to get the HTTP API tests going in this PR, or at least most of them. Probably scoping out the `pin (add|ls|rm) IpfsPath` for just supporting Cids at the moment.
Definitely not included:
- `pin/rm` with multiple arguments; can't see how could this be possible to implement without proper transactional datastore
- recovery from partial recursive pins
Removed:
- `ipfs::repo::Column::Pin` and related paths
Not sure yet:
- how to structure the `pin/ls` response formatting code
- keep the string-precise anyhow errors or do proper error enums?
TODO:
- `pin/ls` non-streaming response
The `pin/ls` responses are quite difficult beast.
### Checklist (can be deleted from PR description once items are checked)
- [x] **New** code is “linted” i.e. code formatting via rustfmt and language idioms via clippy
- [x] There are no extraneous changes like formatting, line reordering, etc. Keep the patch sizes small!
- [ ] There are functional and/or unit tests written, and they are passing
- [ ] There is suitable documentation. In our case, this means:
- [ ] Each command has a usage example and API specification
- [ ] Rustdoc tests are passing on all code-level comments
- [ ] Differences between Rust’s IPFS implementation and the Go or JS implementations are explained
- attempted this at the `ipfs::Ipfs` level method docs
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
