3 ms·
I don't think social networks need the same architecture as file-sharing networks. I want the data I publish on my social network node to be available 24/7 to m
by limmeau 16y ago
I don't think social networks need the same architecture as file-sharing networks. I want the data I publish on my social network node to be available 24/7 to my network friends. Since neither I nor most of my friends have a server at home, that means hosting the data on some server in some hosting center. So Rails isn't a necessarily stupid idea for a social network consisting of people like me.
- moe 16y agoSince neither I nor most of my friends have a server at home, that means hosting the data on some server in some hosting center. No. P2P networks like freenet and edonkey already distribute content over many nodes, just with different goals and priorities. It would be possible to adapt these mechanisms to ensure that data you push to the network actually stays in the network for a reasonable period of client-downtime. I could think of various ways to achieve this technically (n-copies, caching superpeers, and each of your friends would naturally hold on a copy anyways). One important bit to realize here is that the data volume is rather small because only meta-data (friends-graph, profile, wall, messages, etc.) needs to be handled in a truly distributed fashion. Big chunks, such as images, could and should mostly remain on centralized services for the time being. Another important thing to realize is, that the privacy in such a network could be made to be much better than on any remotely hosted solution because you can implement end-to-end encryption. All data on the network would naturally be transmitted and stored only in encrypted form. You would reveal chosen pieces to your friends by sharing the respective keys with them. So Rails isn't a necessarily stupid idea for a social network consisting of people like me. People like you (the end-user) aren't even supposed to install diaspora on their machines. Instead (if I understood them right) you are supposed to sign up on someone else's diaspora installation and generally trust all diaspora nodes in the network because your data travels freely between them. Disclaimer: If this description is wrong then someone please correct me. There's some conflicting information about what diaspora is and what it wants to be. Rails surely has its place in many applications. But for this one it just screams "We have no clue what we're doing" to me.
- limmeau 16y agoPerhaps we have different threat models regarding social networks. I'm concerned about one big company being able to analyze (within its own databases) the social network communication and friend-graph of a large part of the population. I'm less concerned about targeted attacks on individual semi-public messages. Some of my friends use Adobe Reader anyway. If reading a person's social network communication and local friend graph requires approximately the same effort as breaking into an individual mail server or sniffing SMTP traffic on a network node, and the criminal effort is approximately proportional to the number of persons to supervise, that's OK for 1.0 for me. I don't know the details of the protocol between Diaspora instances. But I hope that if some foreign Diaspora instance wants to read my messages to my friends on my own Diaspora instance, then it has to supply some proof that one of its users is a friend of mine.
- moe 16y agoWell, as said, my criticism comes from half a privacy angle, but mostly from the technical/execution angle. Their prototype leaves so many basic (and hard!) questions unanswered that, to me, their architecture smells less like a conscious decision and more like a strong case of: "If all you have is a hammer then everything starts to look like a thumb." In all honesty it looks like a non-starter to me. Sure, "just start hacking" is what everyone tells young startups to do, and that's what they apparently did. But that approach doesn't work very well for building a distributed system where all the components absolutely must snap into one another if you don't want the whole thing to fall apart under stress. Much less if your stated goals include terms like "privacy" and "security". The old proverb "Weeks of coding can save you hours of planning" does not apply here, at all.