Well, you know how client/server stuff works, right? The whole "client/server" paradigm exists because it's necessary; some use cases can't be done well just from client software. Sharing a file is such a use case. Sending a file isn't - you can just email something from your phone - but sharing or making a file available is hard for various reasons (e.g. client software isn't usually 24/7 available, it is often behind a NAT and difficult to route to, etc).
So, we need a server to share a file. There's a lot of ways to do that. On one end of the spectrum, you can do it all yourself: buy a computer, put it in your basement, connect it to the internet, install a webserver, move the file to it, write an index.html file pointing to it, write a .htaccess file to limit who can access it, and send the credentials to your friends and family. On the other end of the spectrum, you can pay someone else to do all of it by signing up for Facebook. In between are a lot of options. Urbit is one of those options, and (obviously) the people who make it are trying to make it the best option for at least somebody. What I was trying to do in this drunken rant, er, crowd-sourced user story, was to lay out how it might be implemented, in order to take advantage of urbit's strengths.
That comment is not an explanation of what urbit is or what its strengths are; it was written towards people who already know, and so glosses over that. I have a near-done "what is urbit and what are its major pros and cons" blog post I should really finish up someday, but this ain't it...
Um. Go to Facebook. Type in some text or select a photo and hit "Share". You have just shared a file with your friends.
(I'm not being snarky, but it seems you misunderstood me and I'm not sure how. Perhaps you thought I meant "share a file" like pirating movies or something? I just meant in the general sense that anything on a computer is a file, and sharing means letting someone else access it, which is sort of the core feature of any social media site.)
Yes I think the misunderstanding is that sharing a status update on Facebook constitutes sharing a file; I assumed you meant "sharing a file" like "I have a PDF I need to get to someone" and just could not imagine a world in which that constituted the majority of Facebook usage. :)
If you had said "creating an entry in a database" instead of "sharing a file" I don't think I would have had the same misunderstanding.
Sharing a file also has different connotations from uploading an image; when I upload an image to Instagram I am not doing it to share the raw file with someone so they can download it (though they certainly can if they use a browser extension to do so); I'm sharing it because that's where the people I know can see and interact with it.
Okay, that makes sense, but "creating an entry in a database" would've been confusing to the intended audience of urbit devs. I probably should've said "serve some stuff".
So, we need a server to share a file. There's a lot of ways to do that. On one end of the spectrum, you can do it all yourself: buy a computer, put it in your basement, connect it to the internet, install a webserver, move the file to it, write an index.html file pointing to it, write a .htaccess file to limit who can access it, and send the credentials to your friends and family. On the other end of the spectrum, you can pay someone else to do all of it by signing up for Facebook. In between are a lot of options. Urbit is one of those options, and (obviously) the people who make it are trying to make it the best option for at least somebody. What I was trying to do in this drunken rant, er, crowd-sourced user story, was to lay out how it might be implemented, in order to take advantage of urbit's strengths.
That comment is not an explanation of what urbit is or what its strengths are; it was written towards people who already know, and so glosses over that. I have a near-done "what is urbit and what are its major pros and cons" blog post I should really finish up someday, but this ain't it...