Does it bring all the boys to the yard?

Oh.

 

:-S

 

Why not?

I don't know where the yard is, so I'm unable to determine if all the boys were brought there.

I had a limited quantity and was not reluctant to consume it.

I fear Peter's milkshake would send the boys away from the yard. It could be quite useful under certain circumstances.

:'D

haha good point!

It could be decentralised and would actually be more secure if it was. I don't think Pete's wrong about this. Freenet did it (it failed, because it required a critical mass of users before it was usable (and never got them), but the tech was sound, I think a lot of it got rolled into what is now TOR).

Stuff is moving that way anyway. I mean all this 'cloud' stuff is virtualised on-demand servers with resources allocated on the fly. That's a step towards complete decentralisation.

There's a legal angle too. In the US people are starting to make home cloud servers - i.e. something very much like a NAS but with webmail, photo sharing etc. etc. - all the social stuff built in to the server. The reason for this is that if the authorities want access to all your online stuff they can get it pretty easily. If they want something from your home it's a lot tougher - they need more warrants and they need more justification.

As that kinda thing starts to become more common (and I think it will, eventually) decentralising gets a lot easier.

And as Pete says, all you'd need then is a chain of central hubs/database servers which glue all this together. You wouldn't even strictly /need/ that. It'd just be a good way to start it off.

I'm not sure Dan's trying to argue against that, more that he's got a fairly good idea of how much hardware costs and that Pete's rough budget isn't anywhere near enough. I'm inclined to agree with him.

And Pete's point is: What hardware? This idea could potentially be run on no-centralised-hardware which, last time I checked, cost no pounds. Anything you add is just to grease the wheels a little.

To put it another way: Dan's talking about creating a very robust 'enterprise level' 'server solution'. Which is nothing like what Pete's talking about, which is a decentralised, distributed (possibly p2p but that's pretty much beside the point) ad-hoc network.

 

Or to put it yet another way: Dan's suggesting a hardware solution to Pete's software problem.

You're assuming that everyone will want to set up a NAS or something similar in their home. But there are plenty of people (I'm thinking of the people in my office who panic when a new version of Internet Explorer gets installed) who don't/won't want that. Christ, I wouldn't want that (I would really, but just to make a point) - I pay enough for electricity as it is.

Even if you (as a company running this social network) does some coding magic to integrate things like Flickr, Picasa, ect and makes it look seamless, you're still going to have to pay those sites for access to their hardware. Especially if you're going to bring millions of new customers to them.

Basically, especially when you scale up to millions (tens of millions) of users, someone's going to have to pay for hardware somewhere along the line.

So where is the data stored? In terms of things like photos? On people's computers? It has to be stored /somewhere/.

I'll be honest and say I don't 'get' or understand it all. I'm not trying to be overly cynical, I just don't see a way it could be reliably implemented on the same scale as Facebook.

 

I don't see how grandpa Jones is going to get his photos to his grandkids using his swanky new iPhone.

 

I'm very much sticking with the Facebook analogy as it's frigging huge and surely the point of any social service is to get the masses involved.

I'm not assuming that at all. I'm saying if that's how things pan out then that makes it even easier.

It doesn't need 'everyone' to do that, just enough people. And people are doing it anyway because of privacy/property concerns.

But that's beside the point. It doesn't need that to work.

It would work similarly to TOR or Freenet or even BitCoin or, from another angle, Wuala.

It's nothing to do with Flickr and Picasa and so on - it supersedes those things, it doesn't talk to them (though it could - you don't have to pay flickr to link to their site :? )

It would (and this is the zero-hardware-cost version I'm describing, this is the extreme) be decentralised and distributed. There would be no server aside from all the clients. It could work in various ways ranging from people voluntarily donating a portion of their hard drive or running a server app on a spare machine to.. the client doing that automatically. But either way, each node would contain an encrypted portion of the network's content and access would be intelligently routed between these nodes.

That's it. Obviously there's no detail there and things could be done in hundreds of ways - large content could still be hosted more traditionally using established services and so on. That's all detail.

You could add a central server into that to improve routing early on and... even for something with a lot of traffic a simple rented dedicated server could handle that task.

You can argue that people would object to donating disk space and... that's a hard one to argue before someone tries it, but I doubt it. It wouldn't be much. And I'm sure people who cared about such things would donate entire servers (which would simply mean running the software and allocating as much HDD space as they wanted to) to the project - the same as people run gaming servers for no obvious gain other than they care.

All it'd take is one machine to get rolling. Then when that starts to get slow you'd have enough users that at least one of them would say "I like this service, I'll run the software on my PC to keep it fast" and so on and so on. (That's assuming you don't force every client to be a small server, which is the simplest solution).

Yeah, on people's computers.

You're saying "Facebook is Centralised so this can only work centralised". Go read up on Freenet and its successors and TOR and so on.

Yeah, I get all that. And it's a really good idea.

 

But, if you're going to be directing millions of people through Flickr's website (as an example), they've got to pay for the hardware and bandwidth it uses, and they're most likely to pass the costs on to the company responsible for all that extra traffic.

 

Mind you, don't ask me how to handle the authentication and user database across a distributed platform. That kind of encryption makes my head hurt.

But that's what Flickr do. That's like saying Flickr should charge Google because Google directs a lot of traffic to Flickr. Flickr want traffic.

If we're talking about scraping Flickr's info without going to the site then that's a different thing. But we're not.

The routing and encryption stuff is eye-wateringly complex, aye. But there are already far more robust solutions for that than this would need. This would only need to be as secure as the current web services are (not very secure at all). Anything on top of that would be an added benefit.

The major problem is that routing through a dynamic network of nodes is not currently going to be as fast as a simple web server. But, well, that is done currently through a distributed system currently (DNS) so that's probably solvable.

Surely, for the sake of keeping a consistent look-and-feel across your social network, you'd want to scrape Flickr's data and put it into your format.