# Compte-rendu rencontre Henry Story / AV

**28 octobre 2019**

*Présents: Henry Story, Simon Louvet (AV), Sébastien Rosset (AV)*

**Simon**

- Contexte:
- On ne peut pas se baser sur le serveur Solid du MIT car il passe par le filesystem.
- On n'a pas réussi à faire une v2 avec un stagiaire, on va repartir de zéro.
- On est en pleine prospective pour trouver les meilleures solutions pour fournir un triple store avec une interface LDP et SparQL, et qui gérerait correctement les droits.

**Henry**
- Ca fait pas mal de temps que je veux réécrire le serveur Read-Write-Web Play (https://github.com/read-write-web/rww-play et https://github.com/read-write-web/rww-play/wiki), basé sur Akka (https://akka.io/). J'aimerais le refaire avec la dernière version d'Akka qui gère HTTP/2.
- Librairie liée : https://github.com/banana-rdf/banana-rdf
- Travaillé sur authentification avec les headers, sans passer par le TLS (HTTP signature), dans le cadre d'un sous-groupe du W3C. Voir https://github.com/solid/authentication-panel/blob/master/HttpSignature.md
- Javascript Crypto API: le client peut créer des clés SSH, s'authentifier avec sa clé.

**Simon**
- On a choisi d'aller sur OIDC (déjà normé et opérationnel) dans un premier temps plutôt que WebID-OIDC ou DID qui sont en cours de normalisation et font face à des travaux qui font bouger les lignes constament. Ce n'est pas décentralisé mais on assume pour le court terme.

**Henry**
- OAuth et OIDC sont les premiers systèmes d'authentification, il y a des choses à récupérer pour faire un système décentralisé.
- Problème: si on a une authentification qui doit être partagée par plusieurs serveur, le serveur A pourrait voler la clé d'authentification du client 1, et l'utiliser sur le serveur B pour obtenir des données.

**Simon**
- Que penses-tu de passer par un triple store ?

**Henry**
- Pour qu'une base de donnée marche bien, il faut pas un triple store mais un quad store.
- Si tu mets tout dans un triple store, tu ne peux plus faire d'access control.
- Si Tim Berners Lee met les fichiers RDF dans le filesystem, c'est parce que ça permet de faire facilement un quad store.
- Akka basé sur les streams, permet d'avoir des centaines de millions d'acteurs avec une très faible consommation de mémoire
- On peut faire beaucoup mieux que ce que fait le MIT
- Je veux refaire un solid Solid en Scala, plus scalable.

**Simon**
- On part plutôt sur du NodeJS mais ça reste ouvert.
- J'aimerais qu'on parle de SparQL. Comment faire pour faire du SparQL sur du multi-ressources ?

**Henry**
- Il y a plein de possibilités, je travaille sur des librairies qui peuvent tout faire.
- Scala peut être compilé en JS (https://www.scala-js.org/) mais a un type system qui est très bien.
- Akka a une interface Scala et une interface Java.

**Simon**
- Inrupt a choisi TypeScript pour son serveur SOLID. Beaucoup plus d'usage que Scala.

**Henry**
- Le mieux est de commencer avec quelque chose de simple.
- Tu peux poser une requête SparQL sur un LDP container. Tu peux avoir un index de ressources et faire une recherche sur toutes ces ressources.
- Jena doit avoir un quad store. Il doit y en avoir d'autres qui sont aussi scalables.
- La flexibilité de Banana RDF permet de faire l'un ou l'autre. On a une abstraction qui permet de switcher, et de faire notre propre implémentation, et de passer de l'un à l'autre facilement.
- C'est pas forcément difficile d'écrire un quad store

**Simon**
- Pour les applications ACL, est-ce que tu as déjà vu un triple store qui peut lire une structure normalisée de triplets, et d'appliquer des droits stockés en triplets ?

**Henry**
- J'ai pas fait beaucoup de recherches. Si Tim ne le fait pas, je suis pas sûr qu'il y en ait d'autres qui le fasse. Peut-être qu'IBM le fait en interne. Ils ont fait la spec LDP mais je sais pas ce qu'ils font en interne. Ces dernières années j'ai surtout fait des maths. Je cherche du travail car les anglais n'ont pas voulu financer mon doctorat.

**Simon**
- On est parti plutôt sur un serveur minimum, avec authentification avec un serveur tiers. Avec interface en React ou web-components qui ne sera pas ontology-driven, avec de la spécification interface bas niveau.
- Presta de court terme, avec le moins de R&D possible, pour avoir des résultats rapides.

**Henry**
- Avec Read-Write-Web on a tout ce qu'il faut pour faire un serveur "off the shelf". Si je trouvais du financement, on pourrait mutualiser. Et travailler plus rapidement à trois sur un serveur Scala minime, qui ait autant de valeur que celui d'Inrupt.
- Les bibliothèques Scala peuvent être compilées en NodeJS, donc on pourrait travailler ensemble mêma avec des langages différents.

**Simon**
- En terme de stratégie, on va plutôt aller vers ce que propose le MIT, et en terme d'authentification on va plutôt se contenter de prendre ce qui existe, car on ne peut pas faire trop de R&D.

**Henry**
- La R&D sur l'authentification, je l'ai déjà bien avancée.
- Ma recherche permettrait de réduire le risque de recherches.
- Pour le front, j'ai un proposal qui s'appelle Launcher App (https://github.com/solid/authorization-and-access-control-panel/blob/master/Proposals/LauncherApp.md).

**Simon**
- Le MIT a développé LDFlex pour le front.

**Henry**
- Je n'ai pas testé LDFlex.
- On pourrait travailler ensemble sur App Launcher. Cela peut être un élément clé dans le système RDF. Pour l'instant il faut une app qui passe par OpenID.

**Simon**
- On peut faire de la coopération sur des bibliothèques Scala compilé en JS, mais il faut se mettre d'accord sur l'API. On tombe des nues lorsqu'on voit qu'aucune solution existe pour gérer les ACL, etc.

**Henry**
- Tim est en train de rendre les gens conscients des possibilités de SOLID. C'est très précieux. Il devrait toutefois être possible de faire 10000 fois mieux que son serveur, en terme de scalabilité, etc.
- Il faut d'abord l'architecture correcte (LDP, etc.), une fois que les gens comprennent l'intérêt, c'est facile de le leur vendre, et d'améliorer par la suite. Il faut faire quelque chose de simple.
- Faire un triple store avec ACL, ça risque d'être de la grosse ingénierie. Il faut faire de la recherche sur quels sont les triple store, est-ce qu'ils ont été bien écrit, etc. Il faut aussi prendre en compte le fait qu'on doit gérer des fichiers (images) qui ne peuvent pas être mis dans un triple store.

**Simon**
- Notre objectif: faire un middleware, qui sert d'interface entre le client et le triple store. Mais utiliser d'autres middleware pour les images et les fichiers.

**Henry**
- Mon serveur Scala, il faudrait le réécrire pour s'adapter en HTTP/2, mais il peut servir de super-middleware. Il faudrait se débarasser de Play qui n'est plus utile, et n'utiliser que Akka.
- Ce serveur pourrait servir d'interface, entre différents clients et différents stores.

**Simon**
- Est-ce qu'on a besoin d'avoir autant de flexibilité alors qu'il suffirait de se conformer à LDP, SparQL, etc. ?

**Henry**
- Je vais voir si j'arrive à trouver de l'argent dans les prochaines semaines. Si j'ai de l'argent, on pourra éventuellement collaborer sur ce projet de serveur Scala.

**Simon**
- Nos trois besoins: une interface LDP classique, des requêtes SparQL multi-containers, et le respect des WACL stockés en triple store.

**Henry**
- Ca doit être possible. Il faut surtout regarder si l'architecture permet de faire ça bien. Faire une requête sur un graphe c'est simple. Une requête multi-container ça veut dire faire une requête sur plusieurs acteurs, et faire un join.
- C'est faire une requête sur plusieurs named graph.

**Simon**
- MIT s'est trouvé coincé à ne pas pouvoir faire de requêtes multi-ressources à cause de son stockage file system.

**Henry**
- Avec HTTP/2 c'est pas forcément un problème de faire de très nombreuses requêtes.
- Avec le filesystem, tu as juste un GET simple, c'est très facile. Tu gères les images de la même manière.
- Dans un graph store, tu te poses tout de suite la question de comment nommer les choses. On part vite dans des délires au niveau du nommage. Tu t'éloignes des principes HTML basiques.
- Si ça devient trop abstrait, les gens perdent la notion d'URL, les ACLs ils vont plus savoir où les mettre.
- Pour indexer des fichiers RDF, il suffit d'envoyer un message à l'indexeur qu'il faut réindexer.
- C'est difficile de travailler efficacement dans le cadre d'une université, c'est pour ça que Tim a créé Inrupt. Un chercheur du MIT il va toujours chercher à faire mieux. Ils perdent encore pas mal d'énergie. Pas simple de lancer un truc comme ça, de lancer une communauté.

**Simon**
- Pistes de coopérations:
- Bibliothèques partagées
- Consultant, sur certains sujets précis
- Si financement de ton côté, des coopérations plus "lourdes".
- On va essayer de voir le maximum d'acteurs avant le 3-4 décembre.

**Henry**
- On peut se faire un RDV dans deux semaines, pour vous dire où j'en suis au niveau financier.
- Je serai en Allemagne début décembre, je pourrai venir le 3-4 décembre si vous pouvez me payer le billet de train.