Designing a human centric next generation internet
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Finkhaeuser, Jens
The Interpeer Project attempts to provide the technical underpinnings for a human centric next generation internet. As sensors and compute nodes are now (close to) ubiquitous, it follows that there is no longer a static or traceable relationship between ownership of a physical processing unit and the personal identifiable data it processes. A future internet architecture must take this into account, whilst respecting and protecting user's privacy and data protection concerns, also from a regulatory point of view. At the same time, sharing data in this proliferation of processing units also favours distributed approaches over the web's decentralised architecture. This session outlines the future the Interpeer Project envisions, and reports on achieved outcomes to date. The Web has was designed with sharing of textual information in mind, and has by now outgrown this purpose. In the academic context in which it was conceived, and considering the technical constraints of the time, it made sense to design a centralised protocol for up- and downloading documents to a server managed by an institution or company. The Web has long evolved away from this, and added authentication, authorization and encryption as natural afterthoughts to the original design. Nowadays, we share more than documents. Our concept of sharing has evolved (for better and worse) from only adding to the public domain to selectively trusting groups or individuals with specific pieces of information. While services built on web protocols can and have modelled this new concept, it remains difficult to do well. This and financial incentives combined push developers to instead adopt half measures, whereby a central instance - the webserver and its legal owners - act as intermediaries to the process, weakening the sharing model to commercial, state or criminal exploitation. There are excellent organisations fighting to amend legislations to close such loopholes. The Interpeer Project recognizes that aside from the legal struggles, the practical consideration remains that it is much simpler for developers to build centralised, vulnerable products than those safe by design. It aims at making safe data sharing applications as easy or easier to build by starting from the ground up, and embedding the security and synchronization concepts for a highly distributed network directly into a new and open protocol stack. Empowering users in the context of this project means enabling them to do everything they're currently used to and more, but safely and without the strict need for centralised infrastructure.
 Hi, welcome to my talk on designing human-centric next generation internet. Here's Boston in 2021. My name is Jens Schienkhoiser. Before I start, let me just tell you this. I started writing the slides for this talk and I thought, yeah, I don't actually have enough content to fill everything up and at the end, I had too much. So rather than take slides out again, what I'm going to do is I'm uploading the slides, but maybe I rushed through some of them a little bit. I think that's only fair. And the first thing that I will rush through a little bit is the introduction. Basically this slide just tells you I'm old. This slide has a little bit of content. I have experience in video streaming on the web through peer-to-peer networks, sorry, not on the web, on the internet through peer-to-peer networks. And that goes back as far as 2006 when I joined Juist. Ancient history, read up on it if you want. I'm going on. Ask forward a little bit. This talk is about the Insepia project. Why did I start this at all? After this experience with video streaming on peer-to-peer networks from a long time ago, I got in contact in early 2019 with a startup that wanted to do basically the same thing, but somehow involved with blockchain. And while that didn't work out, from my point of view, they were a little bit too invested in the blockchain side of things. And I guess I was too much invested in the peer-to-peer side of things. Part of ways, but that gave me the understanding that actually there is still need and also desire for peer-to-peer technologies in the world. And that meant I started looking for funding, which I found from an Aonet. Unfortunately, just after the grant was given or accepted, the challenge was accepted, the pandemic hit, and I didn't really work as much on it in the last year as I wanted to. And because of that, because of the lack of income that resulted from that, I also had to look for a part-time job. So I joined NUI Technologies. Now that's interesting in a way that I will get into later. Funding. The Insepia project is currently funded by an Aonet, which takes the funds from NGI Zero. It's the second-generation commission's next-generation internet initiative. An Aonet also collects donations. So if you ever have any money left over that you want to put into financing FOSS here in Europe, give it to an Aonet. They will try to put it towards the right projects. And also about NUI. NUI is involved in making smart routers, wireless routers. And then because of this, they got involved with two drone projects that are funded by Excel, the Excel joint undertaking, which in turn is half funded by Horizon 2020, or at least part, I don't know, a part, and part by the industry. So these are two projects that I'm active in that relate very closely to the Insepia project in some details. Why I'm doing work for NUI. And NUI has kindly let me publish some of these things in papers and there's more coming. So even though they don't actually fund the Insepia project, they do fund, in their own self-interest if you want, a very closely related work that's also making it to some degree into the public domain can be used by the Insepia project as a result. And that's a very nice arrangement to have. So if you're looking for a job that has to do with networking or embedded or drones, maybe NUI is the place for you. You would have to work with me though. Good morning. All right. So let's start with a bombshell. The web is dead. Yeah. I don't know if that's too small, but it has a small tagline that says actually it will stay on there for quite some time. I don't think I can, this is a section actually I want to skip over relatively fast because it will consume too much time otherwise. But it's very hard to understand why I'm so invested in doing something peer-to-peer when you assume that the web is in good health. So I'm running through a couple of quick points on what's actually really fundamentally contributing to the problems that we see on the web today in the web architecture. First of all, there's a timeline. You don't have to read everything here. Left is basically the development of the HTTP protocol. Right is development of sort of security and authentication technologies, roughly ordered. And I made red arrows there to sort of delineate the beginning, the middle, and the end of a mid-era of the web development. And there's a before and after, of course. So I've divided this, and you don't have to follow this, but I've divided this web history in like three big eras. The early web, the HTTP protocol was not massively specified. It got specified after a while, got a revision immediately after. And it helped establish HTTP as a decentralized protocol. Security at that time was not the highest issue. The focus pretty much was on publication, on publishing data that's already, that's meant to be public. So the idea was you run your own server, you upload documents to the server for the world to see. And that's great, but that's not how we use the web today. The.com bubble came, it burst. And then it sort of got restarted with Web 2.0. And one of the interesting parts of Web 2.0 is not that there were new technologies or something that's not actually necessarily the case. But that was an era where commercial entities tried to pull more and more users to the web. They realized that there was money to be made there, but they also realized that the model where everybody who had something to say would run their own web server and publish stuff on this web server, that model doesn't work. What you have to do is you have to take this technological challenge away from users in order to broaden adoption. So you see a lot of, in this area you see a lot of security features being added in form of TLS, new authentication methods, and also starting towards, I'll put this here, HTML5. I'll get to that a little bit later. And this era pretty much ended when containerization in the form of Docker basically came along. What happened there is that the scale of pulling all the users onto the web became too large to handle, or at least too large to handle by the conventional methods. So data center operators, Google, Amazon, all the big ones, started to look for ways to make handling this complexity easier. And so they came up with tools. I put Docker here. You could easily talk about OpenSec or Kubernetes. That's not really the point. The point is these are all technologies that help manage the complexity of scaling up the web. There's a feedback back loop here because it started out with consolidating users on a smaller number of services that led to a larger scale that leads to complexity. And now what happens is that with the adoption of these management technologies, you have even more consolidation because the easiest way to do stuff on the web now is by using the technologies that enable large scale. So we come back to the same problem again in a loop. The web protocol has issues. One of them I sort of outlined in the timeline skipped over it very quickly is that if you look at the timeline closely at every security feature that exists in the web stack has been added as an afterthought, whether it's encryption or authentication. And privacy has never been a topic because the assumption from the early web was that you would own your own web server. And if you own your own web server, then privacy is guaranteed, right? But that's no longer the case. What we can also see in these eras, if you look closely, I'll leave that up to you, is that really the developments after HTTP 1.1 and HTML4 give or take, the development of new web technologies has only been driven by commercial interests. Commercial interests really never involve them unless you assume that large corporate entities have the user's best interests at heart. And we now end it in a world where HTTP 2 and HTTP 3 is effectively designed by Google for Google scale data centers. It isn't really, there aren't really many necessary changes in there for the original model of the web where you would run your own web server. So it has to do with scale. But there's also fundamental issue that comes with the assumption that everybody runs their own web server. It's that HTTP is and isn't quite, I'll skip over the slide a little bit. Just once you understand that in HTTP everything is a resource and every resource has a unique URL. And all the HTTP methods basically operate on an entire resource. And it's completely fine when you have a document to upload, some text, 10 paragraphs, even three pages, it doesn't matter. You can upload a whole new document as a change to the existing one. The update mechanism is where things break and the partial retrieval is where things break. Partial retrieval is get with range header. I can read up on this. I'm not going to explain everything. The point is only that range headers are not really easy to support and therefore they're not very widely supported, especially not if you're doing something like running an HTTP proxy in behind that's an application server. It doesn't work particularly well. It can be major work, but it's hard work. On the update side, post and patch are defined in the specs to have a content, a request body that is specified by the server effectively. So the server implementer decides how to handle a particular media type in the request body. Really what these things mean, the update part in particular, is that it's very hard to make generic web clients. They have something like a browser that does something generic, but if you look at our, for example, an update patch method is being used, there is no generic implementation in the web browser for doing patch. What you have to do is you have to write a JavaScript that then does the patch method. The JavaScript, well, you deliver it with your web server. So you bundle both the implementation on the server side with the implementation on the client side in one go. A generic patch as such doesn't really exist. It really must lead to one thing, that the server owns the data, because really only the server implementation understands how to handle the data. There is no way for a generic client to do this. Historically we have a similar problem with HTML. Read through this briefly if you want, but the short story is that HTML5 has basically given up on standardization. Yes, there are standardizations, but it's a living standard, which means the standardization that changes all the time. What happens is that most of this changes driven by what WebKit supports. WebKit is owned by Google. It's open source. We can all use it, but you still have a very big influence of one company here on what actually happens on the client side. Now, when I mention this to people, one person responded, yeah, but React and TypeScript, they also have great influence on this. Maybe, maybe so. They're not making a browser engine, though. So for me, this is not the biggest issue here. And there's also a conceptual problem with HTML, because HTML mixes data and representation. So and also with JavaScript and processing. So it's not NBC at all. Now you don't have to believe in NBC, you can use MVVM or whatever. The point is by bundling the logic on how to manage data with the data and the backend that only can deal with whatever happens on the client side that it has sent to the client, you really are creating data silos. You're not building a web of data that can be processed elsewhere. The semantic web effort is trying to do this. It hasn't got very far as far. Well, there's a lot of development there, don't get me wrong, but most developers don't talk about the semantic web as the solution to their problems. In that sense, it hasn't really gone very far. I'm not trying to tell you here that people have way and working with this are not doing their stuff, but not the case, but the adoption is not so great. And yet, HTTP has strengths. This is why it got adopted. And I will highlight this briefly. It's simplicity, simplicity. It's very easy to get started with. The complexity arises later. And the complexity always leads to this issue of centralization that is pretty much inevitable in both the scale that we see nowadays and the HTML JavaScript combo that makes it impossible to do smart things like a patch method without this mechanism of also delivering some processing instructions to the client. So where do we go from there? Well, we can see some kind of trends here. This is a little bit, every slide is going to be a little bit different on a slightly different topic here for a second. This I found particularly interesting is only a couple of days old now. This is a response to Donald Trump being banned on Twitter and Facebook and whatever else. Basically we have with the centralization, we can buy the censorship. Now I certainly don't, I'm not impressed with Trump's track record, but I don't want to get politically, I just need to get that out here. But by having communications platforms centralized in large corporations, we effectively have come to the point now where corporations have the power to censor heads of state, irrespective of who they cut off. That's a very, very dangerous precedent and it's something that we have to be very careful about. Second, centralization has become the default for most developers, right? It's not something that people tend to challenge anymore. I got sent this, this is from Moxie Marlin's comment which looks like it's on GitHub. I got sent this with some kind of, it's old, right? It's four years old. I got sent this with some kind of highlight there that seems to say that he's happy with centralization. I don't think that's actually the case if you read the words carefully, but it certainly reads as if doing anything other than centralized approaches is too hard. And if this is coming from a very smart guy, I think we have a problem, right? He's got a track record, whatever else you think of him, he's got a track record of doing some very, very smart things. Now he's an inventor of signal and the protocol around it. And if he thinks that doing something like signal in decentralized or distributed fashion is too hard, well then our entire field has an issue, basically. Completely different from the technological and control angle, we also, sorry, the censorship angle, we also have defaulted to yielding control, right? This has even the nerdiest nerds with very few exceptions are happy with this, right? Most of us have a smartphone and very few of us run free operating systems on it because it's too much of hassle. And I sort of blame this trademark tagline there which is why I modified it. I think I fixed it actually, yeah? We're looking no longer at how to handle data, how to deal with the data that we have and give it to other people. We tend to look at the channels, right? Which channel allows us to do what? And I think that's a very broken way of looking at how a worldwide network of people, which is essentially what the internet is in the end, even if it's primarily computers. That is supposed to operate. Now, I want to get to this, let's get signed around everyone to know why the internet interprets censorship as damaging routes around it. I think this was the case when it was written in 93 where everything was very decentralized. And it's also important to highlight that the web and the internet is not the same thing, right? It tends to route around damage, whether it's censorship or something else. It tends to route around it because that's how the IP protocol is constructed. That's a good thing. But the web, by its very, by the nature of making it easiest to centralize stuff, is no longer routing around damage. In fact, it actually encourages exploitation and censorship. And that's why this quote is pretty important to put in there. That was my old man, yeah, that's a cloud section of the talk. Let's move on to something slightly better. But I wanted to go through this briefly so that you guys understand. I mean, I run into people who not long to every point here, and I don't have to explain myself pretty much. But then there are people that say, but it's good, but it's easy. But look at what it lets us do. And they're, of course, all right, no? The truth lies somewhere in the middle. The question is, how can we get the same benefits without these problems? That's what we're trying to solve here at the Interpreter Project. By the way, I just said we. That's what leads me. But since I'm working with colleagues at NEY to do something related, I'll get to that again. And I talk about this kind of problem with a lot of people when I can. It feels like there's more people contributing. Yeah, unfortunately, right now it's me. So the focus, in my opinion, should be collaboration. And in the title of this talk, I've spoken about human centricness. What I mean by human centric is that it should focus on people's needs, right? We should think of the Internet as something that serves people's needs. And really, what it comes down to is collaboration, which is why this deaf room is a good place for this talk. Because standalone computer without any Internet connection does serve my needs to write text or program or whatever, right? I don't need the Internet for that. But the moment I want to hear ideas or explore other people's ideas together, then we're talking about collaboration, really. So human centricness and collaboration, I would say it's almost the same thing, not quite, but almost. I want to look at the collaboration part first. I try to write down a list of mechanics, what mechanics exist to make collaboration happen. And the first one is communication. You can't communicate. You can't collaborate without talking about what you want to do, right? In fact, communication is already collaboration in itself in a way that you exchange ideas, you exchange thoughts, you even just touch base with people. That's already collaboration. The next step is that you want to share stuff. You want to give and receive things. And I put here digital assets because it's the Internet we're talking about. But really, in the offline world, it's like give somebody a cup of tea, right? That's giving stuff, that's sharing. I would like you to view this more as a trade. It doesn't even have to be something that is a mutual exchange, right? Where you give and receive something. But it shouldn't be thought of as sharing in the sense of social media, where you just take something that somebody else has written and broadcast it to your circles. You can do that as well. But sharing I'm talking about here is more the give and receive things. The other thing is sharing skills. Once you're working together on something, what you're actually doing is you're sharing your experience, your skills, your point of view, or it's a shared project. And that can be also commercial, so to speak, tell your services. Not saying that it's the most important thing, but it's certainly part of how we currently live our lives as a society. I think this is what human centric means because humans collaborate, right? It's the nature of people to collaborate. When that sometimes seems like it's the opposite, if you look at the state of the world these days, but we do collaborate, we do find groups to do things together with. And that is, you know, if you look at ancient history, that seems to be the greatest strength of people as a rule. So what do these mechanics of collaboration, what sort of features do you need to derive from it? What are the requirements that you need to fulfill in order to enable these mechanics? Well, first of all, communication and also sharing skills. I mean, the can be real time, right? We have asynchronous communication like email, but something like a chat, something like, you know, video conferences, they're real time communication. Similarly, working together and stuff, I can take a task and do it on my own, or we can use one of those online editors where both of us can type something. It can be real time. So we should support real time. You also need to deal with X control and ownership. I do not want to communicate everything that I want to communicate with the entire world. And unlike HTTP, which sort of actually solves this, I think we have to solve this from the beginning. Otherwise, we don't really support the mechanics of collaboration. We also have to update parts of resource. And I'll get to that in a moment and next slide in more detail, but the resolution of the resource, the entire resource, is a little bit difficult when it comes to things like video. Right? Video is huge. If you want to change a frame in a video, you don't really want to upload of gigabytes of video file. Now, selling services can mean that you want to do something like server side processing. I'm not saying that's the highest priority feature there, but this thing that HTTP allows isn't necessarily bad in itself. Right? It's more the way that it does it is a bit broken. Quick interjection. What do you mean when I talk about real time? Well, I'm not talking about hard real time where things happen simultaneously on several computers, which is hard to do anyway, but assuming it would work. What I'm talking about is that it can consume data in the process while it's in the process of being produced. And that really means that you're producing consuming chunks rather than in entire resource. And that's what this point about a final resolution is all about. It also means that at the outset of your collaboration or your real time thingy, you don't necessarily know how much you're going to produce. Right? So the size is, in the beginning, is indeterminate. So really what we're talking about when you're talking about real time is about streaming data back and forth in both directions. And I want to highlight, because I started out talking briefly about video streaming on the web, on the internet. Sorry. I use these terms interchangeably, just like everybody else, right? It's just not correct. It was on the internet. Video streaming is a great use case because like 90% or something of the bandwidth used on the internet is video traffic. It has immense bandwidth requirements. But it also has very low latency requirements. There's a study that I read that points out how dropping a frame or two in a video stream is actually preferable to even a split second of buffering in the perceived quality of the video stream. So the low latency requirements are immense. So the high bandwidth requirements are immense, so it makes for the perfect use case. If you manage to crack video streaming on the internet, you basically crack all kinds of data streaming. Now, I tried to make a table here, and I'm going to update this table so we don't have to spend too much time on this. We're going to see it again and again. Basically you can come up with solutions to these requirements, or at least partial solutions. For data streaming, you have to use something other than HTTP. I tried to point out very quickly. It's not ideally suited to processing anything finer than an entire resource, so data streaming is not really something that HTTP handles very well. There are clutches for it. They're being used. Don't get me wrong. That's not ideal. Exit control and ownership, you can probably solve with encryption some way. There are schemes for this. I don't want to get into them. Just for the sake of this talk, let's just assume that these are kind of solved problems, right, relatively speaking. Service site processing really comes down to remote APIs. I'm saying APIs because APIs is an interface deliberately between the programmers who come up with the service site processing stuff and the users of the API, which are other programs, right? One of the things that helped me in my career to understand is that APIs basically contract. An API is not something that you change all the time, APIs where something that you engage very carefully in cooperation with the consumers of the API. That's why I'm saying remote APIs here rather than something like REST or something, which is not really about APIs even if you use it like that. I don't really care about the technology here. I really want to say APIs is the thing that enables server side processing or processing that's remote if you want to be a little bit more generic about it. I added a requirement here that sort of comes more from the beginning of the talk about HTTP that we don't really need a man in the middle. I don't mean this in the encryption sense. I mean this in the practical sense, right? If I send you a file, there is no human requirement why this file needs to be sent through a server. The technical requirements that make that easiest, but it's not really embedded into the mechanic of collaboration, right? It's not something that the mechanics of collaboration require. That also leads me to conclusion that in order to enable this, we really need to move away from HTTP. It's the wrong medium for modeling collaboration as it happens in the offline world. There's another set of problems that also lead to requirements is about data locality and device that we tend to use. In the beginning with HTTP, we had the web client, the web server. Basically everything was shared through the server, right? You had two clients connected to the same server. If they wanted to access the same resource, it was through the server. That's good because it allows for this kind of collaboration with a centralized instance. But nowadays we have a different problem. Most of us at least tend to have multiple devices, right? There's my mobile phone, there's the laptop that I'm streaming here from, recording, sorry. There's other laptops I have here. I have Raspberry Pi, I have Homesore, all these kind of things. Each of them has its own local storage. Each of these storages contain data from me. Really somehow we need to handle the fact that my data, the data that has to do with me is owned by me, is fragmented across multiple different devices. This problem is only going to get worse because what we also have now is IoT and smart sensors. Now I had a chip here that I wanted to show you, but I mislated. It's basically as big as my fingernail and it's a full CPU with a USB connection. We're now in a world where it's so easy to add devices, really cheap devices to everything that we have machines recording our data in the form of smart sensors. While I don't have hundreds of them in my home, it's very easy to foresee a future where that is happening, right? And then some homes are already happening. Some of these actually have a different type of connectivity than the internet, right? You have Bluetooth or energy, you have Lora, which may make this a bit harder to deal with. Particularly when you look at Bluetooth, most of the Bluetooth devices that you have, you need to connect to. And they're sort of passive devices, right? They're not active clients that connect to a server. They're passive devices and when you connect to them, you can use the functionality. So this inverts the client and server roles. So maybe this idea of having client and server as strictly divided as in the HTTP world is no longer serving our needs. This leads to a couple of other requirements. One is with personal devices is sort of a smooth hand over between link technologies. My example there is always if I'm in a video conference and I leave my home network and I'm only in range of my LTE network, I really wouldn't want my video conference to crap out me. Sorry for the word. I do swear. I don't want to swear on camera. Just did it now. Sorry about that. But yeah, the point is in an ideal world that wouldn't happen, right? Currently, I don't know of any service that doesn't at least interrupt the call for a while while it tries to reconnect. Then the smart sensors and the multiple devices also mean we need to be a bit selective about how we synchronize data, right? I have a home server that serves as a backup for everything basically and that's back up to the cloud somewhere. And I can't pull all the data that's on there onto my mobile phone, right? I want to be able to selectively say, okay, these documents, maybe you always synchronize this document to synchronize in demand and these things I don't even care about, right? And that's sort of requirement for dealing with this fragmentation of data. And I said this in the previous slide without the red arrows. These different link technologies may mean that we have to move away from the client and serve an architecture that we're used to from HTTP. So I just added this as a kind of extra requirements with the solutions for this. For the smooth handle, we need to somehow be able to extract these link technologies. There's words for multi-homing, multi-pousing, multi-link. It's basically all the same thing on some level. Selective synchronization can be solved if we manage to treat resources, something you can subscribe to, right, individually or as a collection. We need some kind of pubs up for resources. The difference link technologies might lead to the conclusion that you want some kind of overlay network that sort of abstracts out all these differences of the link technologies in a way that IP currently does not. It's not that IP can't do it. It's that the deployment of IP is not always such that that makes it easy, right? And lastly, the dissolution of the strict client and server roles might lead to the conclusion that we have to have some kind of HTTP technology. I want to talk briefly about drones now. Oh, wow. Now the light is coming in. I'm very bright here. Okay. I can't move away from the sun. Anyway, it's working on these drone projects. And I want to run briefly through what we're doing there just to illustrate how related the requirements can be between, you know, collaboration and just handling drones. And the main problem that's currently trying to be solved is how to enable drones to fly beyond the visual line of sight. So in European regulations, and I'm going to do this really fast, there's basically three class of drones. There's toy drones, there's military drones. You know, toy drones, you are always they lie in sight. Military drones are not under control. And in the middle in the so-called special category, there is the possibility of using drones for commercial purposes, which might mean pizza delivery to your door or something like that. And the other regulations basically require that the command control and communications link as they call it, to be reliable. And I linked here in blue, there's actually a link to a paper that I wrote together with one of my coworkers on the summary of these requirements, the summary of technologies that exist and how they pretty much all of them, not completely, but not completely fail, but aren't exactly good solutions to this kind of problem. And the use case that we're having is handovers, right here as a C3 link and handover illustration from anywhere. We see a drone, the drone is connected to a satellite or to a ground station there, the yellow lightning goes to a mast, the blue lightning goes to another antenna. And when one of these goes out of line of sight, you still need to have a connection and you have this connection via the different link. It's exactly the same use cases, if I leave my house with the video conference on and step into the LTE network, right, it's just different devices. And maybe sometimes different technologies, I don't have a satellite link on my mobile phone. But the basics are almost exactly the same. So I crossed out a couple of things that weren't so important for the drone use case, but that are sort of in the same realm. The streaming requirement is also there. You want to stream command control information. Access control as such is no longer as important as its temper processing. And that's an ERs requirement. People are not supposed to modify command control messages for drones, otherwise they make them crash into buildings or something. We don't want that. Ownership of data is also not as important, but what's important is identification, right? Drones should only accept commands from identified ground stations. Siversite processing is not very important. Smoother and over is just as important as actually the use case we're working on. The only thing that really doesn't matter at all is this whole selective synchronization thing, but that's for now, right? When you assume a future where maybe a smart drone collects information from IoT sensors and relays that to the ground station somewhere, maybe that actually becomes a requirement also for drones, but right now it's not really something to talk about. But the other things are also there. Drones cannot really act as a client or a server in all cases. Drones have these different linked activities that you have to deal with. Really the requirements from drones that I'm working on with anyway, the requirements of collaboration are almost exactly the same, even if the focus is slightly different on some aspects here. So where do I want to go with this? I spoke about collaboration. That's really the thing I want to solve, right? But there are also some, no actually, here's the list again. I added at the bottom here ease of adoption, right? In a way that's the last thing, right? We talked about technological problems and how we might be able to solve them that somehow support collaboration. But one of the things that HTTP has toward us and that shouldn't be discarded is that simplicity is key for ease of adoption, right? If we come up with a massively complicated stack here that nobody wants to use, it's not going to happen. So that presents a challenge because this entire thing of multiple links and resources that you subscribe to and access control, it becomes complex by virtue of fulfilling all of these requirements. So here we have a bit of a conflict and that's a tough one to crack, but no, I like challenges. The vision is basically nothing else than what we already do, just better. We have to assume that our data, that data that concerns us, that is owned by us, lives on many different devices. But we also want them safe and malicious access. We must be able to access our data at any time. If we want to access it in parts, it should be fast. If we want to access it in full, then we can maybe accept that it can't be super fast because it's really remote and everything has to be pulled over. But if not, of course, to access it, fine. But at least the partial access needs to be fast. It would be nice if we can access our data from any device, even if it's not our own, right? If I use my friend's phone, and I use my private key to identify myself, why shouldn't I be able to pull some data from other devices that I own or that are in the cloud that belong to me so I can use the phone just to do my own thing, right? And then I discard it all again. We have to be able to share and collaborate with our data. And that's basically just writing down the requirements from earlier, the mechanics from earlier. We also want to be able to collectively allow access to our data to processing nodes. And my example here is printers, right? If I want to print a document from my phone, I don't really want to go through a print server. I don't really want to go... Sorry, I said from my phone that's the wrong use case. I mean something else. I know I have a video file that's not on video files that I've printed. I have a document somewhere on the server. I don't actually want to be able to open the document and download it to my phone in order to print it to the printer next to me. What I really want to be able to do is send an authorization to the printer over the local network that it may, or maybe a limited time frame, download the document itself and print it. That would be the ideal use case for how to deal with devices that sort of process our data temporarily. So, one of the things that I haven't highlighted enough here is that the HTTP and the server functionality part of HTTP also means that it's sort of pushing... I mean it is an application level protocol, but it is sort of pushing the protocol to stay there. So, our adoption of HTTP is something that approaches infrastructure is really quite broken. What we really need to do is... That's my opinion here. That's why I'm talking to you guys. What we really need to do is focus more on infrastructure for collaboration. We need more infrastructure protocols. That's really what I'm trying to do here with this whole project. Build a stack of infrastructure protocols that allow us to then build applications on top of it without highlighting them in the same way that the web does. Very briefly here, philosophically, we have to distinguish a little bit between peer-to-peer, peers and hosts and peers and posts. People tend to conflate that you and it's not the same thing. The host-oriented part of peer-to-peer is something that enables the human-centric part. That's really all I want to say here if you want to look at the slides by Augusto. I have to hurry up a little bit. There's not so much time left in my lot. It's a lot here. I want to talk about what I've done so far in this and where the progress is. There's a small library. I'm skipping all of this. It's just a platform abstraction library that I've been building along the way. You can use it. You can add to it. It's not anything magic, but it's nice and small. There's Packeteer, which is a Vend-based socket library. There are plenty of similar projects out there. The focus of them is a little bit different. When I started this, which is a long time ago, it didn't really exist in quite this way. That's why I stuck with this. I'm not saying you need to pick this for your projects, but that's what I'm going to use going on. Check it out. There are some problems with it. The Windows port works. It's a little bit buggy. I need to rewrite this a little bit when I have time. The OZ part is fine, but it can use some cleaning up. I would like to add a SketchRIO as much as possible. It's really not very important right now, but it would enable slightly more high-performing servers. There are tweaks extensions that I want to add to it, but it's largely finished if you want to play around with the Packet-oriented network protocol. You can use this already. Channel as the library I'm currently working on is very work in progress. It's really trying to do a multi-channel protocol, much like the channels on HTTP3.2 as well. The point is with P2P you have to maybe penetrate ads firewalls. Once you've done that, you really want to stick with this one port combination to talk to. In order to then multiplex different data streams through this one connection, maybe it's best to have the provisions for some kind of channels in the protocol so that it gets easier. That's what I'm working on there. It's also a bit of an abstract protocol that is very ready for extensions. One of the extensions I'm already thinking about is how to add encryption to this part of the requirements. I'm looking at doing it in more or less the same way as the WireGuard does. There are problems with WireGuard in this context, but it really needs to fast-run the discussion. I'll skip over this. There are also provisions and therefore adding the multi-link stuff that I'm doing with NUI basically. I want to add some channel-specific settings for how to deal with resins and reliability. It's currently UDP-based because I want to be able to ship it in apps basically. I want people to be able to build applications with it right now. The way I'm working on it, it should be possible to run it directly on IP or on Ethernet. This is not really necessary at the moment, but I'm sort of looking into a future here where maybe that becomes interesting. Maybe hopefully. That's the whole point of the Next Generation Internet Initiative. I'm sort of staying focused on this a little bit. I spoke about multi-path, multi-link. With NUI, we work on this as part of the Adacasa project. I've prepared a paper that I need to finish in the next few days, actually. That's focusing on the abstract protocol, the messages, the state machines. It should be finished in draft this month. I'll probably make a pre-print available and then it should be published sometime in the middle of this year. That's really the model that I want to use for channel-less multi-link support. That's pretty much where we are. I think for a year where I barely could work on it because of the pandemic, it's not actually terribly bad. At least that's what I try to tell myself here. I want to salvage things. The future. Where do we go from here? Let's assume that this problem of efficiently streaming data between peers is solved, which will still take some time. Including the multi-link part, including the multi-channel part. We need something like a distributed hash table in order to find peers in the network. I didn't put this on the slide, but we also need the whole NAT-nutrition thing, sort of stun, turn, their implementations out there. Maybe it's better to add them to the basic protocol so that it's not too much of a collection of different things. The next part that can be layered on top of the bare data streaming, if you want, is to have a streaming protocol much like PPSPP. That has two modes. In order to access a resource that already exists that's finished, you can use a mercury to identify specific parts of the resource and download them in order to complete your picture that you have locally. But there's also a streaming mode. While some of the things in the specification don't really fit anything other than TCP at the base, it has plenty of interesting ideas that can be adopted. Lastly, I put here a distributed file system. This goes back to simplicity. I suspect that the API that most programmers will be most comfortable with is FileIO. We have things like local sockets which are file-like in how they're presented, but actually are streaming connections, if you want. A file system like API, it shouldn't be exactly like a file system. Maybe the solution for modeling how we access resources that belong to us, resources that are on other machines, streams to other machines or the people who use them. There is a precedent for this. I'm very glad to know that it's gaining in popularity, that's the Plan 9 operating system. It actually has a 9P protocol that is a remote file protocol. It does nifty things like exposing the screen of your machine or a window or a map pointer as a device that you can read from. It makes using what the hardware provides very, very easy. Maybe that's the direction you have to go. It's a bit fuzzy, my mind is still something I have to think about a bit more, but I have some ideas in that direction. I'm already over time, which means the Q&A section is going to be a bit shorter, but let's stick with this. Quick note on how you can contribute. Very easy. I'm not very useful at something like presenting this project. This talks the first, and I'm giving help with design and does design identity guides is going to be appreciated if you are not technical. Website and documentation templates would be appreciated because that's just not something I'm very good at. Any feedback you can give on the protocol work, so that means reading the papers, looking at or just talking to me, that's going to be appreciated. The project is relatively financed. I'm not here standing asking for donations. In fact, I'm not really set up to receive donations. That's all taxable income for me. But I would like to start a foundation or a nonprofit or a public interest company, whatever works, so that we can accept donations and scale this up because one of the things that would be very useful would be have a handful of developers to work on this full time. I'm not even managing to do full time myself right now, but that's sort of the thing I would like to work towards in the next year. If you have fundraising experience for this kind of thing, then yes, please. That's the contribution I'm looking for the most in a way because that would allow me to scale this thing up in the way that I think it should be. And that's it with the Q&A section. I just want to point out there's a website. It's basically just a placeholder. There's my email address. You can send me an email. I will try to respond at least. The last URL is a blog where I talk about protocol design a little bit. It's not massively large yet and very, very rare that I post something new, but it's there. And now we're at 53 minutes and I have to stop. Thank you. Thank you.
 Hi, welcome to my talk on designing human-centric next generation internet.  Here's Boston in 2021.  My name is Jens Schienkhoiser.  Before I start, let me just tell you this.  I started writing the slides for this talk and I thought, yeah, I don't actually have  enough content to fill everything up and at the end, I had too much.  So rather than take slides out again, what I'm going to do is I'm uploading the slides,  but maybe I rushed through some of them a little bit.  I think that's only fair.  And the first thing that I will rush through a little bit is the introduction.  Basically this slide just tells you I'm old.  This slide has a little bit of content.  I have experience in video streaming on the web through peer-to-peer networks, sorry,  not on the web, on the internet through peer-to-peer networks.  And that goes back as far as 2006 when I joined Juist.  Ancient history, read up on it if you want.  I'm going on.  Ask forward a little bit.  This talk is about the Insepia project.  Why did I start this at all?  After this experience with video streaming on peer-to-peer networks from a long time  ago, I got in contact in early 2019 with a startup that wanted to do basically the same  thing, but somehow involved with blockchain.  And while that didn't work out, from my point of view, they were a little bit too invested  in the blockchain side of things.  And I guess I was too much invested in the peer-to-peer side of things.  Part of ways, but that gave me the understanding that actually there is still need and also  desire for peer-to-peer technologies in the world.  And that meant I started looking for funding, which I found from an Aonet.  Unfortunately, just after the grant was given or accepted, the challenge was accepted, the  pandemic hit, and I didn't really work as much on it in the last year as I wanted to.  And because of that, because of the lack of income that resulted from that, I also had  to look for a part-time job.  So I joined NUI Technologies.  Now that's interesting in a way that I will get into later.  Funding.  The Insepia project is currently funded by an Aonet, which takes the funds from NGI  Zero.  It's the second-generation commission's next-generation internet initiative.  An Aonet also collects donations.  So if you ever have any money left over that you want to put into financing FOSS here in  Europe, give it to an Aonet.  They will try to put it towards the right projects.  And also about NUI.  NUI is involved in making smart routers, wireless routers.  And then because of this, they got involved with two drone projects that are funded by  Excel, the Excel joint undertaking, which in turn is half funded by Horizon 2020, or  at least part, I don't know, a part, and part by the industry.  So these are two projects that I'm active in that relate very closely to the Insepia  project in some details.  Why I'm doing work for NUI.  And NUI has kindly let me publish some of these things in papers and there's more coming.  So even though they don't actually fund the Insepia project, they do fund, in their own  self-interest if you want, a very closely related work that's also making it to some  degree into the public domain can be used by the Insepia project as a result.  And that's a very nice arrangement to have.  So if you're looking for a job that has to do with networking or embedded or drones,  maybe NUI is the place for you.  You would have to work with me though.  Good morning.  All right.  So let's start with a bombshell.  The web is dead.  Yeah.  I don't know if that's too small, but it has a small tagline that says actually it will  stay on there for quite some time.  I don't think I can, this is a section actually I want to skip over relatively fast because  it will consume too much time otherwise.  But it's very hard to understand why I'm so invested in doing something peer-to-peer  when you assume that the web is in good health.  So I'm running through a couple of quick points on what's actually really fundamentally  contributing to the problems that we see on the web today in the web architecture.  First of all, there's a timeline.  You don't have to read everything here.  Left is basically the development of the HTTP protocol.  Right is development of sort of security and authentication technologies, roughly ordered.  And I made red arrows there to sort of delineate the beginning, the middle, and the end of  a mid-era of the web development.  And there's a before and after, of course.  So I've divided this, and you don't have to follow this, but I've divided this web  history in like three big eras.  The early web, the HTTP protocol was not massively specified.  It got specified after a while, got a revision immediately after.  And it helped establish HTTP as a decentralized protocol.  Security at that time was not the highest issue.  The focus pretty much was on publication, on publishing data that's already, that's  meant to be public.  So the idea was you run your own server, you upload documents to the server for the world  to see.  And that's great, but that's not how we use the web today.  The.com bubble came, it burst.  And then it sort of got restarted with Web 2.0.  And one of the interesting parts of Web 2.0 is not that there were new technologies or  something that's not actually necessarily the case.  But that was an era where commercial entities tried to pull more and more users to the web.  They realized that there was money to be made there, but they also realized that the model  where everybody who had something to say would run their own web server and publish stuff  on this web server, that model doesn't work.  What you have to do is you have to take this technological challenge away from users in  order to broaden adoption.  So you see a lot of, in this area you see a lot of security features being added in  form of TLS, new authentication methods, and also starting towards, I'll put this here,  HTML5.  I'll get to that a little bit later.  And this era pretty much ended when containerization in the form of Docker basically came along.  What happened there is that the scale of pulling all the users onto the web became too large  to handle, or at least too large to handle by the conventional methods.  So data center operators, Google, Amazon, all the big ones, started to look for ways  to make handling this complexity easier.  And so they came up with tools.  I put Docker here.  You could easily talk about OpenSec or Kubernetes.  That's not really the point.  The point is these are all technologies that help manage the complexity of scaling up the  web.  There's a feedback back loop here because it started out with consolidating users on  a smaller number of services that led to a larger scale that leads to complexity.  And now what happens is that with the adoption of these management technologies, you have  even more consolidation because the easiest way to do stuff on the web now is by using  the technologies that enable large scale.  So we come back to the same problem again in a loop.  The web protocol has issues.  One of them I sort of outlined in the timeline skipped over it very quickly is that if you  look at the timeline closely at every security feature that exists in the web stack has been  added as an afterthought, whether it's encryption or authentication.  And privacy has never been a topic because the assumption from the early web was that  you would own your own web server.  And if you own your own web server, then privacy is guaranteed, right?  But that's no longer the case.  What we can also see in these eras, if you look closely, I'll leave that up to you, is  that really the developments after HTTP 1.1 and HTML4 give or take, the development of  new web technologies has only been driven by commercial interests.  Commercial interests really never involve them unless you assume that large corporate  entities have the user's best interests at heart.  And we now end it in a world where HTTP 2 and HTTP 3 is effectively designed by Google  for Google scale data centers.  It isn't really, there aren't really many necessary changes in there for the original  model of the web where you would run your own web server.  So it has to do with scale.  But there's also fundamental issue that comes with the assumption that everybody runs their  own web server.  It's that HTTP is and isn't quite, I'll skip over the slide a little bit.  Just once you understand that in HTTP everything is a resource and every resource has a unique  URL.  And all the HTTP methods basically operate on an entire resource.  And it's completely fine when you have a document to upload, some text, 10 paragraphs, even  three pages, it doesn't matter.  You can upload a whole new document as a change to the existing one.  The update mechanism is where things break and the partial retrieval is where things  break.  Partial retrieval is get with range header.  I can read up on this.  I'm not going to explain everything.  The point is only that range headers are not really easy to support and therefore they're  not very widely supported, especially not if you're doing something like running an  HTTP proxy in behind that's an application server.  It doesn't work particularly well.  It can be major work, but it's hard work.  On the update side, post and patch are defined in the specs to have a content, a request  body that is specified by the server effectively.  So the server implementer decides how to handle a particular media type in the request body.  Really what these things mean, the update part in particular, is that it's very hard  to make generic web clients.  They have something like a browser that does something generic, but if you look at our,  for example, an update patch method is being used, there is no generic implementation in  the web browser for doing patch.  What you have to do is you have to write a JavaScript that then does the patch method.  The JavaScript, well, you deliver it with your web server.  So you bundle both the implementation on the server side with the implementation on the  client side in one go.  A generic patch as such doesn't really exist.  It really must lead to one thing, that the server owns the data, because really only  the server implementation understands how to handle the data.  There is no way for a generic client to do this.  Historically we have a similar problem with HTML.  Read through this briefly if you want, but the short story is that HTML5 has basically  given up on standardization.  Yes, there are standardizations, but it's a living standard, which means the standardization  that changes all the time.  What happens is that most of this changes driven by what WebKit supports.  WebKit is owned by Google.  It's open source.  We can all use it, but you still have a very big influence of one company here on what  actually happens on the client side.  Now, when I mention this to people, one person responded, yeah, but React and TypeScript,  they also have great influence on this.  Maybe, maybe so.  They're not making a browser engine, though.  So for me, this is not the biggest issue here.  And there's also a conceptual problem with HTML, because HTML mixes data and representation.  So and also with JavaScript and processing.  So it's not NBC at all.  Now you don't have to believe in NBC, you can use MVVM or whatever.  The point is by bundling the logic on how to manage data with the data and the backend  that only can deal with whatever happens on the client side that it has sent to the client,  you really are creating data silos.  You're not building a web of data that can be processed elsewhere.  The semantic web effort is trying to do this.  It hasn't got very far as far.  Well, there's a lot of development there, don't get me wrong, but most developers don't  talk about the semantic web as the solution to their problems.  In that sense, it hasn't really gone very far.  I'm not trying to tell you here that people have way and working with this are not doing  their stuff, but not the case, but the adoption is not so great.  And yet, HTTP has strengths.  This is why it got adopted.  And I will highlight this briefly.  It's simplicity, simplicity.  It's very easy to get started with.  The complexity arises later.  And the complexity always leads to this issue of centralization that is pretty much inevitable  in both the scale that we see nowadays and the HTML JavaScript combo that makes it impossible  to do smart things like a patch method without this mechanism of also delivering some processing  instructions to the client.  So where do we go from there?  Well, we can see some kind of trends here.  This is a little bit, every slide is going to be a little bit different on a slightly  different topic here for a second.  This I found particularly interesting is only a couple of days old now.  This is a response to Donald Trump being banned on Twitter and Facebook and whatever else.  Basically we have with the centralization, we can buy the censorship.  Now I certainly don't, I'm not impressed with Trump's track record, but I don't want to  get politically, I just need to get that out here.  But by having communications platforms centralized in large corporations, we effectively have  come to the point now where corporations have the power to censor heads of state, irrespective  of who they cut off.  That's a very, very dangerous precedent and it's something that we have to be very careful  about.  Second, centralization has become the default for most developers, right?  It's not something that people tend to challenge anymore.  I got sent this, this is from Moxie Marlin's comment which looks like it's on GitHub.  I got sent this with some kind of, it's old, right?  It's four years old.  I got sent this with some kind of highlight there that seems to say that he's happy with  centralization.  I don't think that's actually the case if you read the words carefully, but it certainly  reads as if doing anything other than centralized approaches is too hard.  And if this is coming from a very smart guy, I think we have a problem, right?  He's got a track record, whatever else you think of him, he's got a track record of doing  some very, very smart things.  Now he's an inventor of signal and the protocol around it.  And if he thinks that doing something like signal in decentralized or distributed fashion  is too hard, well then our entire field has an issue, basically.  Completely different from the technological and control angle, we also, sorry, the censorship  angle, we also have defaulted to yielding control, right?  This has even the nerdiest nerds with very few exceptions are happy with this, right?  Most of us have a smartphone and very few of us run free operating systems on it because  it's too much of hassle.  And I sort of blame this trademark tagline there which is why I modified it.  I think I fixed it actually, yeah?  We're looking no longer at how to handle data, how to deal with the data that we have and  give it to other people.  We tend to look at the channels, right?  Which channel allows us to do what?  And I think that's a very broken way of looking at how a worldwide network of people, which  is essentially what the internet is in the end, even if it's primarily computers.  That is supposed to operate.  Now, I want to get to this, let's get signed around everyone to know why the internet interprets  censorship as damaging routes around it.  I think this was the case when it was written in 93 where everything was very decentralized.  And it's also important to highlight that the web and the internet is not the same thing,  right?  It tends to route around damage, whether it's censorship or something else.  It tends to route around it because that's how the IP protocol is constructed.  That's a good thing.  But the web, by its very, by the nature of making it easiest to centralize stuff, is  no longer routing around damage.  In fact, it actually encourages exploitation and censorship.  And that's why this quote is pretty important to put in there.  That was my old man, yeah, that's a cloud section of the talk.  Let's move on to something slightly better.  But I wanted to go through this briefly so that you guys understand.  I mean, I run into people who not long to every point here, and I don't have to explain  myself pretty much.  But then there are people that say, but it's good, but it's easy.  But look at what it lets us do.  And they're, of course, all right, no?  The truth lies somewhere in the middle.  The question is, how can we get the same benefits without these problems?  That's what we're trying to solve here at the Interpreter Project.  By the way, I just said we.  That's what leads me.  But since I'm working with colleagues at NEY to do something related, I'll get to that  again.  And I talk about this kind of problem with a lot of people when I can.  It feels like there's more people contributing.  Yeah, unfortunately, right now it's me.  So the focus, in my opinion, should be collaboration.  And in the title of this talk, I've spoken about human centricness.  What I mean by human centric is that it should focus on people's needs, right?  We should think of the Internet as something that serves people's needs.  And really, what it comes down to is collaboration, which is why this deaf room is a good place  for this talk.  Because standalone computer without any Internet connection does serve my needs to write text  or program or whatever, right?  I don't need the Internet for that.  But the moment I want to hear ideas or explore other people's ideas together, then we're  talking about collaboration, really.  So human centricness and collaboration, I would say it's almost the same thing, not  quite, but almost.  I want to look at the collaboration part first.  I try to write down a list of mechanics, what mechanics exist to make collaboration happen.  And the first one is communication.  You can't communicate.  You can't collaborate without talking about what you want to do, right?  In fact, communication is already collaboration in itself in a way that you exchange ideas,  you exchange thoughts, you even just touch base with people.  That's already collaboration.  The next step is that you want to share stuff.  You want to give and receive things.  And I put here digital assets because it's the Internet we're talking about.  But really, in the offline world, it's like give somebody a cup of tea, right?  That's giving stuff, that's sharing.  I would like you to view this more as a trade.  It doesn't even have to be something that is a mutual exchange, right?  Where you give and receive something.  But it shouldn't be thought of as sharing in the sense of social media, where you just  take something that somebody else has written and broadcast it to your circles.  You can do that as well.  But sharing I'm talking about here is more the give and receive things.  The other thing is sharing skills.  Once you're working together on something, what you're actually doing is you're sharing  your experience, your skills, your point of view, or it's a shared project.  And that can be also commercial, so to speak, tell your services.  Not saying that it's the most important thing, but it's certainly part of how we currently  live our lives as a society.  I think this is what human centric means because humans collaborate, right?  It's the nature of people to collaborate.  When that sometimes seems like it's the opposite, if you look at the state of the world these  days, but we do collaborate, we do find groups to do things together with.  And that is, you know, if you look at ancient history, that seems to be the greatest strength  of people as a rule.  So what do these mechanics of collaboration, what sort of features do you need to derive  from it?  What are the requirements that you need to fulfill in order to enable these mechanics?  Well, first of all, communication and also sharing skills.  I mean, the can be real time, right?  We have asynchronous communication like email, but something like a chat, something like,  you know, video conferences, they're real time communication.  Similarly, working together and stuff, I can take a task and do it on my own, or we can  use one of those online editors where both of us can type something.  It can be real time.  So we should support real time.  You also need to deal with X control and ownership.  I do not want to communicate everything that I want to communicate with the entire world.  And unlike HTTP, which sort of actually solves this, I think we have to solve this from the  beginning.  Otherwise, we don't really support the mechanics of collaboration.  We also have to update parts of resource.  And I'll get to that in a moment and next slide in more detail, but the resolution of  the resource, the entire resource, is a little bit difficult when it comes to things like  video.  Right?  Video is huge.  If you want to change a frame in a video, you don't really want to upload of gigabytes  of video file.  Now, selling services can mean that you want to do something like server side processing.  I'm not saying that's the highest priority feature there, but this thing that HTTP allows  isn't necessarily bad in itself.  Right?  It's more the way that it does it is a bit broken.  Quick interjection.  What do you mean when I talk about real time?  Well, I'm not talking about hard real time where things happen simultaneously on several  computers, which is hard to do anyway, but assuming it would work.  What I'm talking about is that it can consume data in the process while it's in the process  of being produced.  And that really means that you're producing consuming chunks rather than in entire resource.  And that's what this point about a final resolution is all about.  It also means that at the outset of your collaboration or your real time thingy, you don't necessarily  know how much you're going to produce.  Right?  So the size is, in the beginning, is indeterminate.  So really what we're talking about when you're talking about real time is about streaming  data back and forth in both directions.  And I want to highlight, because I started out talking briefly about video streaming  on the web, on the internet.  Sorry.  I use these terms interchangeably, just like everybody else, right?  It's just not correct.  It was on the internet.  Video streaming is a great use case because like 90% or something of the bandwidth used  on the internet is video traffic.  It has immense bandwidth requirements.  But it also has very low latency requirements.  There's a study that I read that points out how dropping a frame or two in a video stream  is actually preferable to even a split second of buffering in the perceived quality of the  video stream.  So the low latency requirements are immense.  So the high bandwidth requirements are immense, so it makes for the perfect use case.  If you manage to crack video streaming on the internet, you basically crack all kinds  of data streaming.  Now, I tried to make a table here, and I'm going to update this table so we don't have  to spend too much time on this.  We're going to see it again and again.  Basically you can come up with solutions to these requirements, or at least partial solutions.  For data streaming, you have to use something other than HTTP.  I tried to point out very quickly.  It's not ideally suited to processing anything finer than an entire resource, so data streaming  is not really something that HTTP handles very well.  There are clutches for it.  They're being used.  Don't get me wrong.  That's not ideal.  Exit control and ownership, you can probably solve with encryption some way.  There are schemes for this.  I don't want to get into them.  Just for the sake of this talk, let's just assume that these are kind of solved problems,  right, relatively speaking.  Service site processing really comes down to remote APIs.  I'm saying APIs because APIs is an interface deliberately between the programmers who come  up with the service site processing stuff and the users of the API, which are other  programs, right?  One of the things that helped me in my career to understand is that APIs basically contract.  An API is not something that you change all the time, APIs where something that you engage  very carefully in cooperation with the consumers of the API.  That's why I'm saying remote APIs here rather than something like REST or something, which  is not really about APIs even if you use it like that.  I don't really care about the technology here.  I really want to say APIs is the thing that enables server side processing or processing  that's remote if you want to be a little bit more generic about it.  I added a requirement here that sort of comes more from the beginning of the talk about  HTTP that we don't really need a man in the middle.  I don't mean this in the encryption sense.  I mean this in the practical sense, right?  If I send you a file, there is no human requirement why this file needs to be sent through a server.  The technical requirements that make that easiest, but it's not really embedded into  the mechanic of collaboration, right?  It's not something that the mechanics of collaboration require.  That also leads me to conclusion that in order to enable this, we really need to move away  from HTTP.  It's the wrong medium for modeling collaboration as it happens in the offline world.  There's another set of problems that also lead to requirements is about data locality  and device that we tend to use.  In the beginning with HTTP, we had the web client, the web server.  Basically everything was shared through the server, right?  You had two clients connected to the same server.  If they wanted to access the same resource, it was through the server.  That's good because it allows for this kind of collaboration with a centralized instance.  But nowadays we have a different problem.  Most of us at least tend to have multiple devices, right?  There's my mobile phone, there's the laptop that I'm streaming here from, recording, sorry.  There's other laptops I have here.  I have Raspberry Pi, I have Homesore, all these kind of things.  Each of them has its own local storage.  Each of these storages contain data from me.  Really somehow we need to handle the fact that my data, the data that has to do with  me is owned by me, is fragmented across multiple different devices.  This problem is only going to get worse because what we also have now is IoT and smart sensors.  Now I had a chip here that I wanted to show you, but I mislated.  It's basically as big as my fingernail and it's a full CPU with a USB connection.  We're now in a world where it's so easy to add devices, really cheap devices to everything  that we have machines recording our data in the form of smart sensors.  While I don't have hundreds of them in my home, it's very easy to foresee a future where  that is happening, right?  And then some homes are already happening.  Some of these actually have a different type of connectivity than the internet, right?  You have Bluetooth or energy, you have Lora, which may make this a bit harder to deal with.  Particularly when you look at Bluetooth, most of the Bluetooth devices that you have,  you need to connect to.  And they're sort of passive devices, right?  They're not active clients that connect to a server.  They're passive devices and when you connect to them, you can use the functionality.  So this inverts the client and server roles.  So maybe this idea of having client and server as strictly divided as in the HTTP world is  no longer serving our needs.  This leads to a couple of other requirements.  One is with personal devices is sort of a smooth hand over between link technologies.  My example there is always if I'm in a video conference and I leave my home network and  I'm only in range of my LTE network, I really wouldn't want my video conference to crap  out me.  Sorry for the word.  I do swear.  I don't want to swear on camera.  Just did it now.  Sorry about that.  But yeah, the point is in an ideal world that wouldn't happen, right?  Currently, I don't know of any service that doesn't at least interrupt the call for a  while while it tries to reconnect.  Then the smart sensors and the multiple devices also mean we need to be a bit selective about  how we synchronize data, right?  I have a home server that serves as a backup for everything basically and that's back up  to the cloud somewhere.  And I can't pull all the data that's on there onto my mobile phone, right?  I want to be able to selectively say, okay, these documents, maybe you always synchronize  this document to synchronize in demand and these things I don't even care about, right?  And that's sort of requirement for dealing with this fragmentation of data.  And I said this in the previous slide without the red arrows.  These different link technologies may mean that we have to move away from the client  and serve an architecture that we're used to from HTTP.  So I just added this as a kind of extra requirements with the solutions for this.  For the smooth handle, we need to somehow be able to extract these link technologies.  There's words for multi-homing, multi-pousing, multi-link.  It's basically all the same thing on some level.  Selective synchronization can be solved if we manage to treat resources, something you  can subscribe to, right, individually or as a collection.  We need some kind of pubs up for resources.  The difference link technologies might lead to the conclusion that you want some kind  of overlay network that sort of abstracts out all these differences of the link technologies  in a way that IP currently does not.  It's not that IP can't do it.  It's that the deployment of IP is not always such that that makes it easy, right?  And lastly, the dissolution of the strict client and server roles might lead to the conclusion  that we have to have some kind of HTTP technology.  I want to talk briefly about drones now.  Oh, wow.  Now the light is coming in.  I'm very bright here.  Okay.  I can't move away from the sun.  Anyway, it's working on these drone projects.  And I want to run briefly through what we're doing there just to illustrate how related  the requirements can be between, you know, collaboration and just handling drones.  And the main problem that's currently trying to be solved is how to enable drones to fly  beyond the visual line of sight.  So in European regulations, and I'm going to do this really fast, there's basically  three class of drones.  There's toy drones, there's military drones.  You know, toy drones, you are always they lie in sight.  Military drones are not under control.  And in the middle in the so-called special category, there is the possibility of using  drones for commercial purposes, which might mean pizza delivery to your door or something  like that.  And the other regulations basically require that the command control and communications  link as they call it, to be reliable.  And I linked here in blue, there's actually a link to a paper that I wrote together with  one of my coworkers on the summary of these requirements, the summary of technologies that  exist and how they pretty much all of them, not completely, but not completely fail, but  aren't exactly good solutions to this kind of problem.  And the use case that we're having is handovers, right here as a C3 link and handover illustration  from anywhere.  We see a drone, the drone is connected to a satellite or to a ground station there, the  yellow lightning goes to a mast, the blue lightning goes to another antenna.  And when one of these goes out of line of sight, you still need to have a connection  and you have this connection via the different link.  It's exactly the same use cases, if I leave my house with the video conference on and  step into the LTE network, right, it's just different devices.  And maybe sometimes different technologies, I don't have a satellite link on my mobile  phone.  But the basics are almost exactly the same.  So I crossed out a couple of things that weren't so important for the drone use case,  but that are sort of in the same realm.  The streaming requirement is also there.  You want to stream command control information.  Access control as such is no longer as important as its temper processing.  And that's an ERs requirement.  People are not supposed to modify command control messages for drones, otherwise they make them  crash into buildings or something.  We don't want that.  Ownership of data is also not as important, but what's important is identification, right?  Drones should only accept commands from identified ground stations.  Siversite processing is not very important.  Smoother and over is just as important as actually the use case we're working on.  The only thing that really doesn't matter at all is this whole selective synchronization  thing, but that's for now, right?  When you assume a future where maybe a smart drone collects information from IoT sensors  and relays that to the ground station somewhere, maybe that actually becomes a requirement also  for drones, but right now it's not really something to talk about.  But the other things are also there.  Drones cannot really act as a client or a server in all cases.  Drones have these different linked activities that you have to deal with.  Really the requirements from drones that I'm working on with anyway, the requirements of  collaboration are almost exactly the same, even if the focus is slightly different on  some aspects here.  So where do I want to go with this?  I spoke about collaboration.  That's really the thing I want to solve, right?  But there are also some, no actually, here's the list again.  I added at the bottom here ease of adoption, right?  In a way that's the last thing, right?  We talked about technological problems and how we might be able to solve them that somehow  support collaboration.  But one of the things that HTTP has toward us and that shouldn't be discarded is that  simplicity is key for ease of adoption, right?  If we come up with a massively complicated stack here that nobody wants to use, it's not  going to happen.  So that presents a challenge because this entire thing of multiple links and resources  that you subscribe to and access control, it becomes complex by virtue of fulfilling  all of these requirements.  So here we have a bit of a conflict and that's a tough one to crack, but no, I like challenges.  The vision is basically nothing else than what we already do, just better.  We have to assume that our data, that data that concerns us, that is owned by us, lives  on many different devices.  But we also want them safe and malicious access.  We must be able to access our data at any time.  If we want to access it in parts, it should be fast.  If we want to access it in full, then we can maybe accept that it can't be super fast because  it's really remote and everything has to be pulled over.  But if not, of course, to access it, fine.  But at least the partial access needs to be fast.  It would be nice if we can access our data from any device, even if it's not our own,  right?  If I use my friend's phone, and I use my private key to identify myself, why shouldn't I be  able to pull some data from other devices that I own or that are in the cloud that belong  to me so I can use the phone just to do my own thing, right?  And then I discard it all again.  We have to be able to share and collaborate with our data.  And that's basically just writing down the requirements from earlier, the mechanics from  earlier.  We also want to be able to collectively allow access to our data to processing nodes.  And my example here is printers, right?  If I want to print a document from my phone, I don't really want to go through a print  server.  I don't really want to go...  Sorry, I said from my phone that's the wrong use case.  I mean something else.  I know I have a video file that's not on video files that I've printed.  I have a document somewhere on the server.  I don't actually want to be able to open the document and download it to my phone in order  to print it to the printer next to me.  What I really want to be able to do is send an authorization to the printer over the local  network that it may, or maybe a limited time frame, download the document itself and print  it.  That would be the ideal use case for how to deal with devices that sort of process our  data temporarily.  So, one of the things that I haven't highlighted enough here is that the HTTP and the server  functionality part of HTTP also means that it's sort of pushing...  I mean it is an application level protocol, but it is sort of pushing the protocol to  stay there.  So, our adoption of HTTP is something that approaches infrastructure is really quite  broken.  What we really need to do is...  That's my opinion here.  That's why I'm talking to you guys.  What we really need to do is focus more on infrastructure for collaboration.  We need more infrastructure protocols.  That's really what I'm trying to do here with this whole project.  Build a stack of infrastructure protocols that allow us to then build applications on top  of it without highlighting them in the same way that the web does.  Very briefly here, philosophically, we have to distinguish a little bit between peer-to-peer,  peers and hosts and peers and posts.  People tend to conflate that you and it's not the same thing.  The host-oriented part of peer-to-peer is something that enables the human-centric part.  That's really all I want to say here if you want to look at the slides by Augusto.  I have to hurry up a little bit.  There's not so much time left in my lot.  It's a lot here.  I want to talk about what I've done so far in this and where the progress is.  There's a small library.  I'm skipping all of this.  It's just a platform abstraction library that I've been building along the way.  You can use it.  You can add to it.  It's not anything magic, but it's nice and small.  There's Packeteer, which is a Vend-based socket library.  There are plenty of similar projects out there.  The focus of them is a little bit different.  When I started this, which is a long time ago, it didn't really exist in quite this  way.  That's why I stuck with this.  I'm not saying you need to pick this for your projects, but that's what I'm going to  use going on.  Check it out.  There are some problems with it.  The Windows port works.  It's a little bit buggy.  I need to rewrite this a little bit when I have time.  The OZ part is fine, but it can use some cleaning up.  I would like to add a SketchRIO as much as possible.  It's really not very important right now, but it would enable slightly more high-performing  servers.  There are tweaks extensions that I want to add to it, but it's largely finished if you  want to play around with the Packet-oriented network protocol.  You can use this already.  Channel as the library I'm currently working on is very work in progress.  It's really trying to do a multi-channel protocol, much like the channels on HTTP3.2 as well.  The point is with P2P you have to maybe penetrate ads firewalls.  Once you've done that, you really want to stick with this one port combination to talk  to.  In order to then multiplex different data streams through this one connection, maybe  it's best to have the provisions for some kind of channels in the protocol so that it  gets easier.  That's what I'm working on there.  It's also a bit of an abstract protocol that is very ready for extensions.  One of the extensions I'm already thinking about is how to add encryption to this part  of the requirements.  I'm looking at doing it in more or less the same way as the WireGuard does.  There are problems with WireGuard in this context, but it really needs to fast-run the  discussion.  I'll skip over this.  There are also provisions and therefore adding the multi-link stuff that I'm doing with  NUI basically.  I want to add some channel-specific settings for how to deal with resins and reliability.  It's currently UDP-based because I want to be able to ship it in apps basically.  I want people to be able to build applications with it right now.  The way I'm working on it, it should be possible to run it directly on IP or on Ethernet.  This is not really necessary at the moment, but I'm sort of looking into a future here  where maybe that becomes interesting.  Maybe hopefully.  That's the whole point of the Next Generation Internet Initiative.  I'm sort of staying focused on this a little bit.  I spoke about multi-path, multi-link.  With NUI, we work on this as part of the Adacasa project.  I've prepared a paper that I need to finish in the next few days, actually.  That's focusing on the abstract protocol, the messages, the state machines.  It should be finished in draft this month.  I'll probably make a pre-print available and then it should be published sometime in the  middle of this year.  That's really the model that I want to use for channel-less multi-link support.  That's pretty much where we are.  I think for a year where I barely could work on it because of the pandemic, it's not actually  terribly bad.  At least that's what I try to tell myself here.  I want to salvage things.  The future.  Where do we go from here?  Let's assume that this problem of efficiently streaming data between peers is solved, which  will still take some time.  Including the multi-link part, including the multi-channel part.  We need something like a distributed hash table in order to find peers in the network.  I didn't put this on the slide, but we also need the whole NAT-nutrition thing, sort of  stun, turn, their implementations out there.  Maybe it's better to add them to the basic protocol so that it's not too much of a collection  of different things.  The next part that can be layered on top of the bare data streaming, if you want, is  to have a streaming protocol much like PPSPP.  That has two modes.  In order to access a resource that already exists that's finished, you can use a mercury  to identify specific parts of the resource and download them in order to complete your  picture that you have locally.  But there's also a streaming mode.  While some of the things in the specification don't really fit anything other than TCP at  the base, it has plenty of interesting ideas that can be adopted.  Lastly, I put here a distributed file system.  This goes back to simplicity.  I suspect that the API that most programmers will be most comfortable with is FileIO.  We have things like local sockets which are file-like in how they're presented, but actually  are streaming connections, if you want.  A file system like API, it shouldn't be exactly like a file system.  Maybe the solution for modeling how we access resources that belong to us, resources that  are on other machines, streams to other machines or the people who use them.  There is a precedent for this.  I'm very glad to know that it's gaining in popularity, that's the Plan 9 operating system.  It actually has a 9P protocol that is a remote file protocol.  It does nifty things like exposing the screen of your machine or a window or a map pointer  as a device that you can read from.  It makes using what the hardware provides very, very easy.  Maybe that's the direction you have to go.  It's a bit fuzzy, my mind is still something I have to think about a bit more, but I have  some ideas in that direction.  I'm already over time, which means the Q&A section is going to be a bit shorter, but  let's stick with this.  Quick note on how you can contribute.  Very easy.  I'm not very useful at something like presenting this project.  This talks the first, and I'm giving help with design and does design identity guides  is going to be appreciated if you are not technical.  Website and documentation templates would be appreciated because that's just not something  I'm very good at.  Any feedback you can give on the protocol work, so that means reading the papers, looking  at or just talking to me, that's going to be appreciated.  The project is relatively financed.  I'm not here standing asking for donations.  In fact, I'm not really set up to receive donations.  That's all taxable income for me.  But I would like to start a foundation or a nonprofit or a public interest company,  whatever works, so that we can accept donations and scale this up because one of the things  that would be very useful would be have a handful of developers to work on this full  time.  I'm not even managing to do full time myself right now, but that's sort of the thing I  would like to work towards in the next year.  If you have fundraising experience for this kind of thing, then yes, please.  That's the contribution I'm looking for the most in a way because that would allow me to  scale this thing up in the way that I think it should be.  And that's it with the Q&A section.  I just want to point out there's a website.  It's basically just a placeholder.  There's my email address.  You can send me an email.  I will try to respond at least.  The last URL is a blog where I talk about protocol design a little bit.  It's not massively large yet and very, very rare that I post something new, but it's there.  And now we're at 53 minutes and I have to stop.  Thank you.  Thank you.
humancentricinternet_0_179.png humancentricinternet_180_335.png humancentricinternet_336_383.png humancentricinternet_384_431.png humancentricinternet_432_503.png humancentricinternet_504_551.png humancentricinternet_552_599.png humancentricinternet_600_659.png humancentricinternet_660_707.png humancentricinternet_708_779.png humancentricinternet_780_839.png humancentricinternet_840_887.png humancentricinternet_888_935.png humancentricinternet_936_1103.png humancentricinternet_1104_1175.png humancentricinternet_1176_1691.png humancentricinternet_1692_3635.png humancentricinternet_3636_4307.png humancentricinternet_4308_6047.png humancentricinternet_6048_6563.png humancentricinternet_6564_6815.png humancentricinternet_6816_7391.png humancentricinternet_7392_8063.png humancentricinternet_8064_12659.png humancentricinternet_12660_14879.png humancentricinternet_14880_18587.png humancentricinternet_18588_19907.png humancentricinternet_19908_21719.png humancentricinternet_21720_22775.png humancentricinternet_22776_23039.png humancentricinternet_23040_23171.png humancentricinternet_23172_24539.png humancentricinternet_24540_26183.png humancentricinternet_26184_27935.png humancentricinternet_27936_29279.png humancentricinternet_29280_30707.png humancentricinternet_30708_30755.png humancentricinternet_30756_30983.png humancentricinternet_30984_31487.png humancentricinternet_31488_32099.png humancentricinternet_32100_35087.png humancentricinternet_35088_37775.png humancentricinternet_37776_40463.png humancentricinternet_40464_44183.png humancentricinternet_44184_44387.png humancentricinternet_44388_47783.png humancentricinternet_47784_50207.png humancentricinternet_50208_51863.png humancentricinternet_51864_52319.png humancentricinternet_52320_52415.png humancentricinternet_52416_52631.png humancentricinternet_52632_54551.png humancentricinternet_54552_55595.png humancentricinternet_55596_58247.png humancentricinternet_58248_58295.png humancentricinternet_58296_58523.png humancentricinternet_58524_60011.png humancentricinternet_60012_63431.png humancentricinternet_63432_64991.png humancentricinternet_64992_65483.png humancentricinternet_65484_65783.png humancentricinternet_65784_66095.png humancentricinternet_66096_66755.png humancentricinternet_66756_67751.png humancentricinternet_67752_70751.png humancentricinternet_70752_71615.png humancentricinternet_71616_71891.png humancentricinternet_71892_72107.png humancentricinternet_72108_76619.png humancentricinternet_76620_76667.png humancentricinternet_76668_76859.png humancentricinternet_76860_79271.png humancentricinternet_79272_79823.png humancentricinternet_79824_79943.png humancentricinternet_79944_80219.png humancentricinternet_80220_80345.png