openssh VS nearby

Released openssh-sftp-client 0.11.0 and worked on openssh-rust/openssh

In terms of the API, IMO openssh-rust/openssh offers a much more intuitive set of APIs than libssh2 and the libssh2 does not offer any async API (P.S. I only took a brief look at its doc).

Here're a few projects I considered interesting (including my own project) and relatively easy to participate: - pushgen Push-style design pattern for processing of ranges and data-streams. - compact_str A memory efficient immutable string type that can store up to 24* bytes on the stack - openssh-rs Scriptable SSH through OpenSSH in Rust - pegasus A multi-node parametrized command runner with a focus on simplicity - concurrent_arena Container that can have elements insert/removed concurrently and uses a 'u32' as key.

Did they? I know of https://github.com/google/nearby, but I don't think it's enough to implement. I could be wrong but...

nearby is open, hence my suggestion :) https://github.com/google/nearby

You may want to check this project out: https://github.com/google/nearby. It is in C++, though. It is a medium agnostic socket over bt and wifi. It seems similar to what you are trying to do.

Yeah, I respect the fact that Google made Nearby Share open-source recently (https://github.com/google/nearby-connections).

No plans for Linux right now. You're right that parts of the port would be easier for Linux than Windows. We have a /platform folder (https://github.com/google/nearby-connections/tree/master/cpp/platform/impl) that has abstractions for concepts like 'file', 'lock', and 'bluetooth_classic'. We're having to rewrite a lot of the core files ('file', 'lock', 'thread') for Windows while we could have reused what we already have if we were targeting Linux/MacOS. But rewriting the radio classes ('bluetooth_classic', 'wifi_lan', 'ble') would have had to happen regardless.

See: https://github.com/google/nearby-connections