question: project status

[o-su]

Hi,

thanks for your amazing work on trystero. I am trying to build a project that will synchronize data of one or few users on multiple devices. I've played around with webRTC, but I've always been put off by the need to run servers that kind of defeat the idea of p2p communication.

I tried syncing across multiple devices today and it works perfectly. Is this project production ready?

I would like to create a few PRs if it is okay with you:

• there are no tests, but at least some utils functions can be easily tested
• project has d.ts files but is written in JavaScript. Do you mind if I rewrite project to TypeScript?
• current version works only on local network. I think it can be fixed by adding STUN servers. There are free public STUN servers which can be used in default configuration same way as you added default torrent trackers.

[jeremyckahn]

Is this project production ready?

I'm not the developer of Trystero, but in my experience Trystero is ready for production use. I currently use it in https://chitchatter.im/ and https://www.farmhand.life/. I have reliability issues with peers connecting, but that's because I rely on free, publicly-available WebTorrent and TURN servers. I expect that if I actually invested in proper infrastructure for my projects, these reliability issues would largely disappear.

current version works only on local network. I think it can be fixed by adding STUN servers. There are free public STUN servers which can be used in default configuration same way as you added default torrent trackers.

From what I've learned, the issue isn't STUN servers so much as it's TURN servers. @dmotz would probably know more than me on this, but it seems that Trystero largely obviates the need for STUN servers. TURN servers relay data when P2P connections can't be made, and that happens frequently in my experience. Unfortunately TURN servers are much more expensive to host than STUN servers as they are CPU and bandwidth-intensive applications. As far as I know, there aren't a lot of great free solutions available to meet this need.

[dmotz]

@o-su Thanks for bringing this up. I have lots of plans to continue to improve Trystero, but my time is of course divided with other obligations. I would absolutely welcome more contribution from the community and I think proper tests is a long overdue place to start. Getting a test suite would enable us to more quickly improve Trystero with confidence.

If you're looking for a place to contribute, I think looking into writing Playwright (or Puppeteer) tests would be the highest impact for the project. Due to its multi-client nature, most of the test suite will need to be functional tests run on 2 or more headless browser instances (peers). Luckily tools like Playwright make this straightforward. Ideally the same suite testing all the library methods could be re-run for each different strategy (torrent, Firebase, etc). Is this something you're up for trying?

In regards to a TS rewrite I think the type def files suffice for now, but we can revisit this idea later.

Regarding the last point, if you're not able to connect peers outside of the local network then at least one of them has a firewall blocking p2p connections. Trystero already uses public STUN servers to do NAT traversal, but if there's a firewall blocking things you'll need to use a TURN server which relays all the traffic. As @jeremyckahn mentioned, public ones are harder to come by, but you can try something like Open Relay or running your own. You can pass the TURN (or different STUN servers) to Trystero in the rtcConfig field of the config object passed to joinRoom().

Let me know what you think about the proposal for tests.

[o-su]

I hoped I can use webRTC without TURN servers since TURN servers change whole p2p solution to cloud service. I dont want to handle user data at all. It is good enough solution for my project if it works on local network.

I am planning to experiment with local "server" node this week. My app is just PWA, but I can load this frontend-only app in electron and use it as server. It should stabilize my local p2p network since at least one device will be connected all the time.

@dmotz yes, that was exactly my thought. I would like to use Playwright with more instances..

[metaleap]

I currently use it in https://chitchatter.im/

Hiya @jeremyckahn I guess this issue isn't the place but I just went there to try it out and join your public room "technology / hacking". Spinner for finding peers kept spinning while devtools console kept spitting out "WebSocket connection to 'wss://fediverse.tv/tracker/socket' failed: Error during WebSocket handshake: Unexpected response code: 403". I'm with a very recent Chromium on Voidlinux. Maybe I have some browser setting turned off that shouldn't be, or some such... but you might wanna at least do a try / catch(err) somewhere and pop up a hint to the visitor (ie a setup-checklist link or such =)

[jeremyckahn]

Thanks for the feedback @metaleap! This is actually very relevant to Trystero so I'm glad you brought this up here.

Spinner for finding peers kept spinning while devtools console kept spitting out "WebSocket connection to 'wss://fediverse.tv/tracker/socket' failed: Error during WebSocket handshake: Unexpected response code: 403"

I experience this as well on Firefox and Chrome. The good news is that Trystero has tracker redundancy, so it gracefully falls back to an available tracker if one is unavailable for any reason. That said, wss://fediverse.tv/tracker/socket appears to be unavailable in every scenario I've tested, so @dmotz it may be worth removing that from the defaultTrackerUrls array: https://github.com/dmotz/trystero/blob/8999be2d24d1b08bab69502892ada10bdf805c34/src/torrent.js#L31-L38

you might wanna at least do a try / catch(err) somewhere

IMO this is appropriately logging an error (even if it's a little noisy), so I think this behavior should remain. Either way, this error is thrown within Trystero and not bubbled up to application code. So, it would need to be handled by Trystero. Here's where the error is thrown: https://github.com/dmotz/trystero/blob/8999be2d24d1b08bab69502892ada10bdf805c34/src/torrent.js#L202

But again, I think this is worth logging to the console. It could be worth catching and reporting with console.warn, though.

pop up a hint to the visitor (ie a setup-checklist link or such =)

Chitchatter does have some error handling to inform the user of detected issues and offer potential solutions (such as if no trackers can be reached or if there is no TURN server available). However, what you experienced appears to be a failure that was automatically recoverable, so you weren't shown such messaging.

[metaleap]

Ah my bad @jeremyckahn I keep seeing (from past trauma I guess =) all red console outputs automatically as uncaught exceptions. Didn't even occur to me it might be a deliberate console.error logging call. Yeah you're right, if it's autorecoverable on-a-long-enough-timeline, then that's just fair-nuff. I'll play again and keep that tab up for some hours, see what happens if anything =)

[dmotz]

It's worth noting that you can't catch WebSocket connection errors such that they don't appear in the console (see this answer for details). The nature of using public trackers is that they go in and out of service and we hopefully solve that with redundancy. Ideally this is all hidden from the end user. I have some ideas for much broader tracker redundancy that I'll try to implement soon.