In my last post, I wrote about how REST architectural principles feed into the problem with surveillance capitalism that the world faces today. Today, I want to explore how we might approach an architecture for a better, more human centric internet. Figure: “architecture 2” by fontplaydotcom is licensed under CC BY 2.0 Internet or Web? First, some quick disambiguation. The Interpeer Project’s aim is to provide infrastructure for a next generation human centric internet – so why focus on REST, when that is specific to the web?

Just as my previous FOSDEM talk, my presentation at FOSSASIA was titled “Designing a Human Centric Next Generation Internet”. Trying to learn from the previous presentation – and having less time, and adding the pressure of a live event – I tried to focus more on a future internet architecture. The benefit of that approach is that it can be done as an analysis of the web’s more-or-less-achieved REST architecture and it’s successes and failures.

Remember the early 90’s and Salt-n-Pepa? No? Well, it’s about breaking taboos around talking about important topics. In a vaguely comparable way, we software engineers have a kind of taboo on talking about REST. Let’s break that. Figure: “Rest here” by oliverkendal is licensed under CC BY 2.0 See, most of you will know what REST means, right? And the majority of my readers will be able to tell me that it stands for REpresentational State Transfer.

OK, so in the last post, I was getting into some channel capability flags, and how they impact handling of lost packets. The main conclusion for the purposes of that post was that we need some kind of sequence numbering in every packet, unless we just so happen to switch all reliability flags off. Saving bits is a noble goal to be sure, especially when you have WiFi induced low MTU on the path.