FLOSS Weekly 701 Transcript

Please be advised this transcript is AI-generated and may not be word for word.
Time codes refer to the approximate times in the ad-supported version of the show.

Doc Searls (00:00:00):
This is Flos Weekly. I'm Doc Searls. This week, Simon FIPs and I talk with David P. Reed. David is the creator of Reed's Law. He was one of the founders of the internet itself in the sense that he came up with, with other people, but he was a main guy. The end to end principle, which is given really insufficient credit for where we are right now. Europe went in, I'm at another end. Any one of us could get on this thing. The internet is free and open and large measure because of that. And he's like the main guy. He's very, very, very smart. He's done a zillion things and very learned, and we learned a lot in this show. And that's coming up. Next.

Doc Searls (00:00:41):
Podcasts you love from people you trust. This is TWIT.

Doc Searls (00:00:49):
This is Flo Weekly episode 7 0 1, Recorded Wednesday, October 5th, 2022. Freedom and Scalable Cooperation. This episode of FLOSS Weekly is brought to you by New Relic. Use the data platform made for the curious. Right now you can get access to the whole New Relic platform and 100 gigabytes of data per month, Free forever. No credit card required. Sign up at New relic.com/flos. Hello again, everybody. Everywhere. I am Doc Searls, and this is FLOSS Weekly. I am joined this week by Simon FIPs himself, who for those who gonna have visually impaired, has appeared on the screen in his la in South Hampton. Are there other Hamptons <laugh>? There

Simon Phipps (00:01:41):
Are many, many. And,

Doc Searls (00:01:43):
And the name,

Simon Phipps (00:01:44):
The name has, the name has been mercilessly copied by the United States as well. And so you've got some, there's some place you have over there called Southampton, I believe, But yeah. Yeah. This is, this is the real one here,

Doc Searls (00:01:55):
I think. I think I've been to yours more than, more than the other one. I've driven through the other one to yeah.

Simon Phipps (00:02:03):
Yeah. We have the same problem with Port with Portland. Lots of people seem to think Portland is some place in America or in, you know, there's two of them apparently. But the real Portland is just down the coast.

Doc Searls (00:02:13):
Well, the, the I'm in Indiana where they've copied the, like, Columbus, Nashville. Lots of places that are elsewhere are also in Indiana. So <laugh>, it's Right, right. It's the replica state. I wanna get going here. So our guest is more, is David Reed. Are, are you familiar with David? I've known David a very long time. So

Simon Phipps (00:02:33):
You know, I, I know David by reputation, but I've never actually met him as far as I know. The photograph of him that I've seen is shockingly young. And I have to say,

Doc Searls (00:02:48):
And I have some of those too,

Simon Phipps (00:02:50):
<Laugh>, I, I, I'm, I'm very interested to find out why he is embarrassed to have designed udp. But so I, you know, I can't wait to

Doc Searls (00:03:01):
Talk really. Okay. Well, I, I wanna, I wanna get going on this because we're not, not opening with an ad, but David's whole resume is so long and wonderful. I'm just gonna start reading this cause I want everybody to know how, essentially an important David is, is he's Dr. David P. Reed been working 55 years at the forefront of computing and communications research and development. He's focused on designs for societal scale, computer and communication systems that manage, communicate, and manipulate information shared among people. By the way, among those <laugh> networks as the internet itself, notable contributions, he co-developed both the internet design principle known as the end to end argument that we are all ends here. One of the reasons is David came up with this idea. Some other folks along with David Smith, Allen k Andreas, Rob created crok and architecture based on the underlying con coordination of programmable systems in a highly distributed computing environment, based on replicated execution, also helped the original design and architecture of tcp i p, that's the internet folks and UD P I P protocols.

Doc Searls (00:04:08):
That is to lifelong interest in study stuff. We can talk about computing architectures, programming, language representation, network protocol, architectures and behavior, especially the internet, computational radio, networking, math and modeling of systems the algebra systems, the dynamics of systems, security of information sharing in networks and computer systems. Privacy of human users in complex programs systems as distinct from security. That's another distinction. We can go into anthropology of social system structures, protecting the openness of the internet and creating technology to open a wireless systems. He's the chief scientist currently at title scale, which he held found in 2012. Before that, he was a senior VP at SAP Research. I'm gonna go quickly through his, the mi at the mi t lead media lab. He led work in viral communications. He was a HP fellow at HP Labs. He goes all the way back to Viscal.

Doc Searls (00:05:04):
He worked at Lotus, began his career as a professor of computer science and engineering at mit. After receiving four degrees in w e in Cs from mit, he received the IP three award for seminal work on internet architecture. He served in the FCC commission on in the Technology Advisory Council and other groups advising he was government and policy issues. As a student, he worked at MIT's project Mac back in 1972. He connected with Richard Stallman, very relevant to us here in his first job at the MIT AI lab. And he witnessed the growth of the idea of free software from hiss birth and MIT to it, to what it is now. So, with all that, which is the most I've ever said about anybody, welcome to the show. David <laugh>. There he is.

David P. Reed (00:05:49):
Hi. That was so embarrassing, I have to say. But it's all true.

Doc Searls (00:05:57):
It's all true, <laugh>. So why don't we just start with, with end to end, because I think it, it, it's an argument most people haven't heard, even though they take advantage of it. And to me it's, it's, it's a miracle on the order of loaves and fish and possibly the most essential thing about the way the internet works and so clueless in, And I'll watch the back channel and see, and see what they're saying too.

David P. Reed (00:06:26):
Sure. so it's also a very misunderstood idea because so many people have picked up the phrase and put their own twist on it. So the basic idea is actually pretty simple for a, a computer designer or architect to understand, which is basically when you have a system how much functionality should you build into the system versus how much functionality should you let be created around it, essentially at the edges. And the end-to-end argument says that at least for communication systems, which have ends and, and so forth, you must resist at all costs. Putting functionality into the system that later will bite you. <Laugh>, that's a simple way to put it. It's there, it, there are more precise ways to say it. And we wrote a paper back in probably the paper got published in 1978 or so as I recall, or maybe accepted for publication, cuz in those days, publication took a long time.

David P. Reed (00:07:45):
What what it really meant in the, and the reason we coined it when we were designing the internet was that we had lots of arguments in, in the design process. There were, I don't know, at various times up to about 50 people involved in those early days at various institutions. And we met all the time. And we started from an idea by Surfing Con called the Transmission Control Protocol and gradually turned it into ip, tcp, udp, and a bunch of other protocol pieces. So what do you put in the network? The tradition up to that point was to put everything under the sun into the network put quality of service, put voice quality into the network, put, you know, so, so if you bought a telephone, really the features weren't in the telephone handset. The features were all in the switches that were very expensive, operated by Bell and so forth.

David P. Reed (00:09:00):
And that was the way Bell wanted it. The Bell system architecture was actually a very lovely architecture, but you couldn't change it. And they, by the time we started in 76 innovation was essentially impossible. Inside Bell Labs, they they took, I don't know, I think, I think it took 10 years to get touch tone dialing into the system. And even then it wasn't everywhere. And touch tone was the major technological advance of the bell system in the, you know, since World War II essentially. So we didn't want to get stuck in that trap. We also didn't know that the internet was gonna last a long time, but even then we were worried about getting stuck in that trap. So he said basically, let's not put anything into the internet design that we can think of a way to do from the edges.

David P. Reed (00:10:07):
And that's really the end in principle. Simple example. We use the idea in the internet all over the place that basically said reliability is done from the edges. You don't have to be very reliable in delivering packets in the network. So what happens is whenever you send a packet, you keep a copy if you intend to make sure that it gets there, and you wait for an acknowledgement and then you discard the copy. And if you don't get an acknowledgement quickly, you send the packet again and again until you get an acknowledgement for it. That's the, that's the edge based or end to end way to achieve reliability. That's not how the phone company did it at that point. And it's, it's really not a good idea or it's really not a well accepted idea in most of engineering even today.

David P. Reed (00:11:06):
Which is why it's a little bit controversial, although it works great. And so that's, that's what it was. We, Jerry Saltzer, who was my a professor, I was a graduate student at this time and I was the MIT representative on the design committee. Jerry Saltzer, who was my thesis advisor, but wasn't involved in this at all said, you have a really interesting pattern of arguing there. At the, at these internet design things, you keep coming up with this idea of leaving stuff out of the internet. So why don't we write a paper about it? Because it's not intuitive. So he had to come up with a name, he called it end to end arguments. It's not necessarily a well named idea, but it stuck. So,

Simon Phipps (00:12:00):
Hmm. That's, I, and it strikes me, it's kind of something we need back again cuz I, you know, I keep on I was talking with a, a colleague earlier today about how, how can we get the the, the centralizers out of the internet and and, and it, it seems that there is too much of a public acceptance that the internet does stuff rather than the internet connects you doing stuff to other people doing stuff. Right. I dunno how we, how we get that back again. That, that that instinct that it, we shouldn't be passive leaves on the ends of the branches. We should actually be the trunks reaching out to each other. Do, do you have any clue how we could get back to being decentralized again, given that it's, it, you know, everyone just failed with the blockchain and everyone just failed before that with email? Yeah. You know, is there any way, But is there a route back?

David P. Reed (00:12:57):
Oh, I, I, I, I think it's actually pretty straightforward, but it takes, it, it, because it involves undoing what seems to be an instinct of engineers and product designers and so forth to take control of the whole problem and solve it for everybody, <laugh>. And, and people really want, you know, whatever product they're using at the moment to do everything for them. So there's a very strong pull, but it's not a technical pull. So, so what we discovered and what it's possible to keep rediscovering if you pay attention to it, is that you don't need to put any of that stuff in the middle <laugh>, right? It's basically, you, you have to think hard about what problem you're really, what problem people need to serve, solve, and is there a way to solve it without changing the underlying relatively simple system? The I'll, I'll say something controversial cuz it's a, a good example of the problem.

David P. Reed (00:14:12):
Linux, which is a descendant of Unix, comes from a long tradition in operating system design of putting lots of functionality in the kernel <laugh> and building it in. And I think lately I'll, I'll, I'll, I'll take a strong position. Linux is reaching the end of its life, not because it isn't good, but because you can't innovate in Lennox anymore for a variety of reasons. It's, it's got to be centrally controlled. It's got way too much function in the kernel. The, that function has to stay in the kernel because if it didn't, a lot of things would break. But in, in a sense, it doesn't really need to be in the Lennox Colonel. So if somebody came along and said, We wanna design the next operating system, and it's not gonna have very much in it at all, right? It's not gonna do all those things that Lennox does.

David P. Reed (00:15:13):
We know how to do that. We know how to put file systems in user space. We know how to you know, do all the functionality in a way that we can replace it. We see that in our, our you know, in the distributions of Lennox. Now every distribution looks different and so forth, but but we've been pouring things into the, the kernel that really, in some sense don't need to be there. So the same thing with the worldwide web protocols, or for that matter, cryptocurrency. Ethereum is full of functionality that I, I cannot understand what it's there for other than to show off. Because you know, it's, it's locked in. You can't change what's in the Ethereum design. Yes, it's programmable, but there's a lot of stuff in the ethere design that can't be changed at all.

David P. Reed (00:16:20):
So if we're gonna think about, you know, what, what decentralization makes means decentralization requires applying the end to end principle. And sadly, the blockchain idea, which I think has lots of legs, has gotten converted into a centralized control system, even though it's physically distributed, there's only one center. You know, there's only one Ethereum blockchain. And so to me, you c you get that back since you asked how do you get it back? You get get it back by paying attention to the argument and say this, this is really important. Don't build functionality into a system. Let it be built outside it <laugh>

Doc Searls (00:17:17):
Wow. The, the, Okay, you just opened up a can of candy for us there, <laugh>. Sure. What's the opposite of worms? And and I know Simon has a question about that. Probably our back channel does too. But first I have to let everybody know that this episode of Last Weekly is brought you to you by New Relic. Those are some of the most curious people. The first to explore the newest tech, wanting to know how and why things work. That's why so many engineers turned to New Relic. New Relic gives you data about what you build and shows what's really happening in your software life cycle. It's a single place to see the data from your entire stack, so you don't have to look at a 16 different tools and make those connections manually. New Relic pinpoints issues down to the line of code so you know why the problems are happening and can resolve them quickly. Let's say more than 14,000 companies use New Relic when teams come together around data. It allows you to triage problems, be confident in decisions, and reduce the time needed to implement solutions using data, not opinions. Use the data platform made for the Curious Access, the whole New Relic platform, and 100 gigabytes of data per month, free forever, no credit card required. Sign up at new relic.com/FLOSS. That's N E W R E L I c.com/FLOSS new relic.com/flos.

Doc Searls (00:18:51):
So Simon <laugh>, which of those, Yeah, which of those candies do you wanna pick up first?

Simon Phipps (00:18:56):
Well, you know, the, the key question I've gotta ask just thinking about that, David, is is the problem then that we have let things be too democratic because it's the democratic openness of the Lennox Nel that has led to people putting in their fishing gear as well as the kitchen sink. And I, I think part of the reason why that process has happened is that if you insist on the end to end principle, the people who have got the most market power at the ends are people who will make things closed. So how could we go to a future where the end to end principle reigns the internet application space without basically handing control over to Microsoft or Facebook or Google?

David P. Reed (00:19:47):
Well I think modularity is the key. The, the, you know, in the operating system research world Linux, like many other operating systems is called a monolithic kernel system. Meaning there's just one one kernel. It's a huge body of source code. It's got the drivers for every known piece of hardware on the planet in the source code. You know, it's, it's all of that. And to some extent, you know, things go through cycles. The, the, by keeping it coherent, keeping it a single module, keeping this tiny band of, of what are they called? They're not maintainers, but the folks who sign off on patches

Simon Phipps (00:20:44):
Committers

David P. Reed (00:20:44):
Committers or yeah, Tiny Band of Committers. On top you end up with what you might call quality control, one kind of quality control, but you also create a huge bottleneck for experimentation and innovation. I actually have spent a lot of time building variance of the kernel myself with my own code in it. I've even submitted a few patches over the years, although that's not my primary goal in life. The I, I have to say, if you're a casual innovator or someone who's working outside the, the inner circle of the Linux kernel, now you, you basically can't get anything into the kernel without spending a huge amount of your life on getting the patch cleaned up and accepted. Now, I don't think that's wrong. But, you know, there's, there's an alternative, which is to say, Okay, is there a way we can modularize the ker so that this option doesn't have to be part of the colonel?

David P. Reed (00:22:04):
Right. And you know, and the a a big example that would be a nice step away is making it so that you don't have to get all the drivers into the ker for every piece of hardware. Kernel itself is fairly small the kernel main code, but the drivers are, you know, 99.8% of, of the code in the nel. And you know, really, you know, there's a lot of talent that's created that code. But the structure, very architectural structure, not the, not the sociological structure is the problem there. I, I don't really know what that project would involve. I know what I would do if, if I started, if I started from scratch to create a, a new Colonel <laugh>. I, I certainly keep the, you know, the Kernel API the same which has been a good thing about Linux.

David P. Reed (00:23:21):
But I would make it a lot easier to add fun to, to experiment with functionality and to put functionality together in a loose way. It's, it's doable. Just few people have time to do it. The other, the other thing by the way, which I'll just observe, this is me as an outsider critiquing it, but I do, I do work on hardcore operating system, actual vir virtual machine level stuff in my, in the job in that I have with my the company that we founded. So we actually write code that runs underneath the Linux Nel, so we know a whole lot about it. And who writes it? <Laugh>? Most of the Linux Nel is being written by a, by coders at a small number of semiconductor companies. I, it's my, my, that's my impression the, you know, or Google or Microsoft. Now if you look at who's the, who the contributors are, they work for AMD, Intel, you know, all of all of those companies. And I understand why they do. But that amount of money also makes it hard to you know, actually HP did a lot of work on lots of Linux also and still does, I think. But that amount of money drives what direction that Colonel takes. And I think, you know, I would first start by not having those guys in charge <laugh>. 

Simon Phipps (00:25:18):
Yeah, I, I buy that, that, that, you know, so I'm spending quite a lot of my life at Etsy here in Europe. And, you know, I would love those guys not to be in charge. So I observe that for end to end to work in the new internet, we have to have more standardization because putting your fishing tackle and your lunchbox in with the sink in the kernel is all a response to not having standardization for for multiple implementation outside the colonel. And yet I observe that the world of standardization has been utterly corrupted by, so by standard essential patents does, Yeah. Do you, do you think that, do you think that end to end can, could work in a world where standards essential patents exist? Or, or is, is that a show stopper?

David P. Reed (00:26:07):
Oh, patents. <Laugh> happy to switch to patents if you want. I've been involved with the question of what to do about patents, you know, forever <laugh>. Since, since software, basically, since soft patents, software patents were allowed to be issued in fact, I, I got involved in opposing the very first software patent that was issued when I worked for Lotus. Because that patent was basically on algorithms for recomputing sets of formulas that depended on each other. The algorithm was basically an implementation of something called topological sort, which, you know, I happen to know because I did the research for it. Was originally invented about 1934 in a, you know, in, in service of mathematics. And was well documented in 1934, long before there were computers. But applying that algorithm to computers was patented by a, a company.

David P. Reed (00:27:26):
And then someone bought that, or I don't know who, who originally patented it, but it was bought up by a company that was a patent troll. And they came to Lotus in, or or mid eighties and filed lawsuit against us. It turned out they lost, but they didn't really lose because it was un patentable at the time. They lost for other reasons. The, I have, I, I'm not against totally against patents, i, I them, but you know, you can fix, there are a lot of things you can fix about patents, and I don't really want to go into that cuz I'm not a, a patent lawyer. But I do think that standards and patents are absolutely opposed to each other. Every, I believe every communications protocol needs to have example code that works <laugh> that implements it so that other people can implement the other ends of the communication protocol.

David P. Reed (00:28:39):
And the best way to do that is with some reasonably high level code that implements a version of it. So you can test the if you, if you make a patented thing, the test of compatibility in a standard you're basically fighting the US us usability of the standard. So if you want something to, you know, this is like open source. If you want something to be proprietary and secret, by all means, you know, do that. But recognize nobody's gonna talk to you in the communications world. Nobody's gonna build that connects with you. And you know, they, the other drawback about patents is that if you've patented something that works okay for some function, you actually are preventing other people from achieving that function even other ways. If it's too much like the original, then mm-hmm. <Affirmative>. So, you know, it's a complete public policy disaster if you expect innovation to happen. We have to live with that. Now. Fortunately, there's only one I e t i, I believe there's only one I ETF protocol that depends on a patent that is being a patent that's being enforced by the owner of the patent. That's very sad to me because it's actually a good idea. But but you can't use that protocol except in certain ways which is, you know, I ETF's fault, I think <laugh>, but

Simon Phipps (00:30:36):
I always thought I ETF did a pretty good job of keeping the patents out personally, but I'm, they didn't have, So, so this is the, so this is a, at the moment for, for my sense, part of my day job is going and dealing with standards and patents. And there's another, you know, doc doesn't want the show to be about AV one and and CodeDX, but there's another war just about to break out because the cartel of telecommunications companies is busy trying to enforce patents against a royalty free Kodak called AV one. And they seem to have somehow bought their way into the European Commission to back the, the battle that's going on there. But this is, this is what makes me a deep skeptic about standards as a whole these days. Unfortunately, David, you know, I, I have very much somebody who is I I I, I go for the running code part of the the, the, the deal. I'm not even worried about the rough consensus anymore. I just want to see the running code now. Do you think that that standards really have got a viable contribution to make to the future of an open internet? Or do you think we should just leave that behind and let consensus around code drive our, our progress forward?

David P. Reed (00:31:55):
Well, I, I think you can have standards and consensus <laugh>, right? And, and what I mean by that is we've forgotten that, that the point of standards is largely for interoperability so that you can connect things together, especially in communications. But, but you know, the patents on screw thread sizes you know, would be a bad idea. Standards on screws, thread sizes are great, right? Everybody knows what an M three, well, outside America, everybody knows what an M three screw is. But what, what we forget is that there's standards and then there's standards mandating processes standards organizations. So ITU sometimes is called a standards organization, the International Telecommunications Union. But they're not they're a government organization that makes rules. And those rules are codified as standards, but they're mandatory in most countries. And so there, it's a power center.

David P. Reed (00:33:18):
One of the things that's going on now with respect to the internet is an interesting, I I think it's interesting as, as as we'll see, there's a, a group at it that is saying, Wouldn't it be great if we mandated improved version of the internet standards as part of the, it it use function? And the reason for doing this, they argue, or at least the surface reason, is so that more countries will be able to have the internet. It'll be, you know, it's like arguing for, you know, rural fiber or something <laugh>. That's what it sounds like, but it's important to know. Two things about itu, and this is true of many standards organizations. Not all ITU is run by delegates. The delegates are, have to be part nominated by the governments of the countries in the world that participate in the itu, which is basically the un.

David P. Reed (00:34:27):
And they get decide. So the question here, and, and for example in the us I'll just, cuz I don't really know the process in the uk or, or in Africa for that matter. But in the us the person who represents the US and the ITU is works for the Department of State is a state department, essentially an ambassador, but without all the Ambassador Aerial Bowers. So it works for the US government. Whether that's bad or good, the point is that what you're seeing in the, it is an implementation of government policies. Do we need government policies for all communication standards? I don't think so. And that's really what I, what I'd argue that if I were to I, I, there's a great quote and it's usually just a joke, which is the wonderful thing about standards is that there are so many of them to choose from.

David P. Reed (00:35:39):
So that's actually an important idea. You want there to be many standards to choose from, and you want to be free to choose. It's another kind of freedom. It's freedom to cooperate with other people at the end. So it's supplying the end to end principle to standards. So there's nothing wrong with a standard. And it's great when a group of people work on a standard, but if they have the power to impose it, that becomes a problem. And so I, ETF has been fighting, although it doesn't fight it so hard anymore, the idea that they mandate standards the reason they'd fight it is because they don't want some government coming to them and saying, We want you to put this in the standard to apply to all the world. Right? They just don't want that role. But it's also really important independent of, of being just a, you know, a pain in the ass to governments <laugh>.

David P. Reed (00:36:44):
You know, it's important because it creates the opportunity for alternative standards. So like to coexist. So we now have the case that, you know, there are alternatives to tcp whether they're good or not. If enough people implement them, we might stop using tcp, right? It's kind of the question is to improve TCP or just replace functionally with something better. The we are, we're seeing people work on replacing http, which currently is built on top of TCP with a protocol called Quick Q U I C that runs on top of udp <laugh> Google is, is sort of spearheading that. But there's lots of folks who would like to see that succeed. I'd like to see it succeed, but I'm a little worried that they're pushing it out so fast and with so much force that they're gonna push out something that doesn't work very well in the long run. But but I'd love to see it succeed. I couldn't really, yeah, I've had discussions with the people who are designing it and said, Why don't you just do a little bit at a time? And they're not really interested in that <laugh>. You know, so it may happen before it's time, but, or, or it may suffer from some serious flaws, but the nice thing about it is you can do that. 

Doc Searls (00:38:26):
Wow, there, there's, there's a lot to cover here. And I actually have one more sort of a question about a standard and a kind of a tactic. But first, after I bring it back up on my screen, <laugh>, to let everybody know that about Club twi like Club TWI is another great way to support our network the TWI network as a member, you'll get access to ad free versions of all the shows on TWI, as well as other great benefits. There's a bonus TWI plus feed, which includes footage and discussions that didn't make the final show edit, as well as bonus shows that we've started, such as the GI fizz, Ask Me Any Things and Fireside chats. And those are with some of your favorite TWIT guests and co-hosts ass weekly listeners, you may be interested in checking out the Untitled Linux show. That's with Jonathan Bennett, or on Jonathan Bennett. The show is available only to Club TWI members. And it's a really great show that's on, I think on Saturday, but it, it's just awesome. So you ought to check that out. So sign up and join Club Twit for just $7 a month@overtotwit.Tv slash club twi and join today. We thank you for your support.

Doc Searls (00:39:40):
So David, in couple of metaphors occur to me. One, one is familiar to everybody, which is a green field, you know, try and go for someplace that isn't developed yet. And but there's another one which is red ocean and Blue Ocean. The red ocean is where everybody's fighting it out, and the blue ocean is where nobody's fighting it out, and it's not bloody yet. And it seems to me in the forgottenness that has fallen upon end to end if it was, wasn't remembered in the first place. The, the miraculous nature of it that, I mean to me, I mean, somehow T C P I P and HTTP as well kind of got rolled into the phone companies and the cable companies like a Trojan horse and, you know, and took over the world and they fought it, but then they had to make money with it.

Doc Searls (00:40:27):
And they, they're all adjusted to it now. But there's a you and I have worked on a standard which I'll promote here because it's, I think it's a great idea that you were the chairman of the, of, of this one which is the I e p 7 0 1 2 for machine readable personal privacy terms. And the cool thing about that is that it starts with imagining that, wait a minute, we don't have to always agree to the other parties terms, why aren't they agreed to our terms? And I think the reason is that we sort of decided in a, in some sense, you know, in 1995 when it was easy that we're gonna go with client server as an architecture, which is really a mainframe idea and which might as well be called Slave Master. We're always a slave, we're always the surfs and somebody's futal castle.

Doc Searls (00:41:21):
And it's hardly thinkable that we can assert our own terms. But the interesting thing is, every time I bring it up with somebody, including lawyers, not a lawyer brought it up with, yet, it doesn't say that's a good idea. But we did a standard there and I'm wondering if, you know Simon shared in the back channel at and, and xk cd cartoon about, you know, we've got 14 standards, we need a new standard to rule them all, and now we have 15 competing standards. But I think this is an area where working from the end side rather than the middle or the wannabe middles, they're the other, they're the other end, but we're always like slaves to the other end. Whether that's a greenfield or that's the blue ocean that where we, where we wanna work, or is, or is that everything just takes a long time and we're just kind of stuck. I don't know. Well, what do

David P. Reed (00:42:10):
You think? Yeah, I, I, so I don't think there's like, so if, if something is working badly today and yet it's working <laugh>, right? It's, it's like the, the client server model of, of the web you trying to get in the middle of it is really hard. But this is where a, a new standard can help. And I have a couple thoughts about, about that particular umer, you know, observation, a new standard can help once you get a set of people who will use that standard to solve their problem, whatever their problem is. So you need, you need that kind of blue ocean to get started. And, but once you demonstrate the utility of that standard, you can get people to adopt it. You know, you can get institutions to adopt it for the reasons that make it better. You're not gonna get, for example, Google anytime soon to change from being a client server, you know, company.

David P. Reed (00:43:28):
That's where it gets all its business from. It's, it would cost way too much and it would risk getting competitors that would, you know, that they don't want <laugh> New Start. Competitors are not what any company wants. So how do you, how do you do something like that? Well, first of all, the internet is a great place for a blue ocean. It turns out that the basic technology that we designed in 19 75, 76, 77 is basically still the same. If you drop a, you know, UDP packet into the network, it gets to the other end pretty much untouched just the way you wanted it to. You don't have to use the DNS if you don't want to. So you can use some other naming system. You could even use the DNS I've pointed out to people. You could even use the DNS protocol without the DNS route.

David P. Reed (00:44:33):
But you have to get that started somehow. You have to get other people to decide to start using it. So you could basically invent any protocol you like and use the current internet to provide service today anyway. We're seeing places like the great firewall of China and the Russian attempt to shut itself off working to try to make it impossible to send packets that aren't authorized before they got sent. Were impossible to send packets to unauthorized destinations. But so far that's not a problem. So if you wanna start a project to create a better protocol or framework, you know, there's no technical barrier. There are some legal barriers that you'll run into because the governments and private parties are aware of what game you might be playing. So they're, they're gonna oppose it if they see it as being threatening in the long term.

David P. Reed (00:45:43):
The reason the phone companies and telecom companies couldn't stop the internet was a really deep design assumption that people don't understand. It's kind of the, the other key thing of the internet, which is that the internet is entirely an overlay network. It was intentionally an overlay network. And the reason that's an overlay network is because that isolates it from the low level technologies. Anything that can deliver a packet and transfer a packet to another network and, you know, can be part of the internet. So it's not, it doesn't have to run on ethernet, it doesn't have to run on phone lines cetera. It ran on dial up phone lines in the old days. We don't use those so much anymore. But the internet is an overlay network. A a key thing is that the internet that we operate today is also an overlay overlay network.

David P. Reed (00:46:51):
So if somebody tries to stop you from sending packets, somehow you can send them over a TCP connection like you do with Tour Tour. I don't, I don't remember whether Tour now uses tcp, but it uses a bunch of underlying connections and then sends the packets that you wanna send through that Overlaying, overlaying is not as well known as the end end argument as a foundation of the internet. But it is, and it's another thing that engineers forget about because engineers try to get efficiency and obviously it's less efficient to send packets as an overlay on top of some other network. It's like, oh, that underlying network doesn't really need to be there. So the hardware guys, if you put them in charge, will try to make something that runs the internet protocol as kind of native on top of the bare metal system.

David P. Reed (00:47:55):
And when they try to do that it generally either doesn't work very well or it doesn't, or it doesn't last in the market because technology's in the internet world are changing. So they've done the mistake that the end to end argument warn against of building some particular functionality into the hardware. You know, in the functionality of the format of an internet packet or you know, how TCP decides to acknowledge messages these days or something, They say, Oh, we can optimize that by building it into the hardware. But as long as you can get bits from one end to the other and create markers around the packets, you can overlay that network. So I don't see any problem with there being a Blue Ocean opportunity in the internet. So why, why doesn't it happen that much? Well, you have to find people who want it, so who want the new capability so much that they're not willing to, you know, be stuck in the old space.

David P. Reed (00:49:12):
And that's really where the internet beat the phone company. Basically. People didn't want what the phone company was selling. They didn't want, you know, you know, low bit rate voice or or no, you know, or not to have Zoom or you know, cuz phone company couldn't figure out how to new teleconferencing in it's hardware. You know, people wanted something else. So my observation is if you have a really good idea about how to make a better networking environment that scales up to the size of the planet, which you know, is really what say the worldwide web did it's kind of a build it and it will come argument. You can build it because the internet, at least today is wide open for you to, you know, at least overlay on top of it. But you have to have something that they want to do that's different. You don't just polish the, the brass on the existing system. So I think, I think, you know, the great thing is that we're still free to imagine and even build something like this. It's gonna be slow because the early adopters will be few no matter what, right? Mm. But there won't be so few because the internet is really big now, <laugh>, Right? You don't have to have the all living in the same building. Right? So,

Simon Phipps (00:50:49):
You know,

David P. Reed (00:50:49):
I'm optimistic in

Simon Phipps (00:50:51):
<Laugh>. I I'm quite struck by the, the overlay thought that you've got there. I I was just reflecting on the existence of RFC 1149, which is da datagrams over carrier billions. And just reflecting on the, the way that many of the things that have changed the way we use the internet now, were actually exactly that inefficient overlay going on. I remember when YouTube first came along wondering why on earth anyone would want to play video over a 2,400 ball modem. And it was, it was that work overlaying video over the top of T C P I P that pioneered a basically an entirely new industry and unfortunately corrupted everyone into, into thinking that the internet was a medium for television. Right. I, I wanted, so, so having, having laid that to rest, David, I've been fascinated the entire time since I found that I was gonna be talking to you to find out why you are embarrassed to be recognized as the designer of udp because I would've thought that was a, a great thing to to, to have on the back of your business card

David P. Reed (00:52:05):
<Laugh>. Well I, it turns out that a lot of people still do in various ways credit me with that and I don't have to do anything about it. A lot of people say I'm the main cause of the slash between TCP and ip, but which I was there, but I wouldn't say I was personally the main cause I was just one of the, the people who fought for it. I don't believe in the great man theory of history to use a short term for this. Ideas are in the air there, often invented many by many people in many places. I can't always say where, where I got the idea I had or even claim much credit for, you know, deciding, you know, for making the decision. So that's what embarrasses me about you know, this, I, I am, and, and the, I guess the other part of it is that UDP is actually the only thing UDP does besides the base level ip, which delivers datagrams, is it provides an extra level of addressing that allows a single host to dispatch, you know, the packets to, you know, whoever, whichever process running on the host wants it or whichever program.

David P. Reed (00:53:39):
So that dispatching, you know, that seemed, you know, that function was already in tcp it's the only thing that UDP took from TCP was the port number idea. And so I didn't think it was much of an invention. What, what I'll, I'll tell you the way it really, you know, sort of really went down, there was a meeting we finally, you know, got a consensus in the group that we were going to split TCP into two layers, TCP and ip. And those of us who were fighting for that split, really for a variety of reasons, wanted to be able to send individual datagrams without sending connections. So we needed a connectionless protocol. The word connection list doesn't appear in the rfc, which is funny, but that's really what we were arguing for, was the ability to just send a message without any guarantee it would get there.

David P. Reed (00:54:38):
And, you know, and basically push all the other functions in out to the end, right? Figuring out who to send it to and all that kind of stuff. Handle reliability, handle security, all gets pushed out to the edge. So we had to have a name for that. And we called it the user data grant protocol cause Datagrams aren't connectionless. And you know, I, I think I might have chosen the name maybe <laugh>, but you know, the bigger, the bigger argument was not, you know, was, was a bigger argument. Much, much less than, you know, if you look at the, the spec, it's a little bigger than it originally was, but it basically was saying, well, we'll have this header on it and a check sum that and the header will have the additional addressing information and the check sum is optional in case we knew figured out a better way to do a check sum. So even the optionality of the check sum was, was kind of throwing function out of the network.

Doc Searls (00:55:54):
Yeah. Well we're, we are getting down toward the end of the show which started late, so we were ending late too. You, we touched on, on blockchain earlier, and one of the things you've, you've said is that blockchain is neither democratic nor decentralized or distributed. And those things, those two words, decentralized, mean different things. Paul Barron explained that in 1964, but I think most people today still don't understand. So I'm wondering if you wanna, we only have a short time to talk about this, but if you wanna visit that at all, because I think blockchain is sort of like, Hey, we've got a solution as blockchain. Is that, I dunno.

David P. Reed (00:56:35):
Yeah, so blockchain, the original blockchain that was part of Bitcoin that Sotoshi put together actually was the, the, the Bitcoin system was a bunch of independent ideas that sort of came out of well known ideas. The, the blockchain part was basically came out of a lot of work historically about replicating a database, maintaining a replicated database and doing so in a, you know, an environment that's hostile. So there was a, there's a classic program called the Byzantine General's problem that computer distributed systems theorists have worked on, which is how do you, how do you cooperate with a bunch of good guys if there are some bad guys in the mix, right? And basically the Byzantine General's problem is solved to the extent that it's fully solved by voting. So it's basically, you've gotta have at least a majority, you know, one more than 50% vote.

David P. Reed (00:57:49):
And that guarantees there's no one else who has more than a 50% vote because it can only be one more than 50% agreement. So blockchain is basically, you know, the idea of open replication. So he can have any number of replicas and some way of controlling two things. One, one who's allowed to be a decider and you know, and how to deal with bad deciders, you know, to cheaters or whatever. So, you know, there's a whole bunch of protocols that solve that problem. There are some subsidiary problems that, that are not solved by blockchains or the other solutions. So it's a great, it's a great idea. It's not particularly decentralized in the sense that it creates a centralized power structure. It's a voting based one. So it's like, okay, the, you know, country has a central power structure, it's based on voting, so it includes more players and it's also a bit more resilient.

David P. Reed (00:59:07):
Blockchain is more about resilient. So, so I think there's some good stuff there. It doesn't decentralize power in any meaningful sense. So decentralized power would basically allow, for example groups to split off and maintain the common history, you know, and separate <laugh> fork off in many directions, for example. How that would apply out in the money domain, I don't quite know, but but in the domain of other kinds of data, it's pretty important. So I, I think replicated data is a good idea. There are lots of ways to replicate data. The voting mechanism is awkward because how does, how do you know that some guy is who comes in and says, I have a right to vote is actually a legitimate voter or a, you know, a fraud. So there are lots of holes in that.

David P. Reed (01:00:11):
And so I'd like to see that worked on more before it's declared the solution. And you know, I think the real problem to solve at the higher level, what attracts people to blockchain, the more libertarian folks and so forth, is how do you cooperate as a group without getting controlled by some subgroup, Right? That's, that's the problem with centralized power. And, and it's the problem with centralized power, even in a technical system. You, if you have only one subgroup, you know, how, how do you get resiliency if people, you know, if entities die in that machine subgroup or if you forget things. So to me it remains very interesting. It's very sad to me that cryptocurrency came to be the center of that, and there's a reason that it was there. Because the other problem with these replicated databases that are permanent is you want to keep them around forever because they document history. Yeah, right? You need it to be valuable. And that was, that's the problem with most of the blockchain without a coin, you know, <laugh>, it needs to be valuable and remain valuable forever. <Laugh>, right? <Laugh>. So it remains res needs to be valuable to someone who's gonna keep, you know, keep the records. You know, maybe that's one entity, maybe it's the government, maybe it's a, a bank, you know, but some entity has to really care or else nearly everybody has to care <laugh>, right? Or you're not gonna keep the old.

Doc Searls (01:02:03):
That's, I think, I think the idea was that it would be, it would be everybody. But we are gonna have to leave that question because we are more than out of time. We always end with two quick, quick questions, David, and they're trivial but fun. One is, what is your favorite text editor and the other is your favorite scripting language, if you have those? My

David P. Reed (01:02:25):
Favorite text editor, I, I, I don't know if it's a favorite, but it's the one that I grew up with and the one I reach for is emax. I, I owe that to Richard Toman indirectly actually John, John White and Richard Stallman since John created the infrastructure in Tico for it. But yeah, <laugh>. 

Doc Searls (01:02:50):
And do you have any scripting

David P. Reed (01:02:51):
Language, favorite scripting language? Lately I'm, it's kind of a toss up. I use Python a lot but I don't like it that much. And I think the emerging scripting language is JavaScript. I actually think it would re if it had ev all the libraries that Python had, I would stop using Python except for existing code bases that have Python, so.

Doc Searls (01:03:27):
Well that's, that's good for a lot of future arguments. So this has been fabulous. I think we gave it more than an hour. Thanks so much, David. It's been great having you on the show. Sure. And we will have to have you back to remind us of things <laugh>. So I think that's great. Excellent at that. Thanks, David.

David P. Reed (01:03:45):
Okay,

Doc Searls (01:03:45):
Great. Simon, thank

David P. Reed (01:03:46):
You for,

Doc Searls (01:03:49):
So Simon <laugh>, how's that for you, man?

Simon Phipps (01:03:55):
You know, interesting to, to explore those things and I, I would love to dig in more into you know, the, the principle thinking behind some of the designs that, that David has done. I, you know, I think that the, there's a, there's a timelessness to the end to end principle. I think that overlay principle needs equally needs a paper written about it. Because I actually think that the, one of your, your, your indicators of a future innovation is where somebody doesn't a network overlay like that, that seems completely irrational and ideological. And it's, each time I've seen it happen, it's been a a, a warn or a signal that there is something revolutionary coming in the future when the network speed or the process of power takes away the obvious disadvantages of overlaying that thing over. The other thing, just like, you know, seeing that in video on the internet you could see if you looked past the fact that it was running over a 2,400 bull modem and said, What, what would it would be like if this was running over fiber optic and what would it be like if it was running on a computer that wasn't slow?

Simon Phipps (01:05:05):
Suddenly you realize that there's a massive power involved in that technique. And I think that overlay principle actually is, is there's a lot of thinking to do there. You know, it's if being over overlap makes something safe against being taken over by the underlying infrastructure. So I, I want, I want to go and have more of those conversations, you know, I

Doc Searls (01:05:28):
Want Yeah, I do, I do too to,

Simon Phipps (01:05:29):
For alcoholic beverages and have discussions about them.

Doc Searls (01:05:32):
Yeah, that's, that'd be a better way to do it. I, I hadn't thought of the overlay thing before. To me, it's just miraculous that there were all these lands and WANs and phone companies and cable companies and universities and, and, you know, collections of computers connected in various ways. And this one protocol suddenly, and I guess it wasn't overlay, it was less, it was more like, Hey, everybody use this. And it was just so freaking useful. Nobody could stop it. And, and then it, it, it went from there. And I keep hoping for effects like that, but o overlaying is a really good way to, to look at it. So because we're over time I know you wanna plug something, so I do go for that.

Simon Phipps (01:06:19):
So I'm, I'm very concerned by the various political regimes around the world. And we don't talk politics on this show, so I normally get shut down when I talk about it. But there are people who would love to use the internet and in order to be able to use the internet, they need to be able to gain access to tour. And their repress governments have worked out. That's how they're going to gain access to the internet. And so the tour folks have created something that lets ordinary people like you and me help those people gain access to the internet. It's called Snowflake, and it is a plug-in for Far Fox or Chrome that puts a little Purple Snowflake up on your toolbar. And all the time that Purple Snowflake is visible. People who are struggling to get access to the internet in repressive regimes are being assisted to do so by using you as a proxy entry point onto the, to network at no risk to you at, there's no way that you, that your system is compromised by it. But just by having that icon sitting up on the toolbar, you are helping somebody in a place like Iran gain access to the internet through the Tour Network. So I'd like to ask everybody who's listening to the show, watching the show this week to go to snowflake.to project.org and have a read and then install that Chrome or Far Fox plugin and help people all over the world retain access to the free internet. And that's my plug this

Doc Searls (01:07:49):
Week. That's great. So my plug is for next week. We have John Murk on John Rean in the past. He's great and we say we'll have people back. We mean it sometimes. <Laugh>, usually always. And as, Anyway, that's coming up next week. John Burtick and Jonathan Bennett's gonna be the co-host and I will be in quarterly Idaho, where I'm gonna need a place to do the show. I don't have one yet, so cuz where I'm staying has no connectivity, so I'm working on that too. So it'll be a surprise wherever I am next week. And we will see you then Doc Earls plus week. We see you next week.

Ant Pruitt  (01:08:29):
Hey, what's going on everybody? I am at Pruitt and I am the host of Hands On Photography here on TWI tv. I know you got yourself a fancy smartphone. You got yourself a fancy camera, but your pictures are still lacking. Can't quite figure out what the heck shutter speed means. Watch my show. I got you covered. Want to know more about just the I ISO and Exposure Triangle in general? Yeah, I got you covered. Or if you got all of that down, you want to get into lighting, you know, making things look better by changing the lights around you. I got you covered on that too. So check us out each and every Thursday here in the network. Go to twit.Tv/Hop and subscribe today.