The actual doctrine is closer to “not-self” but it’s still a part of the teachings that one should not compare oneself to others. It’s such a shame that some of the representatives of the Buddhist tradition don’t practice that, which leads to the perception that “it’s all the same,” as someone else commented here.
With respect, Bhante, it is not fitting of a monk to criticize another monk in this way in public.
I do not know venerable Khemarato, nor his teachings, but I would humbly suggest that if you’re concerned about people being misled in the Dhamma by that website, it’s better to focus on the content.
TLS/SSL will be a requirement soon, with some form of "bearer token" auth scheme. At least for the reference implementation.
The MD5 hash is there to mitigate two issues, currently: some (or most) common users won't pay for a certificate, so instead of sending the password in cleartext, it's hashed as an MD5 to avoid exposure—all of this, of course, is no guarantee against MITM. Which leads us to the second issue: most [non–techie] users re–use their password for a _lot_ of things. At least, if the password is intercepted, it won't be reusable.
It's also worth noting that bcrypt is used server–side to store passwords.
Auth (and very possibly a crypto scheme too) is yet to be tackled. Haven't even decided if it should be part of the spec, or left up to each implementer.
Auth is a WIP. Anybody who has suggestions and candidates for auth schemes, is welcome to send them to the mailing list, so we can improve the protocol :) pond@librelist.com
Changing "Article" to "Entry"—noted. As for doing away with the custom schema and using the Atom serialization you posted: it's worth noting the protocol is meant to sync with Atom _and_ RSS transparently; to keep things simple and consistent, a middle ground has to be found.
True. But there are certain elements that vary greatly between specs (or rather, between spec and... suggested format?). For example, the `person` construct, the `text` construct, etc, which are rather inconsistent and flat in the RSS spec. If it were all fire–and–forget, I could rest at ease knowing it's a superset, but most differences are not additive.
Remember encryption is not the same as hashing :) With encryption you can reverse the process, as long as you have the encryption key(s). With hashing, you can't.
I realize, but whatever server is making the API calls needs unrestricted access to the key and the encrypted tokens. So if server is compromised, the access tokens are necessarily compromised too, aren't they?
It's really great to see Microsoft moving on to embracing change, first WP7 and now this. A tendency and a positive attitude towards evolving the company is noticable.
