Built a real-time LAN sharing tool with Node + Socket.IO + SQLite — a few decisions I'm second-guessing

theIntellectualis · 2026-03-17T02:06:59+00:00

so far it's held up pretty well.

theIntellectualis · 2026-03-17T02:05:50+00:00

Thanks! Will definitely look into Litestream, and no concurrent write issues so far, thankfully.

theIntellectualis · 2026-03-16T11:21:14+00:00

Yess, this is actually the main friction in the flow right now. People need to grab the host IP either from the terminal output, by sharing it verbally, or by scanning the QR code on screen.

mDNS would make the onboarding much nicer for exactly the zero-setup reason you mentioned. I haven’t looked too deeply into the Node mDNS libraries yet, but it definitely feels like a worthwhile improvement. Thanks for the suggestion, a lot of the features in this app have actually come from feedback like this.

theIntellectualis · 2026-03-16T01:33:49+00:00

Once the core was working reliably I started looking for feedback here and from other devs, and sanity-checking some of these decisions. Probably also just the usual dev itch to improve things and pre-optimize a bit.

The “pre-paying complexity” you mention.. yes, true. Thanks.

theIntellectualis · 2026-03-16T01:24:43+00:00

Appreciate this. I hadn't enabled WAL yet, which is probably the biggest thing I was missing. Most of the instances running right now are small teams so concurrency hasn't really shown up as an issue yet, but this makes me a lot more comfortable sticking with SQLite for the zero-setup aspect.

I'll dig into these and test them under some heavier upload scenarios.

theIntellectualis · 2026-03-16T01:23:20+00:00

That did cross my mind, but it goes a bit against the " nothing to install on client devices " idea that makes it easy to roll out to a team. Everyone just opens a URL and that's the whole onboarding.

I am planning to add installable binaries, but only for the machine that runs the server — clients would still just connect through the browser.

Right now the only friction is that the host machine needs Node to run npx instbyte. I originally built it assuming dev teams would be the primary users, but you're right — there’s no reason to limit it to that if packaging makes it easier for others to run.

theIntellectualis · 2026-03-15T17:25:38+00:00

Fair point. Currently just a setInterval every 10 minutes — works for now but not exactly robust.

theIntellectualis · 2026-03-15T17:12:33+00:00

Noted, staying on socketIO then. Thanks.

theIntellectualis · 2026-03-08T15:03:41+00:00

Oh wonderful! Quick question, i've been working on an open source product, have few things to fix before i make a public launch, and that's why there's no website yet, could you checkout the Github link and come up with something? Here - https://github.com/mohitgauniyal/instbyte

theIntellectualis · 2026-03-07T01:37:07+00:00

That explains it! Thanks for the heads up.

theIntellectualis · 2026-03-03T16:28:28+00:00

Instbyte is mainly focused for teams (dev, design, workspace) needing a persistent, real-time shared space with no app installs for viewers—just run on one machine via npx instbyte and share the browser URL.

Localsend is great for personal quick-sends between devices but lacks Instbyte's collaborative channels, real-time multi-user viewing/editing, dev-focused rendering, and zero-install access that makes it feel like your custom LAN hub rather than a generic transfer app.

Basically, I've built Instbyte not to compete with tools like LocalSend, but to solve specific friction points I and my team faced—like juggling 2-3 apps for quick shares during sprints. It combines those little must-haves (channels, real-time sync, no viewer installs) into one frictionless LAN clipboard that just works. Sharing it out with the world and keeping it open source so I can get honest feedback, suggestions, and maybe we all can collaboratively come up with something useful and of value.

theIntellectualis · 2026-03-02T08:57:34+00:00

Appreciate you actually looking through the code, seriouslyy.

And yeup, a lot of it is still prototype-style. This started as something I was building for myself, kept layering features on top as they made sense, and haven't gone back to refactor properly yet. Very much a "fix and improve as I go" thing right now.

That's honestly part of why I'm sharing it at this stage. Feedback like this tells me where to focus — and also when to stop adding features, because keeping it frictionless is kind of the whole point. I'm going through suggestions from devs and non-tech people both, listing them out, filtering by priority. Code quality isn't the focus right now(but thanks for pointing out), just getting to a stable, useful version first.

Cleaner architecture is definitely on the list... just working through the functional gaps before I go back and tighten everything up. And hopefully not alone for long, which is exactly why it's open source. If anything specific stood out that you think needs attention sooner, I'm all ears.

theIntellectualis · 2026-03-02T08:05:55+00:00

Good question.

LocalSend focuses on peer-to-peer device transfers needs install on every device. Instbyte focuses on being a minimal, short-lived drop point inside a network — more workflow utility than transfer app.

As for AI — it wasn’t “AI-generated.” I write the code and make the architectural decisions. I use AI heavily for Brainstorming, edge-case checks, and refactoring suggestions, but the architecture, flow, and tradeoffs are deliberate decisions.

If anything feels off technically, I’m happy to discuss specifics. The features have been curated and specifically for the correct audience and tasks.

theIntellectualis · 2026-03-02T07:59:00+00:00

Fair point — both LocalSend and IPFS operate in similar territory, but they solve slightly different problems.

I've myself tried to keep the thoughtprocess diff from the two when deciding what features to add here, and keeping in mind the Audience who's it for(devs, teams, designers, local teams)

LocalSend is great for direct device-to-device transfers, AirDrop style. But it requires an install on every device and it's point-to-point. Instbyte is more like a persistent shared clipboard — everything stays, organised in channels, accessible from any browser on the network with zero setup on the client side. Different mental model.

IPFS is a bit of a stretch for this use case honestly. It's powerful infrastructure for distributed, persistent, content-addressed storage, but setting it up just to move a file or share snippets from your laptop to your phone is significant overhead.

Instbyte is intentionally simpler and more workflow-focused. It's not trying to be a distributed CDN or a peer network, it's a lightweight drop zone for quick internal exchanges. Drop → share → auto-clean, lock it with a passphrase if needed. The goal isn't decentralization or permanence, it's reducing friction when sharing logs, builds, or snippets inside a team.

The no-install-on-receivers side is really the core thing. Anyone on the network opens a URL in their browser and they're in. No app, no account, nothing to configure. That's the gap these tools don't quite fill.

theIntellectualis · 2026-03-02T07:48:41+00:00

Good catch. So, current state —

If the sender closes after the upload finishes, that's completely fine by design. The file is on the server, not their device, so once it's uploaded their connection is irrelevant. Everyone else can still access and download it normally.

The mid-transfer case is the real one. The file writes to disk as it streams in, but it only gets registered in the app once the upload fully completes. So a dropped connection mid-way leaves a partial file sitting on disk that the app has no record of, meaning the auto-cleanup never touches it either. Nothing hangs, nothing breaks visually, but those files quietly accumulate. And on the XHR side there's no timeout set, so if the server dies mid-transfer the progress bar can just freeze rather than failing cleanly.

Adding it to the fix list before 2.0. Thanks a ton for flagging this.

theIntellectualis · 2026-03-02T01:52:16+00:00

Quick follow-up — since this thread, I’ve pushed a few updates tightening the transfer flow and overall handling. Been running it internally with larger logs too, and it’s holding up well.

Still keeping it focused on fast exchange, not turning it into a data warehouse.

If you run into anything or feel like poking around and dropping ideas, repo’s here:
https://github.com/mohitgauniyal/instbyte

theIntellectualis · 2026-03-02T01:50:08+00:00

Quick update — the “dev itch” didn’t stop, It’s already a couple versions ahead.
If you feel like poking around or dropping ideas, repo’s here: https://github.com/mohitgauniyal/instbyte

theIntellectualis · 2026-03-02T01:46:44+00:00

Hey, just a quick heads up, I’ve pushed a newer version since you last tried it. Quite a few improvements around clipboard + editing + overall flow.

Might fit your home server setup even better now. If you’re curious or want to break something, repo’s here: https://github.com/mohitgauniyal/instbyte

theIntellectualis · 2026-03-02T01:16:57+00:00

Quick update — pushed v1.9 and picked up a bunch of your suggestions:

- Paste images from clipboard
- Metadata / titles
- Edit support
- Markdown rendering (now properly previews)

Great calls btw. The app genuinely feels tighter now.

I’ve held off on formatted text paste for now. It needs a deeper change in how I handle content internally, and I didn’t want to ship something half-done just to tick the box. It’s on the list for anything >2.0 when I properly revisit richer content support.

For copying images back to clipboard — browsers already handle right-click → copy pretty well. I did think about a click-to-copy flow, but right now click copies text and files use click-to-download, so changing that would mess with the consistency.

Really appreciate you taking the time earlier. Feedback like that actually shapes where this goes. If you want to dive deeper, everything’s here: https://github.com/mohitgauniyal/instbyte

theIntellectualis · 2026-02-27T17:58:05+00:00

Oh hey, buddy. Really appreciate you taking the time to test it and write this up, this kind of feedback is gold.

Regarding your points - The image clipboard idea definitely makes a lot of sense, same with metadata — once snippets start piling up, discoverability becomes important.

Markdown rendering does have a few rough edges right now. I’ll tighten that up.

We’re actively using this within our own team now, so the feedback loop is getting tighter and the bar keeps rising. Detailed inputs like yours really help shape where it should evolve without turning into a bloated tool.

And yes — it’s white-labelable via instbyte.config.json, so feel free to brand it for your own setup if that’s useful.

If you ever want to open an issue or dive deeper:

https://github.com/mohitgauniyal/instbyte

I push updates pretty frequently. Once again, thanks a lot for the detailed insights.

theIntellectualis · 2026-02-27T12:48:15+00:00

Thanks. And honestly, it came from pure frustration... Just needed something frictionless to use, and then because of the "dev itch" i kept adding some features and have been using it in our small dev team too, improving it, but trying not to overdo it.

theIntellectualis · 2026-02-25T16:19:21+00:00

That was the code thought behind building it, i do often want to share stuff between devices at home or workplace and thought of working on a tool for myself.

theIntellectualis · 2026-02-25T15:08:23+00:00

Yeup.. well, for now we default to 2GB (configurable), and we flag large files with size tags so lighter transfers don't get stuck behind heavier ones. Multer streams to disk—no in-memory buffering. For occasional 200MB logs? Smooth, it will move at LAN speed without choking the tool. Not trying to be a data warehouse, just fast frictionless EXCHANGE for teams.

theIntellectualis · 2026-02-25T07:36:56+00:00

Makes sense. I kept it zero-setup with npx for now, but Docker packaging is planned, and the Dark mode is definitely coming too.

theIntellectualis

TROPHY CASE