Running a community project means collecting files from people you trust but cannot physically hand a USB drive to. The cleanest solution is a single upload inbox: you send one link, contributors drop their files, and you download everything without chasing anyone. Here is how to set that up with ShareIt.onl, plus the rules you need to enforce so the inbox does not become a mess.
Why a Dedicated Upload Inbox Beats Email and Chat
Email clients strip file extensions, reject archives over 25 MB, and make it nearly impossible to keep submissions organized. Chat apps are better for conversation than file collection—messages scroll away, and someone always uploads the wrong version. A dedicated upload inbox gives you a single destination, a clear expiry, and a download workflow that does not require the contributor to sign up for anything. ShareIt.onl calls this feature Request Files, and it is built for exactly this scenario.
Setting Up Your ShareIt.onl Request Files Inbox
Go to ShareIt Online Request Files and sign in with a Google account. This is the only step that requires an account—your contributors will not need one.
Once signed in, create an inbox link that lasts 7 or 30 days. Choose the period that gives contributors enough time, and state the submission deadline in the message that accompanies the link.
Share the link wherever your contributors are: Discord, a forum thread, a pinned message in your group chat. Anyone who clicks it sees a clean upload page. They can send up to 100 files totaling 3 GB in one delivery. If a contributor has more than that, they need to send multiple deliveries.
What Contributors Need to Know
Your contributors are not mind readers. Send them these instructions with the link:
- Allowed file types. Be explicit. If you need
.pngand.txtonly, say so. If you accept.ziparchives, say that too. - File naming. This is where most inboxes fall apart. Tell them to use a consistent format, for example:
username_screenshot_level3.pngortranslation_DE_v2.json. Without a convention, you will getscreenshot(1).pngandfinal_final_v3.zipand you will spend an hour renaming. - One delivery per person. If someone sends files in multiple deliveries, you have to track which is which. Ask them to bundle everything into one upload.
- No malware. This should be obvious, but remind them that you will scan everything before opening. More on that below.
Regardless of the transfer service, independently scan untrusted submissions before opening them.
Malware Checks: Your Responsibility
You are the gatekeeper. Every file that lands in your inbox should be treated as untrusted until you verify it.
- Scan archives before extracting. Use a tool like VirusTotal or a local antivirus with archive scanning enabled.
- Check file extensions. A file named
screenshot.png.exeis not a screenshot. Reject it and ask the contributor to resend the correct file. - Open in a sandbox if possible. For executable files or scripts, run them in a virtual machine or a disposable environment.
- Trust your community, verify their files. Even well-meaning contributors can accidentally include a macro-laden document or a file renamed from a suspicious source.
If you receive something that looks wrong, delete it and message the contributor privately. Do not assume malice—sometimes people grab the wrong file from their desktop.
Copyright Permission: Cover Yourself
Community projects often involve fan art, translations of copyrighted games, or screenshots of proprietary software. You need a clear policy.
- Require contributors to confirm they own the content or have permission to share it. A simple checkbox or a line in your instructions works: “By uploading, you confirm that you have the rights to share this file and that it does not violate any third-party copyright.”
- Do not host obviously infringing material. If someone uploads a full game ROM or a cracked executable, delete it immediately and remove that contributor from the project.
- Keep a record. Save the inbox delivery confirmation emails or screenshots of the upload page. If a copyright claim ever arises, you want to show that you required contributors to assert ownership.
Closing the Inbox and Downloading Files
When the deadline hits, the inbox link stops accepting new uploads automatically based on the expiry you set. You do not need to manually disable anything.
Download all files to your local machine. ShareIt.onl keeps received files for 7 days, and each time you download a file, that file’s retention extends by another 24 hours. If you need more time, download everything within the first few days and re-upload to your own storage.
After downloading and verifying everything, retain only the copies your project needs and remove unnecessary copies from storage you control. Do not rely on the request inbox as your permanent archive.
Common Mistakes and How to Avoid Them
- Setting the expiry too short. A 7-day link that you send on a Friday might expire before weekend contributors see it. Send the link at the start of a week and give a clear deadline.
- Not specifying file naming. You will get chaos. Enforce a naming convention from the first message.
- Forgetting to scan. One infected file can compromise your entire project. Scan everything.
- Assuming contributors read instructions. Repeat the key rules in your announcement and reminder. Be prepared to follow up individually.
When ShareIt.onl Is Not the Right Fit
Request Files works well for a few dozen contributors sending moderate-sized files. If your project involves hundreds of people or files larger than 3 GB per delivery, you need a different approach. For sensitive assets like unreleased game builds or personal data, consider end-to-end encrypted options such as Proton Drive or Wormhole. For local events where everyone is on the same Wi-Fi, LocalSend is faster and requires no internet.
But for a straightforward community file collection with no account burden on contributors, ShareIt.onl’s Request Files is hard to beat. One link, clear rules, and you are done.
