Plan 0.12 release

[Frando]

This is a tracking issues on what I think we should merge for a breaking 0.12 release soonish:

breaking changes

• Move to async/await Implement async API for random-access-storage #103
• Move to generic std::error::Error From Failure into std::error::Error #102
• Erase generic type argument from hypercore (do not merge yet) Erase generic parameter by boxing Storage as trait object #113

non-breaking changes

• New signatures for Hypercore 9 compat Include length in signatures (hypercore v9 compat) #112
• bugfix: put_data bugfix: fixed skewed range in put_data of Storage #110

I think it would be great to get those merged rather sooner than later, because at least the first three ones all change the public and internal API so that all other PRs oftenly have to be manually updated.

Because we don't have, I think, anyone using hypercore-rs, and because there is no one "properly" maintaining this at the moment, I propose that we let this issue sit here for a couple of days or a week and then go ahead, merge the PRs, and figure out bugs and issues in the process.

Also very open to other suggestions :)

[bltavares]

Awesome strategy creating this issue for tracking.

I will land the PRs this Sunday and release it with RC versions then, and we can promote a 0.12 after we are able to test all of this together

[bltavares]

Trying to set network in colmeia, I ended up with a design where a hyperdrive is contained inside a PeeredHyperdrive, and a hypercore is contained on a PeeredHypercore.

https://github.com/bltavares/colmeia contains a similar protocol layer to https://github.com/Frando/hypercore-protocol-rs, producing events. The peered version of each struct contains the struct and the protocol channel in order to drive the underlying struct.

There is a set of unimplemented! functions related to networking on hypercore, but I'm thinking that we might not be able to implement it as a 1:1 mapping to JS as how Rust ownership led me to design the network methods as a wrapper to the hypercore struct.

@Frando I'm wondering if you will endup with a similar desing as well, and if you endup on the same desing I think it would be better to remove the network methods (eg: have, unhave) and add them to the peered layer. This would be a breaking change that could go on 0,12. What do you think?

[dumblob]

What are the next steps?

I wonder if there is (will be) any hypercore implementation in pure Rust to allow being incorporated into DeltaChat along with IPFS.

[ttiurani]

Unrelated to this issue, but I've been working on JS v10 compatibility for a while. The branches are at:

https://github.com/ttiurani/hypercore/tree/v10

and

https://github.com/ttiurani/hypercore-protocol-rs/tree/v10

I'm currently testing my changes with upstream projects, but hopefully those will land at some point here. v9 -> v10 changed just about everything on the javascript-side so trying to keep v9 also working might not be worth the effort.

[dumblob]

@hpk42 as discussed in deltachat/deltachat-core-rust#3227 it seems @ttiurani works on bringing the recent hypercore to Rust.

So not everything is lost...

Thanks @ttiurani !

[cowlicks]

I think this issue can be closed seeing that 0.21.1 has been released. But what is to be done about #113 ?

[ttiurani]

Closing as plans changed with v0.12 was for hypercore v10 compatibility first. #113 did not make it yet, but should be seriously re-considered for v1.0.