Fleer

Not sure if Stardance will get extended until something like the end of September, so here am I (didn’t got many times to update the app and encountered many problems).

• A new command fleer relay followed by any Fleer Relay URL will output details about it.
• Receiver device name was sent in clear to the relay, it is now exchanged using encrypted messages.
• The transfer will be deleted if too many restarts happen (because messages size exceeds the limit for example).
• A structure containing all files, folders and path is included to give the receiver some visuals indications. If it’s too large, the structure will be dropped entirely.
• The amount of received/sent bytes will be displayed in Kbps instead of Mbps if it’s slow asf.
• Many bugs fixes and optimizations.
• The relay can now pauses transfers if it’s processing too many transfers at once.
• The indicated transfer size will include an estimated encryption overhead (the algorithm used can add some bytes to files).
• Transfers that shares MANY messages can use a feature from the relay that give clients ability to select the amount of cached bytes for messages and chunks.
• Inactives shares are deleted from the memory of the relay.
• The build version and latest commit pulled is returned to clients from the relay.
• Rate limits now apply to WebSocket messages.

Didn’t wrote many lines of code on this project the last few days, was busy with personnal things so I’m listing what I pushed this week:

• User can decide what to do if a file already exist in the current directory (replace it, rename the new one, or skip this file).
• A new command fdd allows to start a download even faster, by checking the first parameter (fdd <share_link>) or any URL in the clipboard.
• fleer send command can generate a QR Code image, and display it for supported terminals (such as the incredible Ghostty).
• Download speed is displayed live in Mbps.
• Some fixes concerning security and downloading in specific conditions.

A few minors QoL changes:

• The CLI is automatically closed when download is finished, synced for both sender and receiver through an encrypted message that acts as a signal to tell both party they have done their job.
• Share Link is automatically copied into the clipboard of the sender, even if he’s remotely connected via SSH to another server.
• The directory in which files are saved is displayed at the end of execution (default to current folder).
• Improved performances when downloading.
• Some more verifications with the relay server used.
• Protect against Path Traversal vulnerability.

Okay, changelog required even though I wasn’t planning on publishing it right now. Apart from some additions such as:

• --debug-socket flag that logs every actions happening between the client and a relay server
• Encryption protocol indicator (which is used by clients to know what algorithm and settings to use) is NOT known by the server anymore, as it is transferred in the share link itself
• Proper exit (and closure of spinner animations) when using Ctrl+C
• A few optimizations for responsive logs

Downloading files is ALMOST done, I’m currently having many issues with slow file upload, and many attempts at optimizing it (that litteraly give me the idea of just quitting this project) and I’m making this changelog now because I think we might not finish this part of the CLI before at least 2 days.

In the meantime, I daydreamed about many things I want to introduce into the project that will hopefully make a difference with others apps, even if I don’t have the same speed as them.

Made a command to explain how Fleer relays, encryption and decryption work - always with a nice focus on terminal design, with colors, responsive and auto resize

We can send files using the CLI!

I have some optimizations to make because sending small files is just as slow as sending large files, causing super low speed upload 💀

We also display the URL, command, and keys (used by the server) to connect as a receiver and start downloading files.

The protocol is kinda complex and I’m planning to write a documentation on how to use it for any matter (like automations or 3rd party clients), and a terminal generally being for nerds (especially when a desktop GUI app is planned) make this the best place to showcase how the relay system really work, so I implemented a flag --debug-performances that log every actions into a file, also useful to debug performances (if you didn’t guessed…).

The sender sends files to the relay, one by one, chunk by chunk to the relay, which will pipe them to the receiver afterwards. Chunks are fully encrypted on both clients and server cannot access their content whatsoever. To ensure even better security, I also display a warning with confirmation before continuing if the server is using HTTP instead of HTTPS.

There is many things happening that isn’t easy to see, and many little details (like some responsive resizing for low sized terminals) that many people may never encounteer, and I’m proud of how those devlogs are only like 7h long??

Anyway, here’s a video of where I currently am, and thanks for reading all of that garbage nonsense written by a french guy that isn’t quite good at telling things in foreign languages.

Spent a few hours starting the CLI!
For now it can only search for files and directory to send, while excluding socket and symlinks, and asking user if he want to excludes some others directory (like node_modules, cache or trashed files on macOS/Linux).

Interface use colors, spinners and terminal screen width detection to avoid overflowing texts on another lines, providing a nice display when displaying large quantity of text, even if it’s only on screen for a few milliseconds.

The files searching is really fast thank to Bun and some optimizations I did, here is a demo.

Receiver can now receive chunks of data even if he wasn’t connected when the sender started sending them.
Also, some communications are added between the receiver and the sender, such as a warning when the other one disconnect, or any other form of encrypted message.
Senders were informed when they reached the max cached data limit, but are also now informed when this limit can be ignored (when the receiver download those cached data to free some space).

And the thing you can see in the demo video: it is now possible to, as the receiver, restart an entire transfer if you connect to the download, disconnect, and reconnect again (because cached data are cleaned by the backend, which mean the sender has to send them again).

I know “sender” and “receiver” are repeated 300x but idk how to explain this in a better way 😭🙏 (+ i’m french idk we’re all bad in this language tbh)

After starting to get some progress on a test CLI (with both sending and receiving sides), we can now encrypt/send, and decrypt/download chunks on storage.

I will make a few changes on how files saving will be handled because for now the receiver only get chunks data, and don’t know how to reassemble them.

If you want, one of my git commit got this long ahh description:

- Many more checks
- Receiver can set their name (sender get notified)
- Chunks are sent to receiver - receiver can acknowledge when they receive one, and chunks sending is paused if they have at least three chunks not ack.
- An encryption protocol indicator is exchanged (not encrypted) to let clients know what encryption parameters to use
- Chunks that are in the memory of the server has a maximum, afterwards we stop accepting more
- Auto removal of all in-memory data of acknowledged chunks

Just started this new project! I’ve already wrote a loooong list of things I want to do (and how I want them to be done), will not post it here to avoid spoiling so wait a few changelog to know how the service will work!

For now, I’ve only implemented a basic API that allows to create a share, returning a shareId that allows to request details about it ; I also started the implementation of a socket that will allow someone to download a file while it’s being uploaded.

The backend will be done in Dart to allow the build of a light executable file, allowing an easier self-hosting while consuming less ressources.

This language also enable me the possibility of including the server directly inside a Flutter made client, but I’m not sure I will use this possibility, I guess we will see!