On 15/04/2015 6:30 PM, Alexis Métaireau wrote:
Hi all, Thanks for starting this discussion and driving it with use
cases.
If we want to store user's data and convey the mozilla message, we
cannot just tell people to sync with existing (non privacy-friendly)
solutions, and need to think about a way to store the data in a way
> that fits out mission.
Speaking of privacy-friendly services that fit our mission, something
I'm not clear on is encryption - how will these services
support encryption, if at all?
For example, if we consider the readinglist engine, I believe attempting
to encrypt the data would result in the API breaking - the server would
be unable to perform even trivial reconciliations as the data is opaque.
That might be the correct tradeoff for a readinglist, but it's not clear
it's also the correct tradeoff for SMS/MMS in a privacy-friendly context.
I haven't seen this mentioned anywhere, so wondering what the current
thinking is about that?
Mark
I believe we need to iron out the specifics of each data type we want
to sync, and what are the complexities around them. I would suggest
starting one drop at a time (so next could be contacts? I agree it's
one of the more important ones). I don't know who decides on what
needs to be done next? Do we have product interested in these?
For syncing, the general approach we're taking (we being the people
behind "cloud storage" at cloud services) is to have some specialized
micro services; All of the interesting bits are summarized in a
library and our goal is to provide all of that as a service rather
than as a library.
It will make sense to create a generic cloud storage at some point
(but we're not there just yet). It might make sense for simpler data
types (readinglist, payments) and not for others more complex ones
(email, contacts), but we'll figure that out by learning from our
experiences.
On 15/04/2015 01:34, Richard Newman wrote:
I generally advise "reuse, don't combine" — make separate services
that might, if convenient, share an implementation. The current
Reading List service, for instance, is quite generic and could be
repurposed for storing contacts… but I wouldn't suggest that we
make the same service handle both RL and contacts!
This is the approach we started to take for the readinglist, and all
the generic code is done in a reusable way. The whish, though, is to
be able to provide a generic "cloud storage" solution [0], but this
is currently being defined.
In case this approach doesn't make sense, we'll be able to fallback
to the generic codebase [1] and still do micro services.
[0] http://kinto.readthedocs.org [1] http://cliquet.readthedocs.org
_______________________________________________ Sync-dev mailing
list [email protected] https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
