4 ms·

Introducing Pond: A New RSS+Atom Syncing Protocol

17 points by ArturoVM 13y ago

grinich 13y ago
You might consider changing the name. There's a new crypto messaging project started by some folks at Google called Pond: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/ https://github.com/agl/pond https://github.com/agl/pond It's pretty much impossible to avoid naming collisions for projects. :-/
- ArturoVM 13y ago
  Yeah, I caught that :/ thanks! I have been working on the project for 6 months now, and I even tweeted the author of that project when he posted it, but he just ignored me haha :(
  - tptacek 13y ago
    Pond is probably more than 6 months old, and is an important project. If I were in your shoes, I'd just change the name. Hopefully, in a couple years, we'll know Langley's Pond by a different name: "email".
    - ArturoVM 13y ago
      You are absolutely correct. Guess I should seriously think about it.
nl 13y ago
It's not really a syncing protocol - a syncing protocol is something more like FeedSync (formally SSE)[1]. This looks more like an API for a feed reader type application. From a quick read it looks mostly ok for that (although I'd question why...) Out of interest, why not implement a read-only version of rfc5023/AtomPub[2]? Anyway... I'd suggest you get rid of the "Article" Object, and use the Atom "Entry" object instead (or possibly a single-entry Atom feed if you are in XML mode), serialized as JSON The "Fetch" call should probably take a "since date" as an option, instead of just "since id". It should return a JSON serialized Atom feed, not a custom object. https://cwiki.apache.org/confluence/display/ABDERA/JSON+Serialization https://cwiki.apache.org/confluence/display/ABDERA/JSON+Seri... is a pretty decent JSON serialization spec for Atom Notable omissions: no concept of tagging or saving articles. [1] https://en.wikipedia.org/wiki/FeedSync https://en.wikipedia.org/wiki/FeedSync [2] http://bitworking.org/projects/atom/rfc5023.html http://bitworking.org/projects/atom/rfc5023.html
- ArturoVM 13y ago
  Thank you for your feedback (and the links). 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. `since_date` is something I'm working on.
  - nl 13y ago
    Atom is a superset of RSS (to be more precise, it's a superset of all the different RSS dialects, properly specified).
    - ArturoVM 13y ago
      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.
EvanAnderson 13y ago
It's hard to take this seriously when you're making up your own authentication protocol-- and one that uses MD5 at that.
- ArturoVM 13y ago
  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.
  - marshray 13y ago
    Transmitting MD5(password) is really no better than just sending the password (except maybe for the top 20% or so strongest passwords).
    - ArturoVM 13y ago
      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
- al2o3cr 13y ago
  +1 to this. If you're going to send a replayable MD5 hash over the wire, you might as well just drop the pretense and just call it "password" instead - intercepting the "hash" compromises the account just as surely as if you'd leaked the password. This is especially nasty since the document mentions that not all users will use SSL. If supporting access via a non-secure channel is an absolute requirement, you may want to figure out something more effective...

17 points by ArturoVM 13y ago

You might consider changing the name. There's a new crypto messaging project started by some folks at Google called Pond: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/ https://github.com/agl/pond https://github.com/agl/pond It's pretty much impossible to avoid naming collisions for projects. :-/

ArturoVM 13y ago
Yeah, I caught that :/ thanks! I have been working on the project for 6 months now, and I even tweeted the author of that project when he posted it, but he just ignored me haha :(
- tptacek 13y ago
  Pond is probably more than 6 months old, and is an important project. If I were in your shoes, I'd just change the name. Hopefully, in a couple years, we'll know Langley's Pond by a different name: "email".
  - ArturoVM 13y ago
    You are absolutely correct. Guess I should seriously think about it.

nl 13y ago

It's not really a syncing protocol - a syncing protocol is something more like FeedSync (formally SSE)[1]. This looks more like an API for a feed reader type application. From a quick read it looks mostly ok for that (although I'd question why...) Out of interest, why not implement a read-only version of rfc5023/AtomPub[2]? Anyway... I'd suggest you get rid of the "Article" Object, and use the Atom "Entry" object instead (or possibly a single-entry Atom feed if you are in XML mode), serialized as JSON The "Fetch" call should probably take a "since date" as an option, instead of just "since id". It should return a JSON serialized Atom feed, not a custom object. https://cwiki.apache.org/confluence/display/ABDERA/JSON+Serialization https://cwiki.apache.org/confluence/display/ABDERA/JSON+Seri... is a pretty decent JSON serialization spec for Atom Notable omissions: no concept of tagging or saving articles. [1] https://en.wikipedia.org/wiki/FeedSync https://en.wikipedia.org/wiki/FeedSync [2] http://bitworking.org/projects/atom/rfc5023.html http://bitworking.org/projects/atom/rfc5023.html

ArturoVM 13y ago
Thank you for your feedback (and the links). 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. `since_date` is something I'm working on.
- nl 13y ago
  Atom is a superset of RSS (to be more precise, it's a superset of all the different RSS dialects, properly specified).
  - ArturoVM 13y ago
    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.

EvanAnderson 13y ago

It's hard to take this seriously when you're making up your own authentication protocol-- and one that uses MD5 at that.

ArturoVM 13y ago
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.
- marshray 13y ago
  Transmitting MD5(password) is really no better than just sending the password (except maybe for the top 20% or so strongest passwords).
  - ArturoVM 13y ago
    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
al2o3cr 13y ago
+1 to this. If you're going to send a replayable MD5 hash over the wire, you might as well just drop the pretense and just call it "password" instead - intercepting the "hash" compromises the account just as surely as if you'd leaked the password. This is especially nasty since the document mentions that not all users will use SSL. If supporting access via a non-secure channel is an absolute requirement, you may want to figure out something more effective...