librelist archives

« back to archive

Daybed, synchro et Couch/PouchDB

Daybed, synchro et Couch/PouchDB

From:
Alexis Metaireau
Date:
2014-07-31 @ 14:17
Hey, salut !

J'étais hier à un évènement sur la re-décentralisation du web, et on à
pu
discuter notamment de comment fonctionnent PouchDB / CouchDB, Hoodie et
consort.

J'allais à cette rencontre avec en tête un questionnement sur ce qu'on
pouvait
faire pour que daybed soit possiblement décentralisable, et sur comment
gérer
la synchronisation des données de nœud à nœud.

Ce mail fait suite à une discussion entammée sur github [0], mais je me
suis
dit que ce serait mieux de discuter de ça en Français, tant qu'à faire !

La discussion soulève deux points:

1. Comment gérer la synchronisation des données d'un client vers un
server (et
   vice versa) ?
2. Comment gérer les ACLs de manière distribuée ?

J'essaye d'attaquer les points séparément pour garder les choses un peu
plus
simples…

Comment gérer la synchronisation des données ?
----------------------------------------------

Si possible, avant de ré-implementer notre propre solution pour la
synchro,
aussi sympa que cela puisse paraitre, j'aimerais bien voir si il est
possible
d'utiliser ce qui existe déjà, et définir des points bloquants sur ces
technologies si elles ne répondent pas complètement à notre besoin.

J'essaye de faire l'exercice pour CouchDB/PouchDB:

Points bloquants:
~~~~~~~~~~~~~~~~~

a) La réplication sur CouchDB se fait de base à base, et n'a pas de
granuralité
   plus fine. Ça signifie que toutes les informations stockées dans
   notre
   couchdb seraient partagées entre un client et un serveur. Dans notre
   cas cela
   pose un problème puisque nous stockons tout dans la même base.

b) CouchDB ne gère pas la validation des données (c'est le boulot de
Daybed),
   et accepter de la synchronisation depuis un client voudrait donc dire
   qu'on
   synchronise des données arbitraires.

Solutions non viables:
~~~~~~~~~~~~~~~~~~~~~~

(Je me suis dis que c'était pas une mauvaise idée de mettre les pistes
de
réflexion que j'ai invalidés, peut-être que ça nous donnera des idées)

a) Une des solutions que j'ai invalidé assez rapidement est le fait
d'avoir
   une base par utilisateur, et de mettre les données dedans. Ça
   simplifie
   certains cas d'utilisation (quand tu veux faire de la synchro juste
   avec
   un seul utilisateur) mais j'ai l'impression que c'est pas valable
   pour les
   autres cas.

Solutions viables ?
~~~~~~~~~~~~~~~~~~~

a) On peut imaginer avoir un système qui ne fait pas que de la
synchronisation
   de base à base depuis le server (e.g. on ne laisse pas tout sortir,
   en fonction
   du token d'accès de la personne qui initie la synchro). Un des gars
   du meetup
   bossait sur quelque chose d'un peu similaire (un proxy par dessus
   CouchDB qui
   ne laisse pas tout passer, en fonction d'ACLs), j'ai pas suivi de
   près mais je
   pense que ça pourrait nous intéresser.

b) Pour la gestion de la validation des données, je commence à me dire
que ce
   n'est pas si grave: si tu fais confiance à quelqu'un (e.g. tu lui
   donne un
   droit d'écriture sur la base) c'est pas nécessairement un problème
   qu'il
   pousse des données étranges. On peut imaginer que Daybed ait une
   tache de
   re-vérification des données de manière quotidienne, peut-être ? Ça
   nous
   simplifierait pas mal la tache. (Étonnement, j'étais le premier à
   dire qu'on ne
   pouvais pas faire confiance aux clients …)

Comment gérer les ACLs de manière distribuée ?
----------------------------------------------

Pour les ACLs, le problème que j'exposais à Rémy est le suivant: puisque
chaque
nœud liste qui à le droit de faire quoi, et que ces informations sont
comprises
dans les documents qu'on souhaite synchroniser, alors il faut également
trouver
un moyen de synchroniser les tokens hawk également.

Le souci, c'est que l'équivalent du couple login/password est pour
l'instant
stocké dans le serveur, et que donc il n'est pas possible de les
synchroniser,
puisque ça voudrait dire donner tous les mots de passe à la personne qui
synchronise.

La solution, à ce propos, serait de *ne pas* synchroniser les ACLs, du
tout.
Quiconque à le droit de lire les données peut en faire ce que bon lui
semble,
et il peut devenir une source de vérité également si il veut (donner
accès
à qui il souhaite). La solution que j'évoquais juste avant, à propos
d'un proxy
par dessus la replication de CouchDB pourrait rendre ça plus simple.


Vous en dites quoi de tout ça ? Est-ce que vous connaissez un peu plus
Couch/Pouch ?
Est-ce que ça vous semble possible ?

— Alex

Re: [daybed.dev] Daybed, synchro et Couch/PouchDB

From:
Rémy Hubscher
Date:
2014-08-01 @ 07:06
Salut,

En gros, il y a 3 choses à synchroniser:

  * La définition des modèles
  * Les données
  * Les permissions

Pour les permissions je suis d'accord avec toi qu'il vaut mieux garder
celles en place sur le serveur distant.

Voici ce que je propose en ayant le token *abc* du serveur A qui veut se
synchroniser avec le token *zxc* du serveur B.

Le modèle *todo* à les permissions suivantes: *{**"abc": "ALL"**,
"Everyone": ["read_definition"]**, "Authenticated": ["read_own_records",
"update_own_records", "delete_own_records"], "zte": ["ALL"]**}*

Avec l'opération sessionB("zxc").synchroFrom(sessionA("abc")) la
première fois,

On obtient les ACLs suivants:

*{**"zxc": "ALL"**, "Everyone": ["read_definition"]**, "Authenticated":
["read_own_records", "update_own_records", "delete_own_records"]**}*

Pour les records, la liste d'authors suivante:

*["zte", "abc"] *devient*["zxc"]*

Par suite les acls et authors locaux sont gardés.

Si serveur A possède*["zte", "abc"] et *le serveur B possède *["zxc",
"bfe"]* après synchro de

sessionB("gfe").synchroFrom(sessionA("abc"))

On obtient:

*["zxc", "bfe", "gfe"]*

Le nouveau droits: synchro = [ALL]

J'aime bien l'idée de Hacker un proxy CouchDB externe au code de Daybed
(daybed-synchro) qui utiliserait le même storage, avec une validation et
une modification des permissions/authors à la volée.

La force de CouchDB c'est de ne synchroniser que les données qui ont été
modifiés depuis la dernière synchro. (Il doit utiliser une date pour ça
ou des _rev incrémentales)

Il va falloir entrer dans le vif du sujet :)

Pour ce qui est de Daybed, on a terminé le set de feature minimal qui a
été review et landé hier soir.

La doc est à jour ici: http://daybed.readthedocs.org/en/latest/usage.html

On a également une PoC de daybed.js ici:
https://github.com/spiral-project/daybed.js avec des exemples
d'utilisations ici:
https://github.com/spiral-project/daybed.js/blob/master/tests.js

L'idée est de faire assez rapidement une Daybed Admin qui permette de
naviguer dans les données à partir d'un token.

Go for it :)

Rémy


Le 31/07/2014 16:17, Alexis Metaireau a écrit :
> Hey, salut !
>
> J'étais hier à un évènement sur la re-décentralisation du web, et on à
> pu
> discuter notamment de comment fonctionnent PouchDB / CouchDB, Hoodie et
> consort.
>
> J'allais à cette rencontre avec en tête un questionnement sur ce qu'on
> pouvait
> faire pour que daybed soit possiblement décentralisable, et sur comment
> gérer
> la synchronisation des données de nœud à nœud.
>
> Ce mail fait suite à une discussion entammée sur github [0], mais je me
> suis
> dit que ce serait mieux de discuter de ça en Français, tant qu'à faire !
>
> La discussion soulève deux points:
>
> 1. Comment gérer la synchronisation des données d'un client vers un
> server (et
>    vice versa) ?
> 2. Comment gérer les ACLs de manière distribuée ?
>
> J'essaye d'attaquer les points séparément pour garder les choses un peu
> plus
> simples…
>
> Comment gérer la synchronisation des données ?
> ----------------------------------------------
>
> Si possible, avant de ré-implementer notre propre solution pour la
> synchro,
> aussi sympa que cela puisse paraitre, j'aimerais bien voir si il est
> possible
> d'utiliser ce qui existe déjà, et définir des points bloquants sur ces
> technologies si elles ne répondent pas complètement à notre besoin.
>
> J'essaye de faire l'exercice pour CouchDB/PouchDB:
>
> Points bloquants:
> ~~~~~~~~~~~~~~~~~
>
> a) La réplication sur CouchDB se fait de base à base, et n'a pas de
> granuralité
>    plus fine. Ça signifie que toutes les informations stockées dans
>    notre
>    couchdb seraient partagées entre un client et un serveur. Dans notre
>    cas cela
>    pose un problème puisque nous stockons tout dans la même base.
>
> b) CouchDB ne gère pas la validation des données (c'est le boulot de
> Daybed),
>    et accepter de la synchronisation depuis un client voudrait donc dire
>    qu'on
>    synchronise des données arbitraires.
>
> Solutions non viables:
> ~~~~~~~~~~~~~~~~~~~~~~
>
> (Je me suis dis que c'était pas une mauvaise idée de mettre les pistes
> de
> réflexion que j'ai invalidés, peut-être que ça nous donnera des idées)
>
> a) Une des solutions que j'ai invalidé assez rapidement est le fait
> d'avoir
>    une base par utilisateur, et de mettre les données dedans. Ça
>    simplifie
>    certains cas d'utilisation (quand tu veux faire de la synchro juste
>    avec
>    un seul utilisateur) mais j'ai l'impression que c'est pas valable
>    pour les
>    autres cas.
>
> Solutions viables ?
> ~~~~~~~~~~~~~~~~~~~
>
> a) On peut imaginer avoir un système qui ne fait pas que de la
> synchronisation
>    de base à base depuis le server (e.g. on ne laisse pas tout sortir,
>    en fonction
>    du token d'accès de la personne qui initie la synchro). Un des gars
>    du meetup
>    bossait sur quelque chose d'un peu similaire (un proxy par dessus
>    CouchDB qui
>    ne laisse pas tout passer, en fonction d'ACLs), j'ai pas suivi de
>    près mais je
>    pense que ça pourrait nous intéresser.
>
> b) Pour la gestion de la validation des données, je commence à me dire
> que ce
>    n'est pas si grave: si tu fais confiance à quelqu'un (e.g. tu lui
>    donne un
>    droit d'écriture sur la base) c'est pas nécessairement un problème
>    qu'il
>    pousse des données étranges. On peut imaginer que Daybed ait une
>    tache de
>    re-vérification des données de manière quotidienne, peut-être ? Ça
>    nous
>    simplifierait pas mal la tache. (Étonnement, j'étais le premier à
>    dire qu'on ne
>    pouvais pas faire confiance aux clients …)
>
> Comment gérer les ACLs de manière distribuée ?
> ----------------------------------------------
>
> Pour les ACLs, le problème que j'exposais à Rémy est le suivant: puisque
> chaque
> nœud liste qui à le droit de faire quoi, et que ces informations sont
> comprises
> dans les documents qu'on souhaite synchroniser, alors il faut également
> trouver
> un moyen de synchroniser les tokens hawk également.
>
> Le souci, c'est que l'équivalent du couple login/password est pour
> l'instant
> stocké dans le serveur, et que donc il n'est pas possible de les
> synchroniser,
> puisque ça voudrait dire donner tous les mots de passe à la personne qui
> synchronise.
>
> La solution, à ce propos, serait de *ne pas* synchroniser les ACLs, du
> tout.
> Quiconque à le droit de lire les données peut en faire ce que bon lui
> semble,
> et il peut devenir une source de vérité également si il veut (donner
> accès
> à qui il souhaite). La solution que j'évoquais juste avant, à propos
> d'un proxy
> par dessus la replication de CouchDB pourrait rendre ça plus simple.
>
>
> Vous en dites quoi de tout ça ? Est-ce que vous connaissez un peu plus
> Couch/Pouch ?
> Est-ce que ça vous semble possible ?
>
> — Alex

Re: [daybed.dev] Daybed, synchro et Couch/PouchDB

From:
Alexis Metaireau
Date:
2014-08-01 @ 09:02

  Pour les permissions je suis d'accord avec toi qu'il vaut
  mieux garder celles en place sur le serveur distant.

  Voici ce que je propose en ayant le token abc du serveur A
  qui veut se synchroniser avec le token zxc du serveur B.

  Le modèle todo à les permissions suivantes: {"abc": "ALL",
  "Everyone": ["read_definition"], "Authenticated":
  ["read_own_records", "update_own_records",
  "delete_own_records"], "zte": ["ALL"]}

  Avec l'opérationsessionB("zxc").synchroFrom(sessionA("abc"))
  la première fois,

On obtient les ACLs suivants:



{"zxc": "ALL", "Everyone": ["read_definition"],
"Authenticated": ["read_own_records", "update_own_records",
"delete_own_records"]}



Pour les records, la liste d'authors suivante:



["zte", "abc"] devient ["zxc"]



Par suite les acls et authors locaux sont gardés.



Si serveur A possède ["zte", "abc"] et le serveur B possède
["zxc", "bfe"] après synchro de



sessionB("gfe").synchroFrom(sessionA("abc"))



On obtient:



["zxc", "bfe", "gfe"]



Le nouveau droits: synchro = [ALL]



En fait ce n'est pas ma proposition. Ma proposition est de
laisser les nœuds qui se synchronisent gérer leurs permissions
eux mêmes, ce qui veut dire que les permissions ne seraient pas
synchronisés.



Pour les champs auteurs, ceux cis seraient ajoutés les uns aux
autres lors de la syncronisation, à priori.



Mais cela ne convient en fait pas à tous les cas d'usage, on
peut imaginer avoir plusieurs règles de synchro, qui ont des
effets différents peut-être ?







J'aime bien l'idée de Hacker un proxy CouchDB externe au code
de Daybed (daybed-synchro) qui utiliserait le même storage,
avec une validation et une modification des permissions/authors
à la volée.



La force de CouchDB c'est de ne synchroniser que les données
qui ont été modifiés depuis la dernière synchro. (Il doit
utiliser une date pour ça ou des _rev incrémentales)



Il va falloir entrer dans le vif du sujet :)



Exactement, je ne sais pas encore ce que ça voudra dire de
fonctionner comme ça, parce que ça veut probablement dire qu'il
faudra changer notre utilisation actuelle de CouchDB (plein de
choses qu'on ne souhaite pas synchroniser devraient être
définis d'autres manières).



Pour ce qui est de Daybed, on a terminé le set de feature
minimal qui a été review et landé hier soir.



La doc est à jour ici:
[1]http://daybed.readthedocs.org/en/latest/usage.html



On a également une PoC de daybed.js ici:
[2]https://github.com/spiral-project/daybed.js avec des
exemples d'utilisations ici:
[3]https://github.com/spiral-project/daybed.js/blob/master/test
s.js



L'idée est de faire assez rapidement une Daybed Admin qui
permette de naviguer dans les données à partir d'un token.

Oh yeah ;)

References

1. http://daybed.readthedocs.org/en/latest/usage.html
2. https://github.com/spiral-project/daybed.js
3. https://github.com/spiral-project/daybed.js/blob/master/tests.js

Re: [daybed.dev] Daybed, synchro et Couch/PouchDB

From:
Rémy Hubscher
Date:
2014-08-01 @ 09:04
Le 01/08/2014 11:02, Alexis Metaireau a écrit :
>  
>>
>> Pour les permissions je suis d'accord avec toi qu'il vaut mieux
>> garder celles en place sur le serveur distant.
>>
>> Voici ce que je propose en ayant le token *abc* du serveur A qui veut
>> se synchroniser avec le token *zxc* du serveur B.
>>
>> Le modèle *todo* à les permissions suivantes: *{"abc": "ALL",
>> "Everyone": ["read_definition"], "Authenticated":
>> ["read_own_records", "update_own_records", "delete_own_records"],
>> "zte": ["ALL"]}*
>>
>> Avec l'opérationsessionB("zxc").synchroFrom(sessionA("abc")) la
>> première fois,
>>
>> On obtient les ACLs suivants:
>>  
>> *{"zxc": "ALL", "Everyone": ["read_definition"], "Authenticated":
>> ["read_own_records", "update_own_records", "delete_own_records"]}*
>>  
>> Pour les records, la liste d'authors suivante:
>>  
>> *["zte", "abc"] *devient*["zxc"]*
>>  
>> Par suite les acls et authors locaux sont gardés.
>>  
>> Si serveur A possède*["zte", "abc"] et *le serveur B possède *["zxc",
>> "bfe"]* après synchro de
>>  
>> sessionB("gfe").synchroFrom(sessionA("abc"))
>>  
>> On obtient:
>>  
>> *["zxc", "bfe", "gfe"]*
>>  
>> Le nouveau droits: synchro = [ALL]
>  
> En fait ce n'est pas ma proposition. Ma proposition est de laisser les
> nœuds qui se synchronisent gérer leurs permissions eux mêmes, ce qui
> veut dire que les permissions ne seraient pas synchronisés.
>  
> Pour les champs auteurs, ceux cis seraient ajoutés les uns aux autres
> lors de la syncronisation, à priori.
>  
> Mais cela ne convient en fait pas à tous les cas d'usage, on peut
> imaginer avoir plusieurs règles de synchro, qui ont des effets
> différents peut-être ?

En fait c'est ce que tu proposes avec en plus la synchro des ACL pour
Everyone et Authenticated seulement.

>  
>  
>>  
>> J'aime bien l'idée de Hacker un proxy CouchDB externe au code de
>> Daybed (daybed-synchro) qui utiliserait le même storage, avec une
>> validation et une modification des permissions/authors à la volée.
>>  
>> La force de CouchDB c'est de ne synchroniser que les données qui ont
>> été modifiés depuis la dernière synchro. (Il doit utiliser une date
>> pour ça ou des _rev incrémentales)
>>  
>> Il va falloir entrer dans le vif du sujet :)
>  
> Exactement, je ne sais pas encore ce que ça voudra dire de fonctionner
> comme ça, parce que ça veut probablement dire qu'il faudra changer
> notre utilisation actuelle de CouchDB (plein de choses qu'on ne
> souhaite pas synchroniser devraient être définis d'autres manières).
>  
>> Pour ce qui est de Daybed, on a terminé le set de feature minimal qui
>> a été review et landé hier soir.
>>  
>> La doc est à jour ici: http://daybed.readthedocs.org/en/latest/usage.html
>>  
>> On a également une PoC de daybed.js ici:
>> https://github.com/spiral-project/daybed.js avec des exemples
>> d'utilisations ici:
>> https://github.com/spiral-project/daybed.js/blob/master/tests.js
>>  
>> L'idée est de faire assez rapidement une Daybed Admin qui permette de
>> naviguer dans les données à partir d'un token.
> Oh yeah ;)
>