whytheplatypus

I've been thinking through similar disenchantment with social networks and content distribution. Going back to simplicity with something like this is a great idea.

Also, nice use of "lo-fi"! Thinking of recent projects as lo-fi has really helped me keep to the simple path.

This project came out of some friends and I missing watching bad movies together. I'm of the mind that writing software takes practice. So it was a great chance to practice general p2p design and specific WebRTC implementation.

The basic idea is, one person can open a theater and share their screen or load a video file. Then anyone with the audience link can watch along with them.

I hope it lets some people enjoy some movies together!

I'd love any and all feedback / contributions to the code https://github.com/whytheplatypus/shareable.theater!

I have seen some odd behavior but I haven't had a chance to identify exactly what is causing the limitations. For example one h264 video played correctly on the projectionists browser but resulting stream had a slightly off aspect ratio. I've also seen audio get lost depending on encoding.

Thanks for taking a look!

This works by creating a p2p RTCPeerConnection between the host (or projectionist) and each member of the audience. So the p2p aspect is a hub and spoke model. The video is captured either from a local video element if you're sharing a local file, or from some part of the projectionist's screen using `getDisplayMedia`, then streamed over that connection. There is a server that's responsible for the signaling required to create those p2p connections, but it's responsibilities end there.

The only requirements are a reasonably new browser and something you want to watch. I suspect that you're right about bandwidth requirements, however I haven't done the experiments to prove it. In terms of latency I haven't noticed anything significant, but I'm sure that's dependent on the bandwidth of the two parties.

If you're at all interested and willing to help improve the README or any part of the project, a pull request would be very welcome!

yes!

Couldn't agree with this more.

A current favorite of mine is "The Emperor's old cloths", the Turing award lecture given by C.A.R Hoare. In particular his line "The price of reliability is the pursuit of the utmost simplicity", it applies equally to maintainability and extensibility (I think these are part of what it means for a system to be reliable).

An idea I try to keep in mind while working is not to plan or build for future features but simply leave room for them (meaning don't actively prevent their eventual existence through complexity). It has taken some practice, but it helps guide to a simpler implementation.

very very fair.

mDNS is just the method of communicating what traffic should be sent where. The "switchboard" listens for mDNS broadcasts that tell it what services want traffic routed to them under what conditions. A "node" (which was a bad choice of words) is the other side of that, a program broadcasting one of those mDNS resources (e.g. send traffic that's been sent to the domain "example.test" to this machine on port 8080)

It makes my morning that this might be useful to someone aside from myself. I went down a similar path trying to find something mindless to route traffic to small projects I tend to run on raspberry pi's around the house, which resulted in this being made.

I really appreciate the response!

I've added TensorflowJS and MagentaJS to my reading list.

I'll pick out a couple of things implied in your comment, if I'm interpreting them right:

- An API should feel natural, and human-readable - A codebase should have a flow or consistency through it, in naming and structure.

I couldn't agree more about the comments, it seems like the most useful comments are those that supplement a piece of code with references or context rather than reiterate the code itself.

I've been enjoying "The Elements of Programming Style" by Kernighan and Plauger. Don't get put off by the references to Fortran, what they say applies to any language.

"Structure and Interpretation of Computer Programs" by Harold Abelson, Gerald Jay Sussman, Julie Sussman is another standard.

Martin Fowler and Robert C. Martin are both prolific.

Coding takes practice, so once you've got some ideas on what you want you want your coding to look like add them to your practice and see how it goes.

"write clearly -- don't sacrifice clarity for 'efficiency'"

"make it clear before you make it faster"

"make it right before you make it faster"

"keep it simple to make it faster"

From "The Elements of Programming Style" by Kernighan and Plauger

Other than that maybe that naming is one of the hardest and most important things to do.