4 ms·

Pardon what may seem to be a silly question (amateur "would-be" engineer speaking), but I have a doubt, which is the following: Data needs to be stored. You ei

Pardon what may seem to be a silly question (amateur "would-be" engineer speaking), but I have a doubt, which is the following: Data needs to be stored. You either store it locally, and as such it is only accessible when the device is on, or it's stored on a central repository or index, meaning it's always on even if one of the devices is off. How do you tackle this? How do you make sure that user A tries to access news feed of user B, and fails to get it because user's B device is offline? Maybe I'm being slow or noobish, but it seems to be the same problem one has with bitorrent: user A downloads from user B if user B is online. If data is common, I have multiple seeds, but social network implies that nobody has the same data. Unless you copy my graph to my friends "device" so one has multiple seeds, which could be quite unpractical on mobile devices if I have a lot of friends. How do you solve this "intermittent issue" and the synchronization and persistence problems it generates? Without a central "clearing"/indexing server? Even Skype has "Super nodes" to handle this issues... This aside from the fact that "IPV6 deployment" is not going to be a easy cake to bake, one has to fix the problems faced by GPG trust model to ensure that two parties can verify (with some degree of trust) that the other party with whom they're communicating is, indeed, the person they expect, dynamic IPs, and so on.

pdxwebdev 16y ago
You can have your data hosted if you don't believe your device will be online all the time. This could open up some ad-based services.
- gdberrio 16y ago
  I don't think that answers my question on intermittence, persistence and syncronization. I can have my date hosted, but if my friends don't (that's why they use your service, so not to have to do that, or else they remain with Facebook, LinkedIn, etc. That's your USP), I can only access their data when my friends devices are online. Or, alternatively, you store my whole friends graph on my device, which presents scalability and performance issues. Or, 3rd route, you store my friends data on multiple devices on the network, doing "multiple seeds". Again, we're back to "opps my data is all over the place", when your Unique Selling Point was P2P = privacy, no need to centralize. Even Skype Supernodes don't solve this issue. They solve some of the routing issue. Not the "address book/data issue". You don't seem to solve it either.
  - pdxwebdev 16y ago
    "Or, alternatively, you store my whole friends graph on my device, which presents scalability and performance issues." With all due respect, this is where you are incorrect. Devices today completely capable of handling a large amount of compressed plain text data. Media would will be links to external sources as storage capacities play catch up. The CPU of the device would be able to map your entire social graph and do things that are not possible today being that calculating a social graph on a central server for each user is EXTREMELY expensive and basically impossible with high-load services. Kind of like the concept behind folding @ home.

pdxwebdev 16y ago

You can have your data hosted if you don't believe your device will be online all the time. This could open up some ad-based services.

gdberrio 16y ago
I don't think that answers my question on intermittence, persistence and syncronization. I can have my date hosted, but if my friends don't (that's why they use your service, so not to have to do that, or else they remain with Facebook, LinkedIn, etc. That's your USP), I can only access their data when my friends devices are online. Or, alternatively, you store my whole friends graph on my device, which presents scalability and performance issues. Or, 3rd route, you store my friends data on multiple devices on the network, doing "multiple seeds". Again, we're back to "opps my data is all over the place", when your Unique Selling Point was P2P = privacy, no need to centralize. Even Skype Supernodes don't solve this issue. They solve some of the routing issue. Not the "address book/data issue". You don't seem to solve it either.
- pdxwebdev 16y ago
  "Or, alternatively, you store my whole friends graph on my device, which presents scalability and performance issues." With all due respect, this is where you are incorrect. Devices today completely capable of handling a large amount of compressed plain text data. Media would will be links to external sources as storage capacities play catch up. The CPU of the device would be able to map your entire social graph and do things that are not possible today being that calculating a social graph on a central server for each user is EXTREMELY expensive and basically impossible with high-load services. Kind of like the concept behind folding @ home.