[Owncloud] Dropbox-like FLOSS alternative ideas

[Frank Karlitschek]

On 24.03.2010, at 10:48, Roberto Suarez Soto wrote:

> Hi,
> 
> 	I've read on a news site that there was the intention of creating a
> FLOSS alternative to Dropbox. I use Dropbox, and also SpiderOak and Ubuntu
> One, and have tried JungleDisk. So, with this background, I'd like to share
> my ideas on the subject.


Great. Help is always welcome. :-)


> 	Some time ago I wondered how I could do something akin to Dropbox,
> but in my own server and under my own conditions. I tried several things:
> 
> 	- inosync (http://bb.xnull.de/projects/inosync/)
> 	- A home-brewn solution based on inosync, but using fsvs
> (http://fsvs.tigris.org/) and subversion instead of rsync
> 	- Conduit (http://live.gnome.org/Conduit)
> 
> 	inosync uses inotify and rsync to mirror almost instantly any changes
> to one or several directories to a remote site. Problem and difference with
> Dropbox: it's one way only, from your computer to the remote site. If you
> want to synchronize those directories to another computer you have to
> manually rsync from the remote site, and maintaining coherence afterwards is
> a nightmare. Besides, you can be behind a firewall that doesn't allow
> connections to the rsync port, so access to the remote site can be tricky.
> 
> 	My second attempt was to hack inosync to use fsvs as backend.
> Advantages:
> 
> 	- You can use it through http/https (obligatory for any service like
> this, IMHO)
> 	- You can have versions of your files, nice if you have to undelete
> something or recover what you had in a directory five days ago
> 	- You get conflict resolution (more or less) for free
> 	- You can use fsvs manually for the first checkout, and then use
> inosync+fsvs to keep the files in sync
> 
> 	Disadvantages:
> 
> 	- Very hackish and prone to failure
> 	- Absolutely not easy to use
> 	- Depends on a already setup subversion server, which has its own set
> of advantages and disadvantages
> 
> 	And so I got to Conduit. Conduit is really great. You can define
> relationships among sources and targets easily. You can sync a local folder
> with a remote ssh server, both ways. Install Conduit in another computer,
> configure the same remote ssh server, and you have a very similar setup to
> Dropbox. But it's ssh, so if you change two bytes in your many-megabyte file,
> you have to transfer all the megabytes again. It really needs a rsync backend
> option. Besides, I found it a bit unstable when trying to sync really big
> folders (several gigabytes). Now I use it to maintain backups of several
> files and folders in my computer.
> 
> 	This is my experience. Now, my opinion of how a service of this kind
> should be:
> 
> 	- It should use http or https to transfer data

Yes. I agree

> 	- It should use some rsync-like transfer mode, only sending
> differences of files

Yes. Perhaps not critical for the first version but nice to have.


> 	- It absolutely must use local disk for cache, so you could still
> work without network and benefit from the speed of local disks (like Dropbox
> does)

Yes. But additionally we plan to support direct mounting of the server and a webinterface.


> 	- It should be transparent to the user: you just work in a folder,
> and changes get synchronized, without you having to do anything

Definitely 

> 	- It should be able to use a server as backend (so I could
> install it in my tiny VPS or in my big enterprise fileserver), or proprietary
> services with open APIs, like Amazon S3 or Google Docs

Yes.

> 	- It should have rich ACL features: "admin" and "normal" users,
> groups, etc., so it could be used in multiuser environments

Yes. The first version will probably only support one user. The next version will support sharing of files.
And after that will will work on full multiuser support.


> 	- It should allow for public and private folders, to share
> data among people


Yes.

> 	- It should be fully encrypted

of course.

> 
> 	I think that's all. Thanks for reading :-)


Thank you for your feedback. It would be great if you could help us.

Cheers
Frank


--
Frank Karlitschek
karlitschek at kde.org