You are viewing sandra_snan


Towards a distributed Flattr-like architecture

As I previously noted, Flattr is a proprietary, centralized system. (I also have some other caveats against that form of resource redistribution in general.) I said “Let’s say the centralization/single-point-of-ownership problems with this service were rendered moot somehow”, kind of handwaving that very important issue. That’s not to say that a decentralized Flattr-like system can’t be done. Now, I suck at cryptography and computer security, but here are the first stations along that train of thought.

I’m not affiliated with Flattr and I don’t have an account and I have no idea on how things work on the backend, but Flattr is basically providing three user-visible services. I’m calling them FP, FC, and FR.

FP is the escrow service. You pay money to an organization that provides the FP service, for example to Flattr, in any way that’s acceptable to both you and that organization. In Flattr’s case, that means a monthly payment of at least €2. In other words, you have an “FP-account”. (You could have more, of course, but you’d only need one—with an organization that you trust or that offer’s a good enough deal for you.)

FC is the click registration service. This could be open-source code that you could choose between running on your own server, or you could use an FC-provider hosted somewhere else. For example, Flattr could provide this. (The analogy with OpenID, but I don’t want to stretch this too thin, is that you can run openid-code (like phpMyID) yourself or use a provider.)
When a user with an FP-account clicks that button on any FC-server, some sort of magic crypto token (for example an UUID-derivative) or proof is passed along, generated by the FP-provider, passed to the FC-server, and passed back to the FP-provider who can check if it indeed matches one it sent out recently—i.e. if it indeed is a genuine click from one of it’s users. I’m handwaving this because dammit, Jim, I’m a philosopher, not a cryptographer! The FC-accounts need to be cryptographically unique, too. The gist is that the FP-provider can see how many FC-accounts (again: owned by various servers, not necessarily by the same company that provided the FP-service) received clicks in a given time period of the FP-providers choosing (Flattr uses one month).

FR is the receiving service. Each FC-point is registered to an FR (this could be any bank account, I guess) and cryptographically-securely passes the receivement information (like account/clearing number) along to the FP-accounts it receives user clicks from, so that the organizations providing those FP-services can transfer money according to the deal they’ve set up with their users—again, Flattr does this monthly, but other FR-providing organizations could have other deals.

Now, there’s a transparency problem—too much, and you risk privacy, too little and you risk getting scammed.

The user experience also needs a couple of buckets of polish, and better names. I sure hope FP, FC and FR doesn’t stick as names.

I’m not going to implement this system myself, but hopefully this did start some thoughts out there.



June 2012

Powered by