FluidDB
on September 19, 2010 at 6:01 pmI’ve been doing some work with a new web platform called FluidDB in the last few days, basically adding some functionality to the open source .NET API library. These will be available publicly very soon (which hopefully should take the state of the library from ‘very raw’ to ‘barely useable’.
I will describe my understanding of FluidDB at this point:
FluidDB makes it possible to create and use OOP style objects stored in “the cloud” where you or anyone else can add properties to those object at any time. So if Facebook were to use FluidDB, each person and photo would be a publicly available object, and it would be possible for anyone to attach additional properties to people at any time. So www.hotornot.com would be able to simply attach a property to each photo with a rating out of ten. This would not impact on Facebook at all, but would provide additional functionality for HotOrNot. Of course, the creator of properties attached to an object has full control over access rights, so you can make properties hidden or read only if desired.
What this means in practice is that if web services start to use the system, then it is much easier for new services to come along and use this publicly available data and combine it in new and amazing ways.
I have two major thoughts about the system:
1. Privacy – It is already scary how much data is available online and how easy it is to find. If there was one large backing store for all your personal data and it was all linked together, would that be a good thing?
Actually I don’t think you can treat this as a negative, because ultimately the data is already out there, and it would only mean that you would need to be more careful about how you present your digital persona. Raising awareness of that is probably a positive thing!
2. Data control – The system relies on having a single database for data which raises several concerns. Firstly are practical considerations- can they handle the quantity of traffic, keep spam under control, provide a decent level of security, and support enterprise usage? Secondly is a more complex question- is it a good idea for any individual entity to have control of so much data? How will they deal with copyright and intellectual property infringement, what level of government intervention will they allow when under pressure, what happens if you get banned and become an outsider? This might sound paranoid but I think it is something worth considering (and yes Google scares me).
Still, it is an interesting service in it’s fledgling state, and I would suggest taking a lot at http://www.fluidinfo.com if you are interested.
Thanks for the write-up. Yes, raw -> barely usable would be a good outcome. Take a look at FOM or the Java client library to see where the .NET project could go.
I wouldn’t say FluidDB objects were like OOP objects, rather just “objects” in the common-sense use of the term. The OO object comes with a lot of conceptual baggage (inheritance, attributes, methods, public/private etc…) whereas a FluidDB object is simply a place to tag data about something. I wouldn’t argue with any of the other stuff you’ve written.
Regarding your two reactions to FluidDB. I agree with you about point number one. I’d also add that FluidDB’s unique permission system makes sure the database remains openly writable whilst still allowing users a high level of control over who or what has access to their data.
The first set of questions in your second point are yet to be answered and only time will tell. FluidDB has been designed to scale massively (this is the third version) and we expect to improve performance and reliability based upon evidence from real world usage, although I’d add we’ve never unintentionally gone down or lost data (and remember we’re in open alpha).
The more philosophical questions that you end with are *very* interesting. Obviously, we’ll have a sensible and fair end-user agreement – IANAL but I’m pretty certain it’ll say something about *not* uploading copyright infringing material. But hey, we’re nice guys and we definitely don’t live in a volcano lair with mono-rails or fluffy white cats. We’re open about what we’re doing and will release the source code to FluidDB once things have settled down, it’s feature complete and we have the resources to properly support it as an open-source project with a community of developers. We feel it *essential* that people can audit us since we want them to trust us with their data.
Hope this helps…