It might be nice if 'gobbles' could be distributed/synchronized to multiple databases.

Listening habits could be gobbled both to a private libre.fm instance (e.g. providing local/experimental services turtle.libre.fm doesn't have yet), to turtle.libre.fm itself (to improve recommendations etc there), and even to last.fm.

This might improve adoption, as it'd allow new users to continue to use last.fm, but also be confident that the data is stored openly and could be used for more interesting stuff (and perhaps switching altogether) later.

Of course this could also be solved in the clients, but it'd probably be easier to keep the client-side simple and add intelligence to the server instead. Of course last.fm could start blocking scrobbles that came though us, but I don't expect them to be so evil :).

Data distribution with Last.fm

I agree with this idea. This would really simplify transition for Last.fm users. For now I will use the specific example of Last.fm. There are multiple ways how to solve the distribution.

• The easiest from the user's point of view is to "pull" recent tracks through the Last.fm API. The biggest advantage is that user can still scrobble the same way he was used to - Turtle doesn't need even Last.fm account password to access the data. On the other hand, updates won't be real-time (on the Libre.fm side) unless the scraping interval is very short - and this would put high load on both sides.

• Second solution -mentioned above- is inverse: users gobble to Turtle which pushes data further to Last.fm. This puts higher load on Libre.fm server. Load can be solved by submitting tracks in batch - but it means that the "realtime-ness" is lost on the Last.fm side. Also user needs to install modified client or modify hosts file. On the other hand I think this is the most efficient solution for personal installations of Libre.fm.

• Third solution is purely client-side. There can be some kind of daemon above the Last.fm client, which would catch submissions and send them both to Turtle and Last.fm. I am not sure if there is some effective way how to catch data without examining every packet, but it's just an idea.

Of course these solutions are non-exclusive and all three can be implemented.

I'd personally lean towards the second and third approach. lastscrape is useful for making the transition, but after that I think last.fm should be a 'sink', not a 'hub'. Polling last.fm for changes is likely to be *much* more resource-intensive (also on our side) than forwarding gobbles to last.fm. As for the second and third approaches: I think both should be possible (and why shouldn't they?), but it'd be nice to offer it as an optional service on the turtle server. That would be easy to use, and people with more interesting wishes (i.e., also automatically microblogging your gobbles, gobbling to multiple libre.fm servers, whatever you might think of) could turn it off on turtle and install it locally. --wiki:User:Raboof|Raboof 19:30, 19 April 2009 (UTC)