RVS_ParseXMLDuration VS trystero

Well, these ones aren't "half-baked," but they are no longer being maintained (archived):

[0] https://github.com/RiftValleySoftware/RVS_IPAddress

[1] https://github.com/RiftValleySoftware/RVS_ParseXMLDuration

[2] https://github.com/RiftValleySoftware/RVS_ONVIF

This project is unfinished (I just walked away from it, as it wasn't really giving me what I wanted):

[3] https://github.com/RiftValleySoftware/RVS_GTDriver

This one is "half-baked," I believe. I never really took it particularly far:

[4] https://github.com/RiftValleySoftware/RVS_MediaServer

Not completely. The way that it works for me, is that I start work on a project, and, while building, I notice that some code that I'm working on is:

1) Pretty complex, and fairly insular; and/or

2) Possibly useful, elsewhere.

If that's the case, I will then stop work on the main project, and take some time to extract and "genericize" the subproject. I'll usually set it up as a standalone open-source project; complete with tests and documentation.

This may happen before I have completed the coding in the main project, or may happen as the result of a review, after the fact.

In some cases, I very clearly need to develop a subproject before starting on the main project, or before certain milestones within that project (for example, SDKs or drivers). In that case, the timelines are completely separate.

If you look at my GH repos, you'll see a whole bunch of these projects, including some rather strange ones, like an XML duration parser[0]. These are the types of projects that I extract.

In some cases, I end up not using the extracted project in my main project (happens to some of my UI widgets). In that case, even though I am not using it, I still have an excellent project for the future. Here's an example[1]. I have ended up not using the spinner in my own work, as it was too obtrusive a widget, but it's nice to have it available for future projects.

[0] https://github.com/RiftValleySoftware/RVS_ParseXMLDuration

[1] https://github.com/RiftValleySoftware/RVS_Spinner

This looks exciting and I'm pleased to see more and more frictionless ways of making p2p apps. I've been building a somewhat similar hobby project [1] that aims to connect peers in the browser by piggybacking on open protocols out on the net (BitTorrent, MQTT, Nostr, IPFS, etc).

This project seems to be using Hyperswarm which I've looked at for use as a peering medium but it seems like it's not supported in the browser. I'd love to implement it if that story changes since it's so easy to distribute apps on the web.

[1] https://github.com/dmotz/trystero/

I was going to mention WebRTC! It seems designed for video calling, but there are lots of cool use cases - I recently ran across https://github.com/dmotz/trystero , a dead simple WebRTC library for peer-to-peer multiplayer browser games.

I strongly endorse Trystero (https://github.com/dmotz/trystero) for enabling P2P communication in web apps. It’s open source and leverages public infrastructure for matchmaking.

My attempt to get more out of all my ebook highlights using on-device AI. Click the demo button to try it.

https://github.com/dmotz/trystero

Nice work! Any reason one might use this over https://github.com/dmotz/trystero, you think?

Yes, this is a major issue that I haven't found a real solution for. There seems to be a mixture of iOS Safari bugs and intentional design limitations at play, and I don't know if a fully P2P web app like Chitchatter is practical on that platform. There's an open issue to improve this in Trystero (the networking library that Chitchatter uses), but there may be a limit to how stable iOS will be with WebRTC apps. 😕

You can use Trystero (https://github.com/dmotz/trystero) to cut server costs to zero. That’s what I used to build https://chitchatter.im/, which supports P2P audio and video calls.

WebTorrent is obviously well suited for p2p file distribution, but using a minimal subset of the protocol also provides a nice hack for easily bootstrapping peer connections between web app users. Piggybacking on public mediums already designed to do peer exchange can let you rapidly prototype a WebRTC project without the hassle of running your own server anywhere.

I built a library that explores this idea: https://github.com/dmotz/trystero