Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
PJON – Padded Jittering Operative Network (pjon.org)
32 points by oedmarap on March 22, 2020 | hide | past | favorite | 7 comments


Hmm, I don't get it.

Looks like a way to build your own networks with whatever physical layer you want with a goal of avoiding 3rd parties that may monitor traffic.

But what problem is it actually solving? If you can make your own devices and setup your own physical network, this doesn't seem like it adds value over existing approaches, like using encrypted network tunnels.

The video shows someone in a far future, automated house who watches a rocket put a satellite into space. Huh?

The homepage could probably use some work.


For me, this page helped it click: https://github.com/gioblu/PJON/blob/master/specification/PJO...

If you are an engineer looking to connect devices you built together, this is a cool protocol to consider.

Some examples of projects people have built would be helpful to showcase and help show which problems this solves.


It doesn't really have enough throughput to be an alternative to things like ethernet or wifi. It's intended for hooking low-powered embedded devices together, think of it as an alternative to i2c or canbus, not ethernet.


I think the idea is that it is a successor to other networking protocols, without "baggage" and various (in the author's opinion) other missteps that make our existing networking stack a bit bloated / inefficient.


CANBUS is an example of that.


Again, I wish that every project would have a single "explain like I'm 5" sentence description to say what it does. For this project, I might say, "An improved networking protocol for bus based devices, similar to i2c or spi, but with wide support for several physical mediums." Would I be correct?


For people wondering what this is useful for: I've been using this as a protocol for a project connecting a Raspberry Pi to a microcontroller project. Currently I'm prototyping using the serial transport, but at some point I will likely switch to using I2C to accommodate a more minimal interface between the two and allow for more devices to be connected to the RPi. This makes it so that I can swap out out with minimal changes to the code on both sides and keep a standard protocol in place. Also the libraries are pretty easily to use, so it's a little nicer to work with than rolling my own serial framing protocol.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: