Indeed, that would be quite a different rating solution! ...where the ratings are actually not part of the wiki, unless you were to import them from some external service regularly... or be able to load them like you'd load twitter posts or disqus.
I guess what's required is some service (or chain of services):
- to which we can forward (structured) emails
- which can be taught to read data from those emails
- store the corresponding ratings (or other stuff like comments) to an adequate data store
- should be one store per online wiki, each tiddler being an index
- retrieve ratings from the service
- either retrieved as the entire list (possibly best for something as simple as ratings, on startup)
- each rating individually (when displaying a tiddler ...more requests to the server)
- displayed in the view-template
If we could get something like this going then it would provide a great reference solution / scaffold for other solutions of this nature, e.g. polls. comments, etc...
Actually, we are free to design the form template used to send those emails any way we like! You can actually use
tobibeer/rate to set the rating, and then read it in the form used to send via email. Of course, this rating would not be persisted (per user) unless we also saved it as a cookie.
Anyway, displaying server ratings (on top) would be quite a different task. Look at imdb... if you're logged in, you see your own rating of a movie. If not, you see the ratings of others. Well, you can see the overall rating in a star, e.g. {8.1}.
In any case, I don't think we should (or can) take it as far as displaying to a visitor who rated our tiddler from a given IP ...the rating they assigned (except for the lifetime of a cookie, bah). What's more, an IP address is not a reliable indicator of an actual user... and with TiddlyWiki we do not have authenticated visitors, e.g. via oAuth or the likes... not that it's not possible... but the whole process would have to be thoroughly designed.
Personally, I would never allow anyone to interact with my site / wiki unless they did some basic authentication first, e.g. log in via google / facebook ...or any other authentication provider. But, these things turn out to be not exactly "Hello World" type projects. Something as basic as authentication may actually need quite a bit of code before you can be sure you know who's talking to you (in the context of your wiki) and who wants to participate via... email, ratings, polls, comments... and to make all that terrifically difficult, it would all rely on relaying emails to a service or services that...
- know what to do with those emails
- can be talked to so as to respond with whatever we instructed the service(s) to do with those data