Background
AltSendme provides peer-to-peer file transfers using Iroh, QUIC, and a Rust backend. Functionality is solid, but there is still room to make the app itself faster and lighter, especially around file handling, UI, and resource use.
This is an open-ended optimization issue. Pick an area that looks slow or wasteful, make a focused improvement, and open a PR. You do not need to audit the whole stack or cover every item below.
Note: Transfers, and the events that fire during transfers, can behave differently depending on the network (local LAN vs. internet, fast vs. slow, stable vs. flaky). Keep that in mind when investigating and testing; a fix that helps on one network may not show the same effect on another.
Areas you might improve
Pick one (or a small related set). No need to check everything off.
Core file sharing flow
- File discovery and indexing
- File/folder metadata generation
- Upload/download throughput (app-side bottlenecks)
- Resumable transfer handling (app integration)
- Memory use during large transfers
- CPU use during transfers
- Concurrent transfer performance
Networking (app integration only)
- Peer discovery latency
- Connection establishment time
- Behavior on high-latency, unstable, or low-bandwidth networks
Application performance
- Startup time
- UI responsiveness during transfers
- Large folder handling
- Resource consumption (CPU, RAM, disk I/O)
- Background task efficiency
Platform-specific
What makes a good PR
Observable improvement is enough. If users or developers can clearly see or feel the difference (faster file loading, snappier UI, max CPU uti, etc.), that counts.
Profiling and benchmarks are welcome but optional. Use them when they help you find or prove a fix, not as a gate for every change.
Solving the problem matters more than how you solve it. Use whatever approach works, including AI tools when helpful, but you are still responsible for the result.
Testing before you open a PR is mandatory. Verify your change works in real conditions, not only on your own machine. At minimum, test across different network setups; ideally, test with a friend on a slower or different network and confirm transfers and transfer-related events behave as expected.
When you can, include in the PR:
- What felt slow or wasteful: brief description of the problem
- What you changed: and why you think it helps
- How you verified it: manual testing, timing notes, profiler output, or before/after numbers (whatever fits the change)
- Short notes for others: a sentence or two in the PR is fine; a longer write-up only if useful
Ideas to explore
- Inefficient async / task patterns
- Unnecessary file system operations
- Excessive allocations
- Disk I/O patterns
- Parallelism in app-layer code
- UI update frequency during active transfers
Success criteria
- Noticeable or measurable improvement in the area you touched
- No regressions in reliability or correctness
- Tested across real network conditions (not just localhost or a single fast LAN)
- Focused PRs; link this issue when relevant
Nice to have (not required)
- Benchmarks for critical paths
- Profiling notes in the contributor guide
- Baselines for future releases
How to contribute
- Optional: Comment here with what you plan to work on (helps avoid duplicate effort).
- Make a focused change in AltSendme code.
- Test thoroughly, including with someone on a different or slower network when the change touches transfers or transfer events.
- Open a PR linked to this issue with a short summary of the improvement and how you tested it.
Questions? Comment here or ask on Discord.
Background
AltSendme provides peer-to-peer file transfers using Iroh, QUIC, and a Rust backend. Functionality is solid, but there is still room to make the app itself faster and lighter, especially around file handling, UI, and resource use.
This is an open-ended optimization issue. Pick an area that looks slow or wasteful, make a focused improvement, and open a PR. You do not need to audit the whole stack or cover every item below.
Areas you might improve
Pick one (or a small related set). No need to check everything off.
Core file sharing flow
Networking (app integration only)
Application performance
Platform-specific
What makes a good PR
Observable improvement is enough. If users or developers can clearly see or feel the difference (faster file loading, snappier UI, max CPU uti, etc.), that counts.
Profiling and benchmarks are welcome but optional. Use them when they help you find or prove a fix, not as a gate for every change.
Solving the problem matters more than how you solve it. Use whatever approach works, including AI tools when helpful, but you are still responsible for the result.
Testing before you open a PR is mandatory. Verify your change works in real conditions, not only on your own machine. At minimum, test across different network setups; ideally, test with a friend on a slower or different network and confirm transfers and transfer-related events behave as expected.
When you can, include in the PR:
Ideas to explore
Success criteria
Nice to have (not required)
How to contribute
Questions? Comment here or ask on Discord.