Possible to use offline in local LAN?

[bt]

Hi, thanks for building and maintaining Chitchatter. I just came across this repo as I'm looking for a local/offline P2P chatting solution.

I'm trying to self host this on a completely air-gapped, offline LAN; and then allowing two (or more) users to chat with each other. However, I can't seem to get them to connect as it attempts to connect to an external TURN server and/or public torrent trackers.

If I was to host a local TURN server, would this suffice to allow the connection? Or, is there another way I can get the connection made between the peers?

[jsherman256]

I'd be interested in this use case as well

[jeremyckahn]

Hi all, thanks for raising this question. I don't see how Chitchatter would work in an air-gapped, offline environment by default. However, I imagine it would work if self-hosted with a bit of custom configuration. Specifically, you'd need to self-host both Chitchatter and a WebTorrent tracker. From there you'd need to configure your Chitchatter instance to use your self-hosted tracker.¹ I don't think you'd need a TURN server at all since everyone would be on the same local network (though that may depend on local network configuration).

It's my understanding that WebRTC (Chitchatter's underlying browser-level networking stack) can work in a LAN environment. Either way you'd need a signaling server, which is effectively what the Webtorrent tracker accomplishes. I think the real question here is whether Trystero supports LAN connections, since that's the WebRTC library that Chitchatter uses for networking. I think the answer for that would be much the same as what I've described here, but if this winds up being more involved we may want to raise the question in that project's issue tracker.

I haven't tried any of this myself so it's all pretty theoretical, but I bet it could be made to work one way or another just by playing with the configuration and setup. If you give this a try, let me know what you learn!

Footnotes

1. See https://github.com/jeremyckahn/chitchatter/blob/ed517e7a491e4a85d6c26e130bdb54999f2c27f4/.env#L81 and https://github.com/jeremyckahn/chitchatter/blob/ed517e7a491e4a85d6c26e130bdb54999f2c27f4/src/config/trackerUrls.ts ↩

[bt]

Hey @jeremyckahn - thank you so much for sharing this information!

I'm going to be setting this up soon, will keep you guys posted!

[bt]

Somewhat good news - I managed to get an offline setup working with the self-hosting steps and deploying Mosquitto MQTT locally. I had to change some of the code to use MQTT rather than WebTorrent/trackers as I have very limited compute in the airgap environment to play with.

Video, voice and messaging seem to work well. However, I cannot get image/file sharing working. On the sending side, the photo (image) displays perfectly fine, but on the receiving side, I just get an endless spinner. Do I need to deploy something else for file sharing?

[jsherman256]

Somewhat good news - I managed to get an offline setup working with the self-hosting steps and deploying Mosquitto MQTT locally. I had to change some of the code to use MQTT rather than WebTorrent/trackers as I have very limited compute in the airgap environment to play with.

Video, voice and messaging seem to work well. However, I cannot get image/file sharing working. On the sending side, the photo (image) displays perfectly fine, but on the receiving side, I just get an endless spinner. Do I need to deploy something else for file sharing?

That's awesome! Would you mind sharing the diff for getting MQTT to work, as well as your general deployment approach?

[jeremyckahn]

That's great to hear @bt! I'm glad it's at least working somewhat for you.

I cannot get image/file sharing working. On the sending side, the photo (image) displays perfectly fine, but on the receiving side, I just get an endless spinner. Do I need to deploy something else for file sharing?

This is because file sharing uses an inherently WebTorrent-based networking strategy that your deployment would need to account for. Data transmission for file sharing is handled by https://jeremyckahn.github.io/secure-file-transfer/, a package I extracted out of Chitchatter a while ago. secure-file-transfer is largely a convenience layer over https://github.com/webtorrent/webtorrent and a few other supporting libraries. I went with this strategy because WebTorrent seemed to be the best solution for streaming file data, thus allowing arbitrary file sizes. A simpler approach leveraging the preexisting RTCDataChannel connection via Trystero would have limited file sizes to available system memory (because they would first need to be loaded into memory before sending). In any case, Chitchatter's file transfer functionality requires a WebTorrent tracker.

For your deployment, I see two paths forward:

1. Stick with WebTorrent for networking rather than switching to MQTT
2. Modify Chitchatter to transfer files with Trystero (and accept the file size limitation)

Option 2 would be a nontrivial code change, so I'd suggest pursuing it only if option 1 is truly infeasible.

I had to change some of the code to use MQTT rather than WebTorrent/trackers as I have very limited compute in the airgap environment to play with.

I would be surprised to learn that MQTT is meaningfully lighter-weight than a WebTorrent tracker. For context, I use a local WebTorrent tracker when working on Chitchatter because I don't want to depend on the internet when developing. The local tracker has never struck me as particularly resource-intensive, though admittedly I use a reasonably powerful laptop for development.

What have you found to indicate that WebTorrent's performance is insufficient in your deployment? I'm just wondering if that is indeed a nonstarter, because it seems like the path of least resistance for solving this.

[jeremyckahn]

@bt @jsherman256 FYI I moved this to a discussion thread from #538.

[jeremyckahn]

I explored a solution for this in via an agent in #542. It's not quite working but I think it might be most of the way there. It may be useful as a reference for a real implementation, or it may not.

One challenge that this doesn't address is that inline media previews (like rendering an uploaded image) inherently depend on WebTorrent. That functionality would need to be either completely reimplemented or disabled for a WebTorrent-less deployment.

I don't have time to take this further for now, so hopefully you @bt or anyone else interested can carry it the rest of the way. If you do, let me know how it goes!

[jsherman256]

@bt I'm wondering if there are any WebTorrent servers that are lightweight enough to run on your target device. @jeremyckahn would ChitChatter work with any torrent tracker, or are there nuances to WebTorrent specifically that it relies on?

[jeremyckahn]

would ChitChatter work with any torrent tracker

As far as I know, no. WebTorrent uses WebSockets for communication, whereas traditional Bittorrent trackers use TCP and UDP, transports that browsers (and therefore web apps) don't support.

This is my understanding, anyways. Someone with deeper knowledge of Bittorrent/WebTorrent internals may have more insight here.

EDIT: I just found this: https://github.com/greatest-ape/aquatic/tree/master/crates/ws

I can't vouch for it, but it may be worth a look.

[bt]

Hey both!

Thanks for entertaining my use-case!

@jeremyckahn is correct - it needs to specifically be a WebTorrent tracker and not just any BitTorrent tracker; I found out the hard way by deploying an instance of OpenTracker, which does have a MIPS build, but WebSocket wouldn't connect 🤣

Thanks also for sharing that link - I had a quick look and it looks like Rust. I mentioned in a previous message that Rust doesn't have a MIPS toolchain, but thank you for trying!

I'm honestly on the edge of whether I want to just dump this crazy idea and get a inexpensive Raspberry Pi for my use-case 😄

[jeremyckahn]

Ah, I forgot about Rust/MIPS issue. My bad!

I'm honestly on the edge of whether I want to just dump this crazy idea and get a inexpensive Raspberry Pi for my use-case 😄

That would certainly simplify the software constraints, but I can appreciate that adding hardware would bring its own complexities. I think Chitchatter can do what you need with the hardware you have, it would just require some custom development related to file sharing.

I'll be curious to see which way you go with this. Let us know how it works out @bt!