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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
solved this wrong by isolating it first at http level, however now at
the ipfs::unixfs::cat level the http implementation is looking small as
it should be.
touched some error types and converted them to thiserror.
perhaps the error message requirements have changed, since this worked
right away? aah nope, they must concern other uses of walk_path. well,
this passes the tests either way.
for example, we might want to just do the splitting manually over a
String. this can be added back, but right now it allowed removal of
unnecessary dependencies at tests.
320: Implement Ipfs::find_peer and /dht/findpeer r=koivunej a=ljedrz
Builds on https://github.com/rs-ipfs/rust-ipfs/pull/319, only the last 2 commits are new.
Introduces `Ipfs::find_peer` and `/dht/findpeer` that return addresses belonging to the given `PeerId`; if they are connected to already, the values are returned right away, otherwise the local DHT records are checked.
Blocked by https://github.com/rs-ipfs/rust-ipfs/pull/319.
Co-authored-by: ljedrz <ljedrz@gmail.com>
315: Use explicit Multiaddr wrappers r=koivunej a=ljedrz
Whether a `Multiaddr` contains `Protocol::P2p` (i.e. essentially `/p2p/PeerId`) or not has a lot of bearing on conformance tests, the internal object and APIs and error-handling. Since it is easy to introduce related human errors, it would be a good idea to enforce some type safety here by introducing 2 wrapper objects: `MultiaddrWoPeerId` and `MultiaddrWithPeerId`.
The extent to which they should be applied (in lieu of `Multiaddr`) is a matter for discussion - in my initial attempt I decided to apply them quite liberally, as it results in more type safety (there are still a few plain `Multiaddr`s left though).
Co-authored-by: ljedrz <ljedrz@gmail.com>
110: add: p2p suffixes to multiaddrs from identify r=koivunej a=koivunej
not verified but indirectly used by the conformance tests when dialing a peer with an expected peerid.
Not 100% sure if this should be done, at least long as #105 is done at least to accept the multiaddrs with `/p2p/`.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
Co-authored-by: ljedrz <ljedrz@gmail.com>
Walker was being moved for each iteration and this was being a problem
for proper `Entry` matching.
Removes `Item` indirection and `continue_walk(self, ...)` is now
`inspect(&mut self, ...)`.
This patch changes the warp filter boxing strategy so, that:
1. paths are nested with a "prefix" matcher, if possible
2. the actual handler for the matched path is boxed
3. the non implemented but recognized paths are unified
This strategy might be a good compromise between optimizations and
compilation time but such measurements are yet to be done.
Previous boxing strategy ended up being quite unfortunate. Upon adding
the full `/add` implementation, the test cases using GNU binutils linker
or ld 2.33 (ubuntu) started failing failing with a thread overflowing
its stack.
Most of the stack frames were warp filters for matching the path. This
happened because the combine! macro used in http/src/v0.rs boxed
(mostly) each filter, meaning the compiler could never see through any
of the and requiring enough many frames at runtime to cause a stack
overflow.
An alternative of opt-level = 1 turned out to be easy and simple and was
explored in #293 while this solution was being searched for. The
downside is increased compilation time.
adds the progress reporting, which is a progress notification to the
response stream on every block write *in addition to* a notification
*after* the file has been read (order with the `Added` message doesn't
seem to have been specified).
this is the go-ipfs 0.5 level support for add and directories. next up
will be parsing the headers as unixfsv1.5 metadata and using those with
the directories *and* files.
290: Some maintenance r=koivunej a=ljedrz
Some maintenance work so as not to conflict too much with the pending PRs:
- depend on cid instead of libipld where only Cid is used
- update the `domain` dep (big `Cargo.lock` wins)
cc #75
Co-authored-by: ljedrz <ljedrz@gmail.com>
272: Split Entry into two different enums to remove unnecessary expects r=koivunej a=c410-f3r
Second take on #200
`Entry` is now composed of `Bucket(...)` and `Metadata(MetadataEntry { ... })` to separate things that have and doesn't have metadata, which avoids returning optional values derived from a single entry-point.
Next PR will address the newly introduced double matching while iterating over `continue_walk` but it will require deeper logical changes.
Co-authored-by: Caio <c410.f3r@gmail.com>
267: ci: use vcpkg for openssl on windows r=ljedrz a=koivunej
Hoping to find something to help with #261:
- switch to using [lukka/run-vcpkg](https://github.com/lukka/run-vcpkg)
- get rid of the llvm dependency on windows (it was not needed)
- update openssl dep to 0.10.30
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
259: Multihash-based repo r=koivunej a=ljedrz
We currently have an ad-hoc `Cid`-upgrading mechanism in place for the legacy `v0` version that is complicated and error-prone; when working on the `SubscriptionRegistry` I had to disable some of those upgrades, but some of them were still applied in the `Repo` (and necessary in order for the conformance tests to pass), making it hard to work on further functionalities like content discovery.
The solution I came up with is to introduce a `RepoCid` wrapper in order to make the keys in `Repo` objects operate on the associated `Multihash` instead of the whole `Cid`. Changing them to plain `Multihash`es wouldn't work, as we are still expected to return `Cid`s for the purposes of e.g. `Ipfs::local_refs` and I'm pretty sure some of the conformance tests still expect the full `Cid` to be available.
The only drawback is some extra `clone()`ing, but the improvement in code clarity and the unblocking of further changes is well worth it. This change also simplifies one of our conformance test patches (local refs).
~~I'm marking this PR as a draft in hopes that I can still come up with some solution to the extra cloning.~~ This is hard; I'm not able to do this at the moment, but this shouldn't be a blocker.
Co-authored-by: ljedrz <ljedrz@gmail.com>
240: Initial file add r=koivunej a=koivunej
Adds initial file adding through `/add` interface. Does very little of else.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
233: Add http timeouts r=ljedrz a=koivunej
Related to #228, this adds timeout handling to:
* `block/get`
* `dag/resolve`
* `refs` (partial)
* `cat` (partial)
* `get` (partial)
Partial means only the initial step of at minimum path walking has the timeout. We cannot yet return errors from streamed bodies because of the lack of `Trailer` support in hyper, so no "request timeout" is enforced once we get to streaming the body.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
231: Streaming multiparts: pubsub r=ljedrz a=koivunej
This was seen originally but at least it seemed some months ago that there wasn't a way to process multiparts streaming. Luckily the older js-ipfs-http-client puts the message in query. Later versions related to #228 use multipart bodies, but the topic is still a query argument.
Depends on #230.
* Adds test for the older query part message parsing
* Uses `&'static str` instead of `&'static [u8]` (fixes error messages)
The latest version should leave us failing only the conformance tests related to:
* pinning
* `?timeout=<not sure what unit>`
* refs
* cat
* get
* block/get
* dag/get
* wantlist
This is:
```
146 passing (3m)
21 pending
8 failing
```
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
230: Streaming multiparts at block/put and dag/put r=ljedrz a=koivunej
Supercedes #225 to cover `dag/put`. I'll close the earlier and keep this as a draft while the temp git dependency is in place.
This allows accepting multipart bodies without Content-Length header by using mpart-async. Uploads are limited to 1MB.
As minor fixes this includes checking `dag/put?input-enc=raw` as we don't support any other input-enc at the moment (rust-ipld could read dag-json, this was implemented during phase1 already).
As more minor fixes this includes transformation of LengthRequired rejection to "Missing header: content-length" instead of "UNHANDLED REJECTION".
Fix is needed for #228.
Co-authored-by: Joonas Koivunen <joonas@equilibrium.co>
this is minor change but good for interop. the conformance tests only
exercise the input-enc=raw as js-ipfs-http-client does most of the heavy
work. not checking input-enc could end up someone trying to put a json
dag document expecting it to be transformed to cbor, which we currently
do not support.
