5 ms·

Git provides most of the infrastructure answers. I think the idea that someone would host a personal website in future is slightly backwards. Just clone their w

Git provides most of the infrastructure answers. I think the idea that someone would host a personal website in future is slightly backwards. Just clone their website's public repo and browse locally. This could be extended to social news feeds, where if you just put new content in your repo then other people that subscribe could see those updates mashed together into a single feed. The problem here is the economic incentives to do it are low, but the technical barriers to solving this are genuinely getting lower and lower all the time, so at some point it will happen.

noarchy 12y ago
>Git provides most of the infrastructure answers. I think the idea that someone would host a personal website in future is slightly backwards. Just clone their website's public repo and browse locally. Are you also assuming that Git will one day reach a point where everyday web users can use it? Because unless you're using software to abstract away the ways that one normally interacts with Git, I just don't see your average web user going anywhere near it.
TheSpiceIsLife 12y ago
At some point it will happen. Probably as FOSS because, as you say, the economic incentives are low. While the economic incentives are low mainstream implementation will probably also be low. Also, the security consequences of such scenario could be an issue. Organisations with huge resources have a hard time with security, how's the average person going to compete with an organised adversary. We move now into the realm of speculation.
kragen 12y ago
I wrote about this a bit in 2005, although Git had just come out, so it wasn't clear that Git was going to rule while Codeville would be forgotten: https://www.mail-archive.com/kragen-tol@canonical.org/msg00120.html https://www.mail-archive.com/kragen-tol@canonical.org/msg001... There's still a social/economic question of who pays for storage — presumably someone needs to be able to say "This data is important to me; please don't trust the rest of the Web to keep a copy," or things that nobody happens to read for a few months will be lost. So there's still "hosting". But it might be more like what EBS or Gandi provides than what Amazon EC2 or Rackspace provides. I think distributed content-named storage (like CCN, Tahoe-LAFS, Git, etc.) solves the "distributed immutable hypertext" problem, but there are still other problems to solve: how to make things mutable (each of these three has a somewhat ad-hoc and application-specific method for this), how to do asynchronous event notification, how to establish contact between previously disconnected parties (unsolicited messages), and so on. Think about how you'd build applications like blog comments, or email, or Google Search, on top of such a distributed content-named blob store.
stephenr 12y ago
So to view your personal website, on my phone, I need to clone an entire Git repo, with the entire history of the entire site.. Some people just treat some technologies as a "this can fix anything" when really they're well suited to one task. This is the sort of thinking that suggests using a Git based solution to sync binary files between computers - the thing even the biggest Git fanboy will admit it does poorly - handling of binary files - and someone wants to use it for that specific purpose.
- kragen 12y ago
  You could make a shallow clone with just the objects you need for the front page. If we're taking Git literally here, you need to get the current head somehow, then fetch the commit object, then fetch the root directory object it points to, then fetch the index.html blob object it points to. If we're not using HTTP URLs to name the objects, and the objects in question are small, it would be pretty easy to configure the server to "optimistically" bundle the commit, the directory, and the blob into the response to the request for the head, so it could be a single RTT. It might actually be more efficient to do a single-version shallow clone than to fetch all the relevant assets with separate HTTP requests. Git already supports shallow clones, and you can already use them to clone things like Github wikis, and now you can even push from them: https://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow-clone-more-useful-than-it-makes-out https://stackoverflow.com/questions/6941889/is-git-clone-dep.... A --depth 1 clone of https://github.com/kragen/500lines https://github.com/kragen/500lines is 7 megabytes, although the full history is only barely larger. My phone has 400+ megabytes of RAM. More promisingly, though, Git blobs are identified by their hashes. That means that if both my home page and your home page use Twitter Bootstrap 2.3.2, your phone only needs to download it once to render both home pages, since it can see from the blob IDs in the Git directory that it already has the relevant blobs. (Assuming it hasn't been optimistically included in the initial message response!) It doesn't have to worry that one of us might be serving up a maliciously-backdoored version in order to steal users' login cookies on the other's site. By the same token, you can accept the blobs from anyone who has a copy, who might be closer to you on the network than the origin server. Especially if, like me, you're in Argentina with a 250ms ping time to the US. (This assumes you're using something cleverer than the standard git clone protocol, which builds a thin pack including all the objects you lack.) So git-cloning websites to view them could actually be faster than loading them over HTTP the way we do it now, because it eliminates a lot of the unnecessary security issues that we work around with bandwidth duplication and high latency.
dragonwriter 12y ago
> I think the idea that someone would host a personal website in future is slightly backwards. Just clone their website's public repo and browse locally. If you're cloning the public repo, that still requires someone to host the website -- instead now, they are hosting the whole history of the website (or not -- they could rewrite history and just have the most current version) -- and anyone who wants to view it has to pay the cost (bandwidth/latency) to clone the repo before they can view it.

noarchy 12y ago

>Git provides most of the infrastructure answers. I think the idea that someone would host a personal website in future is slightly backwards. Just clone their website's public repo and browse locally. Are you also assuming that Git will one day reach a point where everyday web users can use it? Because unless you're using software to abstract away the ways that one normally interacts with Git, I just don't see your average web user going anywhere near it.

TheSpiceIsLife 12y ago

At some point it will happen. Probably as FOSS because, as you say, the economic incentives are low. While the economic incentives are low mainstream implementation will probably also be low. Also, the security consequences of such scenario could be an issue. Organisations with huge resources have a hard time with security, how's the average person going to compete with an organised adversary. We move now into the realm of speculation.

kragen 12y ago

I wrote about this a bit in 2005, although Git had just come out, so it wasn't clear that Git was going to rule while Codeville would be forgotten: https://www.mail-archive.com/kragen-tol@canonical.org/msg00120.html https://www.mail-archive.com/kragen-tol@canonical.org/msg001... There's still a social/economic question of who pays for storage — presumably someone needs to be able to say "This data is important to me; please don't trust the rest of the Web to keep a copy," or things that nobody happens to read for a few months will be lost. So there's still "hosting". But it might be more like what EBS or Gandi provides than what Amazon EC2 or Rackspace provides. I think distributed content-named storage (like CCN, Tahoe-LAFS, Git, etc.) solves the "distributed immutable hypertext" problem, but there are still other problems to solve: how to make things mutable (each of these three has a somewhat ad-hoc and application-specific method for this), how to do asynchronous event notification, how to establish contact between previously disconnected parties (unsolicited messages), and so on. Think about how you'd build applications like blog comments, or email, or Google Search, on top of such a distributed content-named blob store.

stephenr 12y ago

So to view your personal website, on my phone, I need to clone an entire Git repo, with the entire history of the entire site.. Some people just treat some technologies as a "this can fix anything" when really they're well suited to one task. This is the sort of thinking that suggests using a Git based solution to sync binary files between computers - the thing even the biggest Git fanboy will admit it does poorly - handling of binary files - and someone wants to use it for that specific purpose.

kragen 12y ago
You could make a shallow clone with just the objects you need for the front page. If we're taking Git literally here, you need to get the current head somehow, then fetch the commit object, then fetch the root directory object it points to, then fetch the index.html blob object it points to. If we're not using HTTP URLs to name the objects, and the objects in question are small, it would be pretty easy to configure the server to "optimistically" bundle the commit, the directory, and the blob into the response to the request for the head, so it could be a single RTT. It might actually be more efficient to do a single-version shallow clone than to fetch all the relevant assets with separate HTTP requests. Git already supports shallow clones, and you can already use them to clone things like Github wikis, and now you can even push from them: https://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow-clone-more-useful-than-it-makes-out https://stackoverflow.com/questions/6941889/is-git-clone-dep.... A --depth 1 clone of https://github.com/kragen/500lines https://github.com/kragen/500lines is 7 megabytes, although the full history is only barely larger. My phone has 400+ megabytes of RAM. More promisingly, though, Git blobs are identified by their hashes. That means that if both my home page and your home page use Twitter Bootstrap 2.3.2, your phone only needs to download it once to render both home pages, since it can see from the blob IDs in the Git directory that it already has the relevant blobs. (Assuming it hasn't been optimistically included in the initial message response!) It doesn't have to worry that one of us might be serving up a maliciously-backdoored version in order to steal users' login cookies on the other's site. By the same token, you can accept the blobs from anyone who has a copy, who might be closer to you on the network than the origin server. Especially if, like me, you're in Argentina with a 250ms ping time to the US. (This assumes you're using something cleverer than the standard git clone protocol, which builds a thin pack including all the objects you lack.) So git-cloning websites to view them could actually be faster than loading them over HTTP the way we do it now, because it eliminates a lot of the unnecessary security issues that we work around with bandwidth duplication and high latency.

dragonwriter 12y ago

> I think the idea that someone would host a personal website in future is slightly backwards. Just clone their website's public repo and browse locally. If you're cloning the public repo, that still requires someone to host the website -- instead now, they are hosting the whole history of the website (or not -- they could rewrite history and just have the most current version) -- and anyone who wants to view it has to pay the cost (bandwidth/latency) to clone the repo before they can view it.