In the last 24 hour, somehow, I was stumbled upon the idea of having my information sync-ed to all devices that I use every day. I know, some of you might say "that's old news, what's so good from your idea this time Dwi?"

Here's the thing that I can't crack my answer about the above needs: why does many 'me cloud' providers always use their own server located in the Internet to store our personal data? Why can't we make me-to-me cloud kind of sync method?

I'm going to discuss the later one as the answer to the first one is very obvious (if you don't know the answer, then bad luck )

The approach of having all your data sync-ed up can happen in two ways:

• Centralized data storage using outside party
• De-centralized data storage using third party as 'pass through' link

We have seen the first implementation all over the place, Apple's mobile me, Google sync and Mozilla Weave are some of the example.

I have not seen the second approach being implemented by any one (yet, if there's any let me know).

The de-centralized data storage will work much like peer-to-peer mechanism, except: only certain party(ies) can access the data. Thinking of it, it will be making protected-p2p for sharing data amongst 'yourself' (which could include you, your family and maybe your friends). Am I talking about social networking now? Aaaarrgghhhh!!!!

Ok, seriously, here's what I can come out on the idea about de-centralized me-cloud.

The sync mechanism is similar with the centralized method that we already know. The key difference with the decentralized method is: only username, password  and which node in the Internet that it should sync to/from. Thus, no sync data is kept in the provider. The provider is working much like the messenger services (ah ha, that's what I was trying to say in the beginning!).

The reason I came up with that method is based on the following fact:

• the cloud provider is being hammered/ bombarded by user sign up and their storage (the provider) is filled up quickly, each time a current or new user sync their data.
• the cloud provider's objective is supposed to be set at passing user's data, not keeping it (unless they have their own agenda on why they wanted to keep user's data -> ha!)

This give us one question left: if all of my data is kept by me, if things happened (touch wood) with my data, isn't it going to be destroed/ gone? Hang on my friend, even though your data is kept by you, you still can opt for internet storage right? (I know, this will be against my own word up there, but the data that you store is not in the cloud provider that you sync with. Your data is kept in the Internet storage service provider that has guaranteed you that your data will be safe and secure. More on this topic later)

From the cloud provider, the challenge is: how to provide that many connections at one time. True that the storage issues is no longer happening (or at leat reduced to the minimal growth rate), but the simultanuous connecections to/from client/provider will still be massive.

Let's do the math:

• Let's assume each user has 200 contacts, 500 calendar appointments (spanning 2 years), and 100 notes. Assuming each contact is 1kB, each calendar is 5kB and each notes is 10kB, that is like 3.6-ish MB data to be sync-ed.
• Let's assume each day, there is 100 new sign ups and the provider runs the service non-stop for 3 months. This equals to around 30GB of data that the provider need to store! For one year, that will be around 120GB and so on ...
• The above assumption will only takes place if the new user sign up per day only 100, if the service is getting popular, with the current nearly 3billion mobile phone users, and each user (I believe) have 2-3 computers to use everyday. That is equivalent to ... (counting ... switching from calculator to better calculator ...) nearly 10exabytes of data!!! (1 exabytes is 1 miillion terabytes, or 1000 million gigabytes).

The thing is: that huge number is only for data storage. If we counted in the data transfer, that will be multiply from that amount, and that's only single sync per day for all users (assuming the number of cell phone users is the same number of desktops/notebooks that they use, that will only be multiplied by 4 per day for single sync).

Now, for the trade offs:

• With centralized sync, provider must be able to hold that chunk data size and also the data transfer.
• With the de-centralized sync, provider only need to worry on the data transfer (lets just pass the data storage worry at the user's end, or with the Internet storage provider) 
• Speed will be the next focus. With the centralized sync, data is available right after the sync happens. For de-centralized sync, data will be available after the sync's push from the provider.

Some of the details that I can think of how to make the de-centralized sync works is:

• Each user login will mark their devices' presence. Therefore, this might need a kind of 'heartbeat' software to tell the server whether the sync nodes are alive, which last time stamp that they hold, what's the last sync status, etc.
• User can choose to sync manually, periodical, or just automatic. With the manual sync, this will take sometime if there is/are huge number of sync to be made. With periodical, or just automatic, the sync data can be kept smaller per sync. Periodical and automatic sync will need reliable connections for constant sync.

To close off this article, either method above is actually promising a good business revenue for storage vendor, network, ISP and other parties.

Even though de-centralized sync reduce the possibility of keeping the data 'out there', it still needs a method to provide more secure sync session. Otherwise, whoever out there can simply tapped into user's sync cloud and slurp the data out (or worse still, poisoning the data with the false data or even erase it).

De-centralized sync is becoming an option, but I wonder why I can't find that many provider either to do it (other than they are not going yo make any business in data storage thingy).

P.S.: maybe since I am involved mainly in the data networking and not storage that's why I am keen to find out how de-centralized sync and its future potential works