Upspin and a future of the 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.
Chabot, Gildas
by At: FOSDEM 2018 Room: H.1308 (Rolin) Scheduled start: 2018-02-03
 Hi. Thank you. I'm very pleased to talk today. So, in such a great room, there is so many people waiting outside. It's really an honor. Thank you to Frances for making this possible. Today, I will talk about a project I really like, and I think that can change the way we use the Internet. Before that, just a quick word of introduction about myself. So, my name is Gilles Dachabot. I'm working in Paris for a big French website called Le Bon Coin. We are doing Go there, but we're not... This talk is really not about what I'm doing there. So, just a quick overview of what we'll talk about. So, the project I will talk to you about is UBSPIN. First of all, why are you talking about UBSPIN? Why does UBSPIN exist right now? Then, we'll have an overview of how it's working, and then we'll see what we can do in practice with it, just as a regular user or as a Go developer, and then we'll have a quick conclusion. So, why UBSPIN? So, UBSPIN is the new project from Rob Pike. I guess most of you know who Rob Pike is, but maybe not all of you. He's the husband of René French, the creator of the GoFer. So, last year, there was two posts about UBSPIN. The first one was published on the Google Security blog last February, introducing the concept. And then in last October, there was the original manifesto that Rob Pike wrote eight years ago. And that's where I heard about it, and that's where I found in love with that project. So, the reason behind UBSPIN really is the information silo architecture that we've fallen into slowly. The premise of the modern world, of the modern web was remixability and creativity, but actually, we have been moved into databases that we cannot access and that we cannot control. We have become dependent on the apps of the storage providers that we use, and we are really dependent on what these people are willing to offer us. I think we have lost quite a lot along the way, just to quote a few ones. I think we should be able to use our data with any apps that we want, especially the one that we developed, for example. And I think it should be very simple to share any kind of data with anybody we want. It's funny for me to think that it's not easy, like to just create a public website just from a note that you have on Evernote or anywhere, and from a couple of Google photos or something like that. I think it should be trivial. Another problem with that is the actual apps. Developing something like Google Photo is really something complicated, and yet every new storage provider is trying to redo the same photo viewer and this kind of thing, and I expect them to fail because they don't have the years of development of Google Photo, for example. Storage and application should be two different businesses, and we should keep them separated. So the model that UBSPIN is pushing is a model with data at its core, and the apps are just coming next. The apps are just like regular users playing with data, reading and writing to it. It's by no means a new approach. It's exactly what a local file system is, but it's something that we've never truly had in remote systems, and it's something that is being taken away, for example, on the mobile devices. So the two basics that UBSPIN is offering is universal naming and access rights. So every file has a global identifier that you don't need to worry about sharing with other people. So it starts with the mail of the person that owns that file, and then it's just a regular Unix-like path. And the access control about it is really something, is another thing that comes with UBSPIN and that you should consider solved and stop wondering about. So let's have an overview of how it actually works. The most important thing about UBSPIN is actually the protocol, and as you would expect coming from Rob Pike, it's very simple. So it's just three interfaces for a total of 11 methods, and that's really all you need to know for building any system that works with the rest of the UBSPIN world. Still, there is a need for a proof of concept for reference implementation, and that's exactly what the UBSPIN team has been doing for the past years. So there is a reference implementation for all the clients and servers, and also there is a collection of tools that add some functionalities, some of the basic functionalities to UBSPIN. So UBSPIN is really built around Go, and the best reference is actually the Go code, and for the definition of the protocols, it's basically the interfaces from the UBSPIN protocol. So very quickly, so the key server is just looking up and updating user information, and the store server is basically the same thing, but with data. The DR director is a bit more complicated. I won't go through all of them, but it's basically that's where the solving of the global name is done, and then you have some other functions. So for example, if you need to develop, well, basically for the global use, you don't really need to know how it's happening behind, what is happening behind, but for example, if you are making a server from scratch, then you will really need to know how it works behind. So let's quickly see how we can get a file, for example. So the first step is with the key server. So you do a lookup for the user, and what you get in exchange is just the user public key and the directory server address. So that's for the user part, then the next part will be the lookup of the file. So then at that point, the previous key server is just one key server for the whole UBSPIN, so that's a known address, key.UBSPIN.IO. But then here you are contacting the directory server of the user, the information that you had just previously. Looking up a file will give you back his name, his metadata, and references, and store server addresses. That's actually where the first access control is checked. The directory server, at least in the reference implementation, will check that you have rights to ask for the store references. And then you can just get the reference. So most of the time it's just a hash, and then the store will just give you back bytes. Most of the time these bytes will be encrypted. So you need to have the key, and you'll have the key only if you can access this file. Another example, for example, listing a directory. This is an operation that you do only with the directory server, and then it will return a list of names and metadata and reference to store just as before. What you need to know is how to control the sharing. So UBSPIN defines an access file. When you place this file in a directory, then this access rights will apply to all the files of that directory, and also of the files in the sub directory if no other access file is uncontrolled. This access file is stored in the directory server and is heavily used by the directory server to wizard information if the user that is requesting the file don't have the rights. And then the access control at the store level is done through keys. Basically, you create a version of the secret key per user that is supposed to access the file. So just a note, it's not an interlock protocol. Some misunderstanding about UBSPIN sometimes is that it provides a special way to share your data from your computer or this kind of thing like IPFS would do for example. But this is just a protocol. It doesn't define how your server should be accessible. So you need to have a public server and HTTPS is mandatory. Yeah, so let's see how you can use it as a user. So there are two steps in the setup. First one is signing up the user. So it's basically creating your key pair and verifying your email. All of it is just putting a new user into the key server and then you need to deploy your server. So it's installing the directory and store servers on your host and makes them accessible to the Internet. The best way to do is to use UBSPIN UI. So you can download it from the official website or just install it with GoGet if you have a special system. So the first time you open it, you will have the sign up wizard. It's very nice. You can just type in your email and stuff. Well then it creates your keys and it sends you just one email. That's the only time they will use the email for just verifying that you own the email at that point. The second step is a bit more complicated but there are some nice wizards to do it. So in the future, well UBSPIN is really early stage. So right now this is quite, it's not very simple especially for a wide audience but in the future it's most likely there will be some server providers and there is already one that is building. It's called Django. It should be live soon. Today you can just deploy your server into one of your servers or you can also use the Google Cloud Platform. Everything is done from UBSPIN UI and it's all deployed automatically. Also you can just use UBSPIN as a read-only mode. So at the end of the setup, this is what happens to your PC. So you have this configuration file that is created. So it's just the configuration of what user you're using and what are your dear and store servers. And also in your.ssh folder you will have the electric keys that are created. So all these files will be used by your UBSPIN clients running locally. You have just a word about the keys, the central key server. The logs are public so here are what you can see on the website. So this is the first sign-up. You can notice the new directories and store servers and this is the second logs with the actual server that I created. So now just some of the tools that you can use straight away. The most common is UBSPIN FS. So you can just install it as all the other tools and it just mounts a folder on your machine. So from this you can access your own files but you can also access anybody's file. For example, Rob Pikes says his lightroom and iTunes library with UBSPIN FS and the goal is to mount your whole home directory. Well then these two other tools are useful. You can install them the same. UBSPIN UI is the web file explorer and UBSPIN is just the general command line interface with a lot of commands. Some unofficial tools for now there is really not a lot but I expect more coming in the future. So for example you have a browser and this is a music player I've done and that I'm using actually daily now. So how does it play as a developer? So let's build a client app. So a client app is an app that accesses data through UBSPIN. It uses the client interface that the official library is using. It gives you a lot of helper functions. Basically you can do everything about reading, listing and writing data. So it reads the conf and key files that we've created before and it's the part of your app that will access UBSPIN. So for example here are some IDs for clients. Maybe something that synchronizes the photos that you have on your phone. This one will be right only into your UBSPIN data. Maybe a photo gallery to see your files, a sharing organizer and this kind of thing. And maybe a photo editor to do some little tweaks on your photos. So here are the different steps that you need for creating it. It's actually very simple. So for example if you want to make an application that just reads into UBSPIN and just serve it through HTTP, then you just need to initialize your configuration, then create your clients and then in your handle func you will just open the file and copy it straight away. So it's very simple. So the best way for initializing the configuration is to load it from a file. So just the same file as the one I showed you before. And then the client just takes the configuration file. That was actually the hardest part of the code. The rest is very simple. So this is just a classic HTTP handler. And the only thing is that you can see the client that opens and then the rest is just known. Yeah, of course, there should be probably some better error handling to know if the... because here it's just a not found, but maybe the information is withheld or maybe it's a network error. So yeah, listen and serve and serve. So just with that part of code, it compiles everything and everything. And then you can just try out some of the files that are accessible. And yeah, straight away, it will work with any of the of the UPSPIN files that you can access. So it's a very easy way to make application that can play with data. And yeah, from now on, you can already... there is a lot of other things that you can do with it, like list all your files, maybe filter some of the files, transcode on the fly and this kind of thing. The other thing that you can build are the server and storage. So a server app is something that implements the directory and store servers of the UPSPIN protocol. And that's all. The rest is you are just free to do whatever back end you want. So you can check the access control if you like. And then any data source of your choice. It can be just a link to another UPSPIN server or maybe it can be the GitHub API for serving GitHub issues or this kind of thing. The storage is also something that is very... well, the server is hard to implement actually, but the storage is something quite easy to do. It's just the low level implementation of how to store reference data. So there is already a lot of implementation with S3, Google Drive, GCP and this kind of thing. If you want some example of this kind of implementation, the best is to go to the official repos. So for example, in the experimental repos, you have an issue server or you can see the Dropbox storage for example. So as a conclusion, never before we had so much of our life on digital support and I think there are more and more projects that want to use sensitive data. For example, medical data. I think we really need to get back the control on who access our data and we should stop trading privacy for usage. Another thing I wanted to say is that the computer world has assumed that the wide audience is just getting dumber and file systems have been hidden from the mobile devices and this kind of thing. And the data and services are just hidden behind limited apps that are really focused on consumption. I think we should give back complexity to the wide audience because accessing files and sharing data and this kind of thing are not complex operation and I believe everybody should be able to deploy their own website. I want to give great UX to everybody and I think the key point here is collaboration. Doing the service together and I think Upspin can be a centralized way to have all our applications using the same storage and we'll just be compatible between each other. So if I think for example a photo viewer application can be really general and we don't care about how the data is stored behind, we just need to use Upspin and then we can work together. I believe. So yeah, that's all for me if you have some questions. I didn't hear about Hanoz. The project I really liked before that was Cosy Cloud which also had like data as a center. Oh sorry. So the question was there are some other projects that want to do the same thing such as unhosted, right? Well that's a big discussion in the Upspin community. There are some issues on GitHub about this. The Upspin team is always answering that the combination of universal security and shareable aspects of Upspin are kind of unix. What I like is the ambition of Upspin and also the simplicity of the interface. Yes? What do you think is the most important thing that needs to happen so that Upspin gains more traction than security? Yeah, I think the most important thing is to have some storage provider that can create you servers for people that know about IT or even people, non-IT people too. And yeah, I don't know to have some nice apps. I think an easy, maybe a transition would be to create some Upspin servers that can just plug onto already existing systems such as Facebook or Google photos or this kind of thing. And yeah, if it can be transparent and if you can just access your Google photos or your Facebook feeds through Upspin without having to deploy your own servers and this kind of thing, then maybe it can be like the killer feature that would spark the widespread adoption or something like that. But already, I'm just using it for myself right now and it's already quite nice. But yeah, I think everybody here will be even better for sure. Yes? If somebody gives you permission to file automatically, it means that you do yourself, now have the authority to give permission to somebody else? No, giving permission is only for the owner of the directory. And then you can choose what kind of permission you want to give, just like read, list or write. But you cannot, only the owner of the directory can modify the access. Yeah, exactly. Yeah. Sorry, but we're out of time. Thank you. We're on a close.
 Hi. Thank you. I'm very pleased to talk today. So, in such a great room, there is so many  people waiting outside. It's really an honor. Thank you to Frances for making this possible.  Today, I will talk about a project I really like, and I think that can change the way we use the  Internet. Before that, just a quick word of introduction about myself. So, my name is Gilles  Dachabot. I'm working in Paris for a big French website called Le Bon Coin. We are doing  Go there, but we're not... This talk is really not about what I'm doing there. So, just a quick  overview of what we'll talk about. So, the project I will talk to you about is UBSPIN. First of all,  why are you talking about UBSPIN? Why does UBSPIN exist right now? Then, we'll have an overview of  how it's working, and then we'll see what we can do in practice with it, just as a regular user or  as a Go developer, and then we'll have a quick conclusion. So, why UBSPIN? So, UBSPIN is the  new project from Rob Pike. I guess most of you know who Rob Pike is, but maybe not all of you.  He's the husband of René French, the creator of the GoFer. So, last year, there was two posts  about UBSPIN. The first one was published on the Google Security blog last February,  introducing the concept. And then in last October, there was the original manifesto that Rob Pike  wrote eight years ago. And that's where I heard about it, and that's where I found in love with  that project. So, the reason behind UBSPIN really is the information silo architecture that we've  fallen into slowly. The premise of the modern world, of the modern web was  remixability and creativity, but actually, we have been moved into databases that we cannot  access and that we cannot control. We have become dependent on the apps of the storage  providers that we use, and we are really dependent on what these people are willing to offer us.  I think we have lost quite a lot along the way, just to quote a few ones. I think we should be  able to use our data with any apps that we want, especially the one that we developed, for example.  And I think it should be very simple to share any kind of data with anybody we want. It's funny  for me to think that it's not easy, like to just create a public website just from a note that you  have on Evernote or anywhere, and from a couple of Google photos or something like that. I think  it should be trivial. Another problem with that is the actual apps. Developing something  like Google Photo is really something complicated, and yet every new storage provider is trying to  redo the same photo viewer and this kind of thing, and I expect them to fail because they don't  have the years of development of Google Photo, for example. Storage and application should be two  different businesses, and we should keep them separated. So the model that UBSPIN is pushing  is a model with data at its core, and the apps are just coming next. The apps are just like  regular users playing with data, reading and writing to it. It's by no means a new approach. It's  exactly what a local file system is, but it's something that we've never truly had in remote  systems, and it's something that is being taken away, for example, on the mobile devices. So the  two basics that UBSPIN is offering is universal naming and access rights. So every file has a  global identifier that you don't need to worry about sharing with other people. So it starts with  the mail of the person that owns that file, and then it's just a regular Unix-like path. And the  access control about it is really something, is another thing that comes with UBSPIN and that  you should consider solved and stop wondering about. So let's have an overview of how it actually  works. The most important thing about UBSPIN is actually the protocol, and as you would expect  coming from Rob Pike, it's very simple. So it's just three interfaces for a total of 11 methods,  and that's really all you need to know for building any system that works with the rest of the  UBSPIN world. Still, there is a need for a proof of concept for reference implementation,  and that's exactly what the UBSPIN team has been doing for the past years. So there is a  reference implementation for all the clients and servers, and also there is a collection of  tools that add some functionalities, some of the basic functionalities to UBSPIN. So UBSPIN is  really built around Go, and the best reference is actually the Go code, and for the definition of  the protocols, it's basically the interfaces from the UBSPIN protocol. So very quickly,  so the key server is just looking up and updating user information, and the store server is  basically the same thing, but with data. The DR director is a bit more complicated. I won't go  through all of them, but it's basically that's where the solving of the global name is done,  and then you have some other functions. So for example, if you need to develop,  well, basically for the global use, you don't really need to know how it's happening behind,  what is happening behind, but for example, if you are making a server from scratch,  then you will really need to know how it works behind. So let's quickly see how we can get a  file, for example. So the first step is with the key server. So you do a lookup for the user,  and what you get in exchange is just the user public key and the directory server address.  So that's for the user part, then the next part will be the lookup of the file. So then at that  point, the previous key server is just one key server for the whole UBSPIN, so that's a  known address, key.UBSPIN.IO. But then here you are contacting the directory server of the user,  the information that you had just previously. Looking up a file will give you back his name,  his metadata, and references, and store server addresses. That's actually where the first  access control is checked. The directory server, at least in the reference implementation,  will check that you have rights to ask for the store references. And then you can just get the  reference. So most of the time it's just a hash, and then the store will just give you  back bytes. Most of the time these bytes will be encrypted. So you need to have the key,  and you'll have the key only if you can access this file. Another example, for example,  listing a directory. This is an operation that you do only with the directory server,  and then it will return a list of names and metadata and reference to store just as before.  What you need to know is how to control the sharing. So UBSPIN defines an access file. When  you place this file in a directory, then this access rights will apply to all the files of  that directory, and also of the files in the sub directory if no other access file is uncontrolled.  This access file is stored in the directory server and is heavily used by the directory  server to wizard information if the user that is requesting the file don't have the rights.  And then the access control at the store level is done through keys. Basically, you create a  version of the secret key per user that is supposed to access the file. So just a note,  it's not an interlock protocol. Some misunderstanding about UBSPIN sometimes is that it provides  a special way to share your data from your computer or this kind of thing like IPFS would  do for example. But this is just a protocol. It doesn't define how your server should be  accessible. So you need to have a public server and HTTPS is mandatory. Yeah, so let's see how  you can use it as a user. So there are two steps in the setup. First one is signing up the user.  So it's basically creating your key pair and verifying your email. All of it is just putting  a new user into the key server and then you need to deploy your server. So it's installing the  directory and store servers on your host and makes them accessible to the Internet. The best way  to do is to use UBSPIN UI. So you can download it from the official website or just install it  with GoGet if you have a special system. So the first time you open it, you will have the sign up  wizard. It's very nice. You can just type in your email and stuff. Well then it creates your keys  and it sends you just one email. That's the only time they will use the email for just verifying  that you own the email at that point. The second step is a bit more complicated but there are some  nice wizards to do it. So in the future, well UBSPIN is really early stage. So right now this is  quite, it's not very simple especially for a wide audience but in the future it's most likely  there will be some server providers and there is already one that is building. It's called Django.  It should be live soon. Today you can just deploy your server into one of your servers or you can  also use the Google Cloud Platform. Everything is done from UBSPIN UI and it's all deployed  automatically. Also you can just use UBSPIN as a read-only mode. So at the end of the setup,  this is what happens to your PC. So you have this configuration file that is created. So it's just  the configuration of what user you're using and what are your dear and store servers. And also in  your.ssh folder you will have the electric keys that are created. So all these files will be used  by your UBSPIN clients running locally. You have just a word about the keys, the central key  server. The logs are public so here are what you can see on the website. So this is the first sign-up.  You can notice the new directories and store servers and this is the second logs with the actual  server that I created. So now just some of the tools that you can use straight away. The most  common is UBSPIN FS. So you can just install it as all the other tools and it just mounts a  folder on your machine. So from this you can access your own files but you can also access  anybody's file. For example, Rob Pikes says his lightroom and iTunes library with UBSPIN FS and  the goal is to mount your whole home directory. Well then these two other tools are useful.  You can install them the same. UBSPIN UI is the web file explorer and UBSPIN is just the  general command line interface with a lot of commands. Some unofficial tools for now there  is really not a lot but I expect more coming in the future. So for example you have a browser and  this is a music player I've done and that I'm using actually daily now. So how does it play as a  developer? So let's build a client app. So a client app is an app that accesses data through UBSPIN.  It uses the client interface that the official library is using. It gives you a lot of helper  functions. Basically you can do everything about reading, listing and writing data. So it reads  the conf and key files that we've created before and it's the part of your app that will access  UBSPIN. So for example here are some IDs for clients. Maybe something that synchronizes the  photos that you have on your phone. This one will be right only into your UBSPIN data. Maybe a  photo gallery to see your files, a sharing organizer and this kind of thing. And maybe a photo  editor to do some little tweaks on your photos. So here are the different steps that you need  for creating it. It's actually very simple. So for example if you want to make an application  that just reads into UBSPIN and just serve it through HTTP, then you just need to initialize  your configuration, then create your clients and then in your handle func you will just open  the file and copy it straight away. So it's very simple. So the best way for initializing the  configuration is to load it from a file. So just the same file as the one I showed you before.  And then the client just takes the configuration file. That was actually the hardest part of  the code. The rest is very simple. So this is just a classic HTTP handler. And the only thing is  that you can see the client that opens and then the rest is just known. Yeah, of course,  there should be probably some better error handling to know if the... because here it's  just a not found, but maybe the information is withheld or maybe it's a network error. So yeah,  listen and serve and serve. So just with that part of code, it compiles everything and everything.  And then you can just try out some of the files that are accessible. And yeah, straight away,  it will work with any of the of the UPSPIN files that you can access. So it's a very easy way to  make application that can play with data. And yeah, from now on, you can already... there is a lot  of other things that you can do with it, like list all your files, maybe filter some of the files,  transcode on the fly and this kind of thing. The other thing that you can build are the server  and storage. So a server app is something that implements the directory and store servers of  the UPSPIN protocol. And that's all. The rest is you are just free to do whatever back end you  want. So you can check the access control if you like. And then any data source of your choice.  It can be just a link to another UPSPIN server or maybe it can be the GitHub API for serving  GitHub issues or this kind of thing. The storage is also something that is very... well, the  server is hard to implement actually, but the storage is something quite easy to do. It's just  the low level implementation of how to store reference data. So there is already a lot of  implementation with S3, Google Drive, GCP and this kind of thing. If you want some example of  this kind of implementation, the best is to go to the official repos. So for example, in the  experimental repos, you have an issue server or you can see the Dropbox storage for example.  So as a conclusion, never before we had so much of our life on digital support and I think there  are more and more projects that want to use sensitive data. For example, medical data. I think  we really need to get back the control on who access our data and we should stop trading privacy  for usage. Another thing I wanted to say is that the computer world has assumed that the wide  audience is just getting dumber and file systems have been hidden from the mobile devices and  this kind of thing. And the data and services are just hidden behind limited apps that are really  focused on consumption. I think we should give back complexity to the wide audience because  accessing files and sharing data and this kind of thing are not complex operation and I believe  everybody should be able to deploy their own website. I want to give great UX to everybody and  I think the key point here is collaboration. Doing the service together and I think Upspin can be  a centralized way to have all our applications using the same storage and we'll just be  compatible between each other. So if I think for example a photo viewer application can be  really general and we don't care about how the data is stored behind, we just need to use Upspin  and then we can work together. I believe. So yeah, that's all for me if you have some questions.  I didn't hear about Hanoz. The project I really liked before that was Cosy Cloud which also had  like data as a center. Oh sorry. So the question was there are some other projects that want to do  the same thing such as unhosted, right? Well that's a big discussion in the Upspin community.  There are some issues on GitHub about this. The Upspin team is always answering that the  combination of universal security and shareable aspects of Upspin are kind of unix. What I like  is the ambition of Upspin and also the simplicity of the interface. Yes?  What do you think is the most important thing that needs to happen so that Upspin gains more  traction than security? Yeah, I think the most important thing is to have some storage provider  that can create you servers for people that know about IT or even people, non-IT people too.  And yeah, I don't know to have some nice apps. I think an easy, maybe a transition would be to create  some Upspin servers that can just plug onto already existing systems such as Facebook or Google  photos or this kind of thing. And yeah, if it can be transparent and if you can just access your  Google photos or your Facebook feeds through Upspin without having to deploy your own servers  and this kind of thing, then maybe it can be like the killer feature that would spark the  widespread adoption or something like that. But already, I'm just using it for myself right now  and it's already quite nice. But yeah, I think everybody here will be even better for sure.  Yes? If somebody gives you permission to file automatically,  it means that you do yourself, now have the authority to give permission to somebody else?  No, giving permission is only for the owner of the directory. And then you can choose what kind of  permission you want to give, just like read, list or write. But you cannot, only the owner of the  directory can modify the access. Yeah, exactly. Yeah.  Sorry, but we're out of time. Thank you. We're on a close.
Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_0_2195.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_2196_2399.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_2400_4763.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_4764_4847.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_4848_6899.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_6900_9071.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_9072_10643.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_10644_18719.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_18720_23783.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_23784_24263.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_24264_24911.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_24912_27767.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_27768_30059.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_30060_33503.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_33504_33587.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_33588_35711.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_35712_37343.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_37344_41711.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_41712_41891.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_41892_42887.png Upspin_and_a_future_of_the_Internet_My_vision_of_Rob_Pike_s_Upspin_as_a_basis_for_42888_43065.png