Hacker Newsnew | past | comments | ask | show | jobs | submit | dd-dreams's commentslogin

Well aft features:

- Encryption. Currently the only algorithm in use is AES-128/256 GCM and for exchanging keys is x25519 Diffie-Hellman, but in the future there could be other algorithms such as XChaCha.

- Parallel Encryption (with an option to choose the amount of threads) which makes the transfer much faster.

- Peer-to-Peer and Relay Modes: Individuals who prefer not to open a port can utilize a relay service. Currently, there is no hosted relay available; however, if there is sufficient demand, I may consider establishing one. The relay does not get any information about the file.

- Blocking senders. Blocking senders is only supported in relay mode which allows for basically...blocking senders. It relies on an IP address (it's not shared with the receiver, only a hashed one).

- DNS lookups.

- More info in the GitHub page...

# Comparisons with other tools

I didn't look too much into the protocols of the tools you mentioned, but here some differences:

- croc and magic wormhole - (always?) uses a relay. Good for most cases, but it has some problems such as: transferring on local networks is not accounted for and relying on a relay. They might try to connect the receiver and the sender first but I'm not sure.

- rclone - not really the same purpose. rclone wants to sync files for cloud storage with popular providers or your own. aft wants to transfer files between any two devices but not syncing.

- sfk - if I found the correct one, sfk main concern is not file transfer but multiple utilities. aft is only for transferring files.

## Executables size

Last time I installed magic-wormhole, I was required to install 340MB of dependencies on a new VPS. aft was only a quick `sh` run away. croc on the same system is 13MB, but aft is 2.6MB.

## Speed

Currently aft matches almost the same download speed with croc and magic-wormhole (they're the only ones I tested of some quick runs) (might be even faster if you configure the amount of threads). But I do believe aft still has potential for making the transfer even faster. One of the reasons for this potential is because I'm using Rust, and Rust allows for low-level programming which might be useful here.

Regarding mDNS, I didn't look into it, but if there is demand I might.

edit: formatting and clarify


Great and detailed response, thank you. Well, I asked, because a longer while ago I wrote a cross platform tool named `graft` [1] to solve a similar issue: Having to transfer files without needing too much boilerplate on windows, linux and macOS.

`graft` is a "risk your files for convenience" tool with pretty bad performance - so I would not recommend using it for something else than `graft serve` and `graft receive`, but these two are pretty handy.

`graft serve ".zip"` will scan the current directory for `.zip` recursively, start a password authenticated sftp server and providing all findings (and only them) via `mdns`.

While you COULD use any sftp client, you also can use any other host in the same network supporting mdns to just `graft receive` (without hostname) and `graft` will find the running instances in the network. If it is only one, it will connect, otherwise you can choose.

This is indeed pretty convenient :-) - as I said, I wouldn't rely on this for important files.

1: https://github.com/sandreas/graft


So with aft you probably could use it for the same purpose you have, but currently aft doesn't support multi transfers, but rerun each time. In the future it will probably be added, or provide an easier way to multi-transfer.

About mDNS I'm not sure since if you're already running a receiver and a sender, might as well get the local IP. aft aims to be minimalistic.


Any plans for Android?


Yes! I need to test it on some devices first, then re-register as a play store dev.


Looks awesome. I hope you could find a way to make LLDB usable with Rust.


Yeah that's the next step probably. It initially had it's own debugger implementation but the scope for that was too great.


The development never stops. In a few years we will look back and see how the previous models were and how they're now. How we couldn't run LLaMa 70B on MacBook Air and now we can.


Yes it's pretty cool. There was a neat comparison of deep learning development that I think resonates quite well here.

Around 5 years ago, it took a lambda user some pretty significant hardware, software and time (around a full night), to try to create a short deepfake. Now, you don't need any fancy hardware and you can have some decent results within 5 min on your average computer.



There is also "aft"[0] (I'm the author) for transferring files between devices.

[0] https://github.com/dd-dreams/aft


Thanks for the feedback. Only an address is needed to be specified. There is a default port built into the source code. But, I believe in the near future I will add some kind of algorithm to extract IP addresses from phrases.

> The user probably shouldn’t need to think about whether it’s in p2p mode or not.

aft designs to be configurable, but I do believe your comment is right and something about it in the docs should be added. There is also a config file in this program, with a default `mode` property. It's not really used right now, but very soon it will be.


I never want to have to configure a file transfer program. For this to be useful to me, it has to be better than magic wormhole.


The only configuration you will do is choosing the mode you're gonna use (I don't even think it counts as configuration). There are a few modes, and as I said at the comment above, very soon you could choose the default mode.

Also, its OK not wanting to configure anything, but some people might find it useful. This program aims to include both types.


Thanks for the comment. Yes, it also does something very similar. But, Magic Wormhole requires "Mailbox Server", to deliver messages from one to another, which seems a requirement, where in aft it doesn't. It also requires both clients to be on the same "Mailbox Server" to transit messages between them. Requiring a server by default doesn't seems reasonable only to omit IP addresses.

Each program has it's unique benefits, Magic Wormhole looks great, but I do believe that aft gives you more configuration by default, and its more accessible to you.

Also, some people like Rust more than Python ;)

Edit: typo


It sure looks excellent, `aft` actually looks very similar to it with the same relay server idea. I don't know the program, but from a first glance, it looks like it requires a relay server. While I don't think it has any major disadvantages, but needing to communicate with an external service might not be reasonable for some people. And many times you might not require a relay server at all such as transferring on a local network, or from a VPS (maybe croc can identify if its on a local network, didn't dig enough into it). Well, you can host yourself a relay server, but it does require a bit more configuration.

Also, some people might like Rust more than Go ;)


> Also, some people might like Rust more than Go ;)

Why would this matter for users?


For users, not much since the performance is probably equal between Rust and Go. But for developers it might matter, such as forking the repository, or submitting pull requests and for other reasons they might have.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: