Laverna: Laverna bifurquant

J'ai une bonne formation en programmation, mais je viens d'apprendre js et je suis prêt à faire des efforts si nécessaire pour contribuer à ce projet car c'est mon application goto depuis longtemps maintenant. Quant au nom Laverna2.0... Heh.

@daed Essayons d'abord d'écrire @wwebfor && @wwwredfish .

Je suis presque sûr qu'ils peuvent ajouter tous les contributeurs ou vous à l'organisation afin que vous puissiez avoir un accès en écriture...
Sinon faites le moi savoir quand vous avez un nom et une par version pour que je puisse créer le package AUR :wink:

Pouvez-vous me contacter sur keybase (de préférence) ou par email afin que je puisse vous transmettre l'email personnel de @wwebfor plus tard dans la

PS: Si vous générez une nouvelle version sur votre fork, je pense que cela peut être une bonne idée de générer également des tarballs :smile:

Oui bien sûr. Je ne voulais arracher le projet à personne. Je voulais juste m'assurer qu'il ne soit pas laissé pour compte.

Je suis à l'heure du centre des États-Unis. Je te parlerai demain sur keybase si je peux.

Alors, wwebfor m'a répondu. Il en a fini avec le projet.

Il a reconnu que laverna ne résout pas les problèmes de synchronisation et de plusieurs appareils. Il a suggéré que les efforts seraient mieux dépensés en se concentrant sur d'autres projets qui le font déjà. Il ne m'a pas non plus donné accès au repo, donc je ne peux rien faire directement avec.

Je pense que ses inquiétudes sont valables, mais j'aime laverna et je pense que cela vaut la peine d'essayer d'en tirer quelque chose. Je vais continuer avec mon plan de le forger et de le développer indépendamment de l'organisation laverna.

J'ai passé les dernières semaines à essayer de me familiariser avec la branche dev et à travailler sur des bogues mineurs là où je le pouvais. Il n'est honnêtement pas en très bonne forme en ce moment :

• Il semble que le projet était en train de passer à un modèle client/serveur avec l'ajout du serveur de signaux et de mongodb. Ce n'est pas nécessairement un mauvais modèle pour l'hébergement, mais cela devient fastidieux pour les utilisateurs finaux autonomes qui se synchronisent via Dropbox (ou pas du tout).
• Le serveur de signaux semble avoir été mis en place avec un environnement multi-utilisateurs à l'esprit, et il y a le début de certaines fonctionnalités utiles (comme le partage entre utilisateurs) mais c'est incomplet, et je pense qu'en fait, cela empêche actuellement la synchronisation entre plusieurs appareils.
• Malgré ce qui précède, https n'est pas activé par défaut.
• La version de l'application de bureau électronique ne fonctionne pas.
• gulp est assez cassé dans le nœud 10 en raison d'anciennes dépendances. Soi-disant, cela sera corrigé un jour, bien que le plan actuel semble être de forcer une version plus récente du package natif, qui n'est pas pris en charge. Je n'ai pas trouvé d'ETA.

J'aimerais parler davantage de ces problèmes et obtenir des recommandations/de l'aide pour les résoudre. Je vais reproduire ce problème sur mon fork à l' adresse https://github.com/daed/laverna/issues/1.

J'encourage fortement tous ceux qui ressentent un intérêt pour le projet à venir en discuter, et j'aimerais avertir quiconque que ce projet, tel qu'il existe au sein de l'organisation Laverna, ne sera probablement plus mis à jour.

Joli résumé @daed :tada: :star:

J'en suis!

Pour référence : #931

Salut.
J'ai utilisé Laverna dans le passé et j'ai abandonné à cause de DropBox. Mes 2 centimes : passer à un vrai modèle client/serveur avec un back-end de base de données pourrait être utile pour éviter de nombreux problèmes de synchronisation. Et cela rendra le projet presque indépendant.

@ romu70 C'est l'une des choses avec

J'essayais de trouver un moyen de le fournir comme vous le souhaitez avec une version hébergée, une version Apportez votre propre serveur et une version de bureau autonome, mais cela semble être incroyablement difficile à prendre en charge.

J'ai l'impression que le client/serveur est vraiment la voie la plus rapide et la plus probable vers la prochaine version, mais plus nous avançons vers cela, plus une application de bureau autonome sera difficile à mettre en œuvre.

J'ai tendance à être d'accord. Client/serveur est bon si vous pensez que votre produit doit être installé sur les serveurs des utilisateurs. De cette façon, vous êtes sûr que les données sont privées, mais la configuration est certainement moins facile.

En ce qui concerne l'application de bureau, je ne suis pas sûr que cela complique les choses, pensez simplement à emballer le front-end avec Electron, et vous avez presque terminé.

Je suis impressionné de voir des gens qui ne connaissent pas cette base de code prêts à s'y plonger. Mais on peut aussi parler d'un chemin plus simple, aller sur Boostnote qui propose déjà la même chose (DropBox sync), avec une base de code déjà bien entretenue, une communauté, un support, etc.

La vie est trop courte pour réinventer la roue.

Boostnote est assez lisse, je suis d'accord avec ça. Il est beaucoup plus avancé et a beaucoup plus de polissage. Cependant, il ne gère pas le cryptage (la demande de fonctionnalité est ouverte depuis un peu moins d'un an), et l'empreinte de ce qui doit être installé sur un ordinateur semble beaucoup plus lourde que laverna.

Laverna peut également être utilisé complètement à partir de l'usb et interagir toujours avec Dropbox, même s'il n'est pas installé. C'est assez chouette aussi. Je pense qu'il y a beaucoup à économiser ici, même face à d'autres outils de notes avec plus de ressources que quelques personnes obsédées.

Un simple utilisateur ici, mais la caractéristique clé de Laverna est le cryptage à connaissance nulle avec le slogan « Gardez vos notes privées ». Sans cela, je pourrais aussi bien retourner sur Evernote.

D'accord, l'implémentation électronique du front-end laverna était beaucoup plus facile à implémenter que je ne le pensais pour la branche dev. Il a encore besoin d'outils de construction automatisés (qui fonctionnent), mais c'est un pas dans la bonne direction.

@glocalglocal Quelle est votre définition de « privé » ?

Est-ce que « crypté mais sur un serveur que vous ne possédez pas » est-il considéré comme « privé » ?
Qu'en est-il de « crypté mais sur votre disque dur local » ?

Je suppose que d'une manière détournée, je demande si le premier est assez bon, ou si le second est une exigence pour considérer le logiciel à utiliser ? Pas de mauvaises réponses ; J'ai besoin du point de vue de l'utilisateur ici.

Le choix est toujours bon. Il vaudra donc certainement la peine de consacrer du temps et des efforts à ce projet malgré le fait qu'il existe d'autres alternatives matures.

Voici ce que je pense initialement être le compromis le plus flexible et le plus maintenable :

Actuellement en développement :
Laverna est composé de deux composants, trois si vous comptez l'interface utilisateur, quatre si vous comptez mongodb (actuellement une exigence). C'est une attente déraisonnable à mettre sur un utilisateur. Le composant orienté utilisateur parle à un serveur de signaux, qui à son tour parle à mongodb. Actuellement, tout ce que mongodb fait est de stocker les noms d'utilisateur et ce que je pense être des clés publiques. Tout ce que fait le serveur de signaux (à ma connaissance) est de découpler la base de données du composant qui gère l'interface utilisateur. Cela signifie qu'il serait possible pour un utilisateur d'exécuter un "gui" laverna (laverna en électron par exemple) et de se connecter à un "serveur" / db laverna public. La mise en œuvre multi-utilisateurs / multi-périphériques semble incomplète, bien que basée sur mes tests superficiels. S'il EST complètement complet d'une manière ou d'une autre, je ne pouvais pas comprendre comment l'utiliser, ce qui signifie que c'est probablement beaucoup trop compliqué.

Ce que je propose pour le dev :
Nous fusionnons le serveur de signaux et l'interface utilisateur en un seul package. De plus, nous construisons des versions électroniques de ce package fusionné. Nous traitons toutes les données via le serveur de signaux vers la base de données. Notes, cahiers, fichiers de configuration de sauvegarde, tout sauf la clé privée. Nous incluons une configuration vous permettant de démarrer une interface utilisateur, un serveur de signaux ou les deux. De plus, nous construisons un adaptateur pour que le serveur de signaux puisse gérer les connexions sqlite3.

Cela prend laverna et vous permet de le transformer en tout ce que vous voulez. Les trois configurations évidentes avec ce schéma que vous pouvez choisir parmi :

1. entièrement géré : l'interface utilisateur, le serveur de signaux et la base de données s'exécutent tous sur un serveur quelque part. Vous vous connectez via un navigateur. C'est plus ou moins ce qu'est laverna.cc aujourd'hui. Vous obtenez le plus de commodité et n'avez pas besoin de télécharger / d'installer quoi que ce soit, mais vous avez le moins de transparence et devez faire confiance aveugle à votre administrateur de serveur. Je vais appeler cela la "configuration Evernote".
2. client / serveur : l'interface utilisateur s'exécute sur l'ordinateur client via un nœud ou un électron, le serveur de signaux et la base de données s'exécutent sur un serveur quelque part. Vous disposez d'un stockage centralisé et de toutes les fonctionnalités de collaboration qui pourraient être incluses sur toute la ligne, et vous possédez le client d'interface utilisateur, que vous pouvez créer à partir de la source pour avoir une attente raisonnable que la sécurité est maintenue au niveau du client. C'est probablement le meilleur compromis entre fonctionnalités, commodité et sécurité. Cela ressemble vaguement à la façon dont je comprends que keybase fonctionne.
3. entièrement autonome : l'interface utilisateur, le serveur de signaux et la base de données fonctionnent tous sur un seul boîtier. Le nœud ou l'électron démarre l'interface utilisateur et le serveur de signaux pour vous lorsque vous les exécutez. La base de données est votre choix de mongodb ou si vous voulez l'option facile et sans installation supplémentaire, vous pouvez choisir sqlite3. Nous abandonnons complètement la méthode api de dropbox et optons pour la synchronisation de dropbox via le système de fichiers. Si vous souhaitez que dropbox se synchronise, vous pouvez choisir de placer la base de données dans le répertoire dropbox à n'importe quel chemin qui vous convient. Si vous voulez que vos notes soient écrites sur un lecteur flash ou NFS ou /dev/null, dites-lui simplement de le faire. C'est probablement ce qui se rapproche le plus du fonctionnement de la version actuelle de laverna en ce moment.

Notez que j'utilise indifféremment "client" et "ui" ci-dessus.

Ma seule vraie préoccupation est la robustesse de sqlite3, en particulier lors de la synchronisation sur Dropbox. J'ai l'intuition (et seulement l'intuition) que la plupart des problèmes de synchronisation que les gens ont rencontrés avec Dropbox sont liés à l'API, et le simple fait de passer à l'application / au système de fichiers pour accéder à la boîte de dépôt résoudra beaucoup de ces douleurs.

C'est beaucoup à revoir, et je ne suis probablement pas le meilleur pour expliquer mes pensées, mais des questions ? Des inquiétudes ? Commentaires?

@daed du point de vue de l'utilisateur, tant que le cryptage est suffisamment fort et transparent, la base de données peut être stockée n'importe où et cela ne soulèverait pas de problèmes de confidentialité pour moi.

Je privilégierais le modèle client/serveur (2), avec ses clients de bureau et mobiles open source pour l'examen/l'audit, et le stockage sur serveur pour la portabilité et le partage. Souvent, les applications proposent le modèle autonome (3) en option. La copie locale de la base de données dans le modèle 2 ne pourrait-elle pas également être stockée en option dans un dossier Dropbox, MEGA, etc.? Cela fonctionnerait même si le serveur disparaissait pour toujours.

Sur le modèle (1), le chiffrement/déchiffrement côté client ne résout-il pas le problème de confiance ? par exemple Lastpass, Bitwarden. Cela suppose que ce qui s'exécute sur le navigateur est scruté. Le modèle (1) serait pratique dans certaines circonstances.

Pour le modèle 1 :
Le « client » dans ce cas est juste un navigateur Web « idiot » qui se connecte à l'interface utilisateur de laverna. Cela nous donne deux options.

• Nous pouvons soit demander à l'utilisateur le chemin d'accès à sa clé privée afin que nous puissions la lire (localement) et faire le crypto dans brower-side js avant de transmettre le message à l'instance de nœud exécutant l'interface utilisateur laverna, ce qui est gênant car il nécessite des fichiers locaux, ce qui va à l'encontre de l'objectif d'une configuration entièrement hébergée pour commencer. Ce serait un peu similaire au fonctionnement de github, mais techniquement, github a toujours un client avec git/ssh.
• Ou, nous pouvons demander au serveur de conserver/gérer votre clé privée (mais JAMAIS votre mot de passe) et ensuite nous faisons les choses à 100 % à distance. Vous pouvez télécharger/modifier votre clé privée, mais vous devez également être sûr que nous ne conservons pas la phrase secrète et que nous ne gâcherons pas la sécurité de votre clé. C'est plus proche de la façon dont il est mis en œuvre maintenant, je pense. Il s'agit essentiellement d'evernote gratuit avec des conditions d'utilisation plus conviviales et une ambiance open source de bien-être. Pas idéal, mais pourrait être suffisant pour certains.

Il pourrait y avoir plus d'options, mais je ne suis pas sûr de ce qu'elles seraient pour le moment. Lastpass / Bitwarden stocke et masque les mots de passe, pensais-je. C'est une fonction de cryptage qui pourrait être utilisée en conjonction avec cela, mais cela ne résout pas le problème de gestion des clés. Je n'en ai jamais utilisé non plus, il est donc possible que je ne comprenne pas bien leur utilité.
Cela étant dit, je vais probablement configurer un serveur "officiel" comme celui-ci sur AWS ou quelque chose au cas où cela conviendrait à certaines personnes, voire à toutes. J'imagine qu'evernote gratuit, même avec quelques problèmes de confiance, serait plus que suffisant pour certains utilisateurs. Peut-être mettre un bouton de don dessus et voir si je récupère un jour les coûts d'hébergement.

Pour le modèle 2 :
C'est en fait ma mise en œuvre préférée des trois possibles. Techniquement, aucun logiciel n'a encore besoin d'être installé sur l'ordinateur. Vous pouvez exécuter laverna à partir d'une clé USB et y conserver votre clé. Vous pouvez même l'intégrer dans une clé USB avec des queues installées dessus si vous vouliez aller aussi loin pour les ordinateurs publics.
Je n'avais pas envisagé une copie locale, mais une sorte de fonction d'importation/exportation/sauvegarde de notes figurait sur ma liste, donc ces deux types s'harmonisent bien. Si votre serveur est parti, vous pouvez simplement passer au modèle 3 et importer les notes et continuer comme si de rien n'était. Cela peut être un peu étrange de passer des données stockées dans mongodb à un format local, mais c'est probablement quelque chose qui peut être traité.

Comme mise à jour générale, j'ai fait une preuve de concept d'application électronique tard hier soir avec l'interface utilisateur et le serveur de signaux intégrés et les deux lancés au démarrage. C'est entièrement sans vernis et totalement impropre à la sortie, mais cela m'a montré qu'il était 100% possible d'avoir toujours le modèle 3 avec très peu d'effort supplémentaire.

Je pense que si nous suivons le schéma du modèle 3, je créerai des packages pour une version "serveur" qui contient l'interface utilisateur et le serveur laverna et aucun électron, ainsi qu'une version "client" qui contiendra également les composants pour tout comme électron. Pour la version serveur, la configuration devra être effectuée en éditant des fichiers, mais elle sera capable de fournir des composants côté serveur pour le modèle 1 ou le modèle 2, tandis que la version client aura une page/un assistant de configuration de l'interface utilisateur et sera capable de fournir composants pour le client pour le modèle 2 ainsi que la mise en œuvre complète du modèle 3.

Cette conversation a été utile, mais rester sur ce dépôt laverna n'est pas particulièrement utile car je ne peux rien faire avec. Je vais quand même vérifier ici pour voir si quelqu'un publie quelque chose de nouveau, mais si vous voulez continuer à en parler (et j'espère que tout le monde le fait !), je demanderais que nous le fassions chez moi à l' adresse https://github.com/daed /laverna/issues/1.

Et merci à tous.

Je ne sais pas ce que signifie Forking (et je ne suis pas sûr que je devrais ?) mais quand même ; J'ai essayé laverna apk et il semble que la synchronisation ne fonctionnera pas avec. Je l'essayais avec 5storage. Il semble y avoir une autre version Android sur une autre page mais pas de version, je dois la construire et avec mes mauvaises connaissances, elle a échoué.

@xreqx Cela signifie que le projet est mort, et je prends le code et le redémarre par moi-même (avec quiconque veut m'aider).

Honnêtement, je n'ai pas encore regardé la version mobile. Pour être honnête, je n'ai pas vraiment d'expérience dans l'écriture d'applications mobiles. C'est quelque chose que j'aimerais travailler cependant.

il peut être intéressant de mentionner le fichier standard ; la bibliothèque utilisée par les notes standard .

Standard File est une bibliothèque de synchronisation et de chiffrement pour les applications Web et natives. Il permet aux développeurs de se concentrer sur la création de superbes applications destinées aux utilisateurs et laisse la synchronisation, les serveurs et le cryptage de bout en bout à cette bibliothèque.
..
Le fichier standard est un système client et serveur réutilisable qui vous permet de déployer un serveur principal « muet » qui ne connaît pas ou ne se soucie pas de votre schéma de données, et vous permet de crypter les données côté client et de les synchroniser avec le serveur distant .

Alors, wwebfor m'a répondu. Il en a fini avec le projet.

Remarque, j'ai créé cette page wiki il y a quelque temps. J'ai mis un lien vers votre commentaire :
https://github.com/Laverna/laverna/wiki/DEAD-PROJECT-ALERT