Laverna: Bifurcación de laverna

Tengo una experiencia de programación decente, pero estoy aprendiendo js y estoy listo para hacer un esfuerzo si es necesario para contribuir a este proyecto, ya que ha sido mi aplicación goto durante mucho tiempo. En cuanto al nombre Laverna2.0 ... Je.

@daed Intentemos escribir primero @wwebfor && @wwwredfish .

Estoy bastante seguro de que pueden agregar a todos los contribuyentes o a usted a la organización para que pueda tener acceso de escritura ...
De lo contrario, avíseme cuando tenga un nombre y un lanzamiento para que pueda crear el paquete AUR: wink:

¿Puede ponerse en contacto conmigo por keybase (preferido) o por correo electrónico para que pueda transmitirle el correo electrónico personal de @wwebfor más tarde hoy (hora de Berlín)?

PD: Si genera una nueva versión en su fork, creo que puede ser una buena idea generar también tarballs: smile:

Si seguro. No quería arrebatarle el proyecto a nadie. Solo quería asegurarme de que no se quedara atrás.

Estoy en la hora central de EE. UU. Hablaré contigo mañana en keybase si puedo.

Entonces, wwebfor me respondió. Terminó con el proyecto.

Reconoció que laverna no resuelve los problemas de sincronización y múltiples dispositivos. Sugirió que sería mejor invertir el esfuerzo centrándose en otros proyectos que ya lo hacen. Tampoco me dio acceso al repositorio, por lo que no puedo hacer nada directamente con él.

Creo que sus preocupaciones son válidas, pero me gusta Laverna y creo que vale la pena intentar sacar algo de eso. Voy a continuar con mi plan de bifurcarlo y desarrollarlo independientemente de la organización de laverna.

He pasado las últimas semanas tratando de familiarizarme con la rama de desarrollo y trabajando en errores menores donde puedo. Honestamente, no está en muy buena forma en este momento:

• Parece que el proyecto estaba en medio de la transición a un modelo más de cliente / servidor con la adición del servidor de señales y mongodb. Ese no es necesariamente un mal modelo para el alojamiento, pero se vuelve una carga para los usuarios finales independientes que están sincronizando a través de Dropbox (o no sincronizan en absoluto).
• El servidor de señales parece haber sido creado con un entorno multiusuario en mente, y están comenzando algunas características útiles (como compartir entre usuarios) pero eso está incompleto, y creo que actualmente inhibe la sincronización entre múltiples dispositivos.
• A pesar de lo anterior, https no está habilitado de forma predeterminada.
• La versión de la aplicación de escritorio basada en electrones no funciona.
• gulp está bastante roto en el nodo 10 debido a dependencias antiguas. Supuestamente, esto se solucionará algún día, aunque el plan actual parece ser forzar una versión más nueva del paquete nativos, que no es compatible. No pude encontrar una ETA.

Me gustaría hablar más sobre estos problemas y obtener recomendaciones / ayuda para solucionarlos. Voy a replicar este problema en mi bifurcación en https://github.com/daed/laverna/issues/1.

Animo encarecidamente a cualquiera que sienta un interés personal en el proyecto a que venga a discutirlo, y me gustaría advertirle a cualquier otra persona que este proyecto, tal como existe en la organización Laverna, probablemente no se actualizará más.

Buen resumen @daed : tada:: estrella:

¡Estoy dentro!

Para referencia: # 931

Hola.
Solía ​​ejecutar Laverna en el pasado y me rendí debido a DropBox. Mis 2 centavos: ir a un modelo de cliente / servidor real con un back-end de base de datos podría ser bueno para prevenir muchos problemas de sincronización. Y esto hará que el proyecto sea casi independiente.

@ romu70 Esa es una de las cosas con las que he estado lidiando. Por alguna razón, nunca tuve los problemas de sincronización de Dropbox de los que escucho quejarse a todos y me gusta el hecho de que no hay un servidor central. El método de Dropbox es algo similar, pero al menos puedo mirar mis notas y ver que están encriptadas. Si una persona o un grupo posee el software y la base de datos, como dentro de un modelo cliente / servidor, se resuelven muchos de los dolores de cabeza necesarios, pero, ¿cómo puede probar que sus datos están realmente protegidos adecuadamente? Una API pública a la que puede enviar mensajes ya cifrados sería una de esas formas, pero eso es lo más lejano en la distancia.

Estaba jugando tratando de encontrar una manera de proporcionarlo de la forma que desee con una versión alojada, una versión Bring Your Own Server y una versión de escritorio independiente, pero parece que va a ser increíblemente difícil de admitir.

Siento que el cliente / servidor es realmente la ruta más rápida y más probable hacia la próxima versión, pero cuanto más avancemos hacia eso, más difícil será implementar una aplicación de escritorio independiente.

Tiendo a estar de acuerdo. Cliente / servidor es bueno si piensa que su producto se instalará en servidores de usuarios. De esta manera, está bastante seguro de que los datos son privados, pero la configuración es menos fácil de seguro.

Con respecto a la aplicación de escritorio, no estoy seguro de que esto dificulte las cosas, solo piense en empaquetar la interfaz con Electron, y ya casi termina.

Estoy impresionado de ver a personas que no conocen esta base de código lista para profundizar en ella. Pero también se puede buscar un camino más fácil, yendo a

La vida es demasiado corta para reinventar la rueda.

Boostnote es bastante hábil, estoy de acuerdo con eso. Es mucho más avanzado y tiene mucho más pulido. Sin embargo, no maneja el cifrado (la solicitud de funciones ha estado abierta por poco menos de un año), y la huella de lo que debe instalarse en una computadora parece mucho más pesada que laverna.

Laverna también se puede usar completamente desde usb y aún así interactuar con Dropbox, incluso si no está instalado. Eso también es bastante bueno. Creo que vale la pena ahorrar mucho aquí, incluso frente a otras herramientas de notas con más recursos que un par de personas obsesionadas.

Un usuario simple aquí, pero la característica clave de Laverna es el cifrado de conocimiento cero con el lema "Mantenga sus notas privadas". Sin eso, también podría volver a Evernote.

De acuerdo, la implementación electrónica del front-end de Laverna fue mucho más fácil de implementar de lo que pensé que sería para la rama de desarrollo. Todavía necesita herramientas de compilación automatizadas (que funcionen), pero es un paso en la dirección correcta.

@glocalglocal ¿Cuál es su definición de "privado"?

¿Se considera "privado" "cifrado pero en un servidor que no es de su propiedad"?
¿Qué pasa con "cifrado pero en su disco duro local"?

Supongo que de una manera indirecta, estoy preguntando si el primero es lo suficientemente bueno, o si el segundo es un requisito para considerar el uso del software. Sin respuestas incorrectas; Necesito la perspectiva del usuario aquí.

La elección siempre es buena. Por lo tanto, definitivamente valdrá la pena el tiempo y el esfuerzo para bifurcar este proyecto a pesar de que existen otras alternativas maduras.

Esto es lo que inicialmente pensé que será el compromiso más flexible y fácil de mantener:

Actualmente en desarrollo:
Laverna tiene dos componentes, tres si cuentas la IU, cuatro si cuentas mongodb (actualmente un requisito). Esa es una expectativa irrazonable para un usuario. El componente de cara al usuario habla con un servidor de señales, que a su vez habla con mongodb. Actualmente, todo lo que hace mongodb es almacenar nombres de usuario y lo que creo que son claves públicas. Todo lo que hace el servidor de señales (que yo sepa) es desacoplar la base de datos del componente que maneja la interfaz de usuario. Esto significa que sería posible para un usuario ejecutar una "gui" de laverna (laverna en electron como ejemplo) y conectarse a un "servidor" / db de laverna público. La implementación multiusuario / multidispositivo parece incompleta, aunque según mis pruebas superficiales. Si está completamente completo de alguna manera, no pude averiguar cómo usarlo, lo que significa que probablemente sea demasiado complicado.

Lo que propongo para el desarrollador:
Fusionamos el servidor de señales y la interfaz de usuario en un solo paquete. Además, creamos versiones electrónicas de este paquete combinado. Procesamos todos los datos a través del servidor de señales a la base de datos. Notas, cuadernos, archivos de configuración de respaldo, todo excepto la clave privada. Incluimos la configuración que le permite iniciar una interfaz de usuario, un servidor de señales o ambos. Además, construimos un adaptador para que el servidor de señales pueda manejar conexiones sqlite3.

Esto toma laverna y te permite convertirla en lo que quieras. Las tres configuraciones obvias con este esquema que puede elegir entre cualquiera de:

1. Totalmente administrado: la interfaz de usuario, el servidor de señales y la base de datos se ejecutan en un servidor en algún lugar. Te conectas a través del navegador. Esto es básicamente más o menos lo que es hoy laverna.cc. Obtiene la mayor comodidad y no necesita descargar / instalar nada, pero tiene la menor transparencia y debe confiar ciegamente en el administrador de su servidor. Voy a llamar a esto la "configuración de Evernote".
2. cliente / servidor: la interfaz de usuario se ejecuta en la computadora del cliente a través de un nodo o electrón, el servidor de señales y la base de datos se ejecutan en un servidor en algún lugar. Tiene almacenamiento centralizado y tiene disponibles todas las funciones de colaboración que podrían incluirse en el futuro, y es propietario del cliente de interfaz de usuario, que puede crear desde la fuente para tener una expectativa razonable de que la seguridad se mantiene en el nivel del cliente. Este es probablemente el mejor compromiso de características, conveniencia y seguridad. Esto se parece vagamente a cómo entiendo el funcionamiento de la base de claves.
3. Totalmente independiente: la interfaz de usuario, el servidor de señales y la base de datos se ejecutan en una sola caja. El nodo o el electrón inician la interfaz de usuario y el servidor de señales cuando los ejecuta. La base de datos es su elección de mongodb o si desea la opción fácil, sin instalación adicional, puede elegir sqlite3. Volcamos completamente el método de la API de Dropbox y optamos por la sincronización de Dropbox a través del sistema de archivos. Si desea que Dropbox se sincronice, puede optar por colocar la base de datos en el directorio de Dropbox en la ruta que le parezca mejor. Si desea que sus notas se escriban en una unidad flash o NFS o / dev / null, simplemente dígale que lo haga. Esto es probablemente lo más parecido a cómo funciona la versión actual de laverna en este momento.

Tenga en cuenta que utilizo "cliente" y "ui" arriba indistintamente.

Mi única preocupación real es la solidez de sqlite3, especialmente cuando se sincroniza a través de Dropbox. Sin embargo, tengo la corazonada (y solo la corazonada) de que la mayoría de los problemas de sincronización que la gente ha tenido con Dropbox están relacionados con la API, y simplemente cambiar a la aplicación / sistema de archivos para acceder a Dropbox curará muchos de esos dolores.

Eso es mucho para repasar, y probablemente no soy el mejor para explicar mis pensamientos, pero ¿preguntas? ¿Preocupaciones? Comentarios

@daed desde la perspectiva de un usuario, siempre que el cifrado sea lo suficientemente fuerte y transparente, la base de datos se puede almacenar en cualquier lugar y eso no me plantearía problemas de privacidad.

Yo preferiría el modelo cliente / servidor (2), con sus clientes móviles y de escritorio de código abierto para el escrutinio / auditoría, y el almacenamiento en el servidor para la portabilidad y la capacidad de compartir. A menudo, las aplicaciones ofrecen el modelo independiente (3) como opción. ¿No podría también almacenarse opcionalmente la copia local de la base de datos en el modelo 2 en una carpeta de Dropbox, MEGA, etc.? Eso funcionaría incluso si el servidor desaparece para siempre.

En el modelo (1), ¿el cifrado / descifrado del lado del cliente no resuelve el problema de confianza? por ejemplo, Lastpass, Bitwarden. Eso es asumiendo que se analiza lo que se ejecuta en el navegador. El modelo (1) sería conveniente en determinadas circunstancias.

Para el modelo 1:
El 'cliente' en este caso es solo un navegador web 'tonto' que se conecta a la interfaz de usuario de laverna. Eso nos da dos opciones.

• Podemos pedirle al usuario la ruta a su clave privada para que podamos leerla (localmente) y hacer la criptografía en js del lado del navegador antes de entregar el mensaje a la instancia del nodo que ejecuta la interfaz de usuario de laverna, lo cual es inconveniente ya que para empezar, requiere archivos locales que anulan el propósito de una configuración totalmente alojada. Esto sería algo similar a cómo funciona github, pero técnicamente github todavía tiene un cliente con git / ssh.
• O podemos hacer que el servidor mantenga / administre su clave privada (pero NUNCA su frase de contraseña) y luego hacemos las cosas 100% de forma remota. Puede descargar / cambiar su clave privada, pero también debe confiar en que no mantenemos la frase de contraseña y que no arruinaremos la seguridad de su clave. Creo que esto está más cerca de cómo se implementa ahora. Esto es básicamente un evernote gratuito con condiciones de servicio más amigables y un ambiente de código abierto para sentirse bien. No es ideal, pero podría ser suficiente para algunos.

Puede que haya más opciones, pero no estoy seguro de cuáles serían en este momento. Lastpass / Bitwarden almacenan y ocultan contraseñas, pensé. Esa es una función de encriptación que podría usarse junto con esto, pero no resuelve el problema de administración de claves. Nunca los he usado, por lo que es posible que no entienda completamente su utilidad.
Dicho todo esto, probablemente estableceré un servidor "oficial" como este en AWS o algo por si acaso es lo suficientemente bueno para algunas personas, si no para todas. Me imagino que evernote gratis, incluso con algunos problemas de confianza, sería más que suficiente para algunos usuarios. Tal vez presione un botón de donación y vea si alguna vez recupero los costos de alojamiento.

Para el modelo 2:
Esta es en realidad mi implementación favorita de las tres posibles. Técnicamente, todavía es necesario instalar cero software en la computadora. Puede ejecutar laverna desde una unidad USB y guardar su clave allí. Incluso podría incrustarlo en una unidad USB con colas instaladas si quisiera llegar tan lejos para las computadoras públicas.
No había considerado una copia local, pero en mi lista había algún tipo de función de importación / exportación / copia de seguridad de notas, por lo que ambos encajan muy bien. Si su servidor desapareció, podría simplemente cambiar al modelo 3 e importar las notas y continuar como si nada. Puede ser un poco extraño pasar de los datos almacenados en mongodb a algún formato local, pero probablemente sea algo con lo que se pueda tratar.

Como actualización general, anoche hice una aplicación electrónica de prueba de concepto con la interfaz de usuario y el servidor de señales integrados y ambos se iniciaron al inicio. Está completamente sin pulir y totalmente inadecuado para su lanzamiento, pero me ha demostrado que era 100% posible seguir teniendo el modelo 3 con muy poco esfuerzo adicional.

Creo que si vamos con el esquema del modelo 3, crearé paquetes para una versión de "servidor" que contenga la interfaz de usuario de laverna y las cosas del servidor y no electrón, así como una versión de "cliente" que contendrá los componentes para todo también. como electrón. Para la versión del servidor, la configuración deberá realizarse mediante la edición de archivos, pero será capaz de proporcionar componentes del lado del servidor para el modelo 1 o el modelo 2, mientras que la versión del cliente tendrá una página de configuración de interfaz de usuario / asistente y será capaz de proporcionar componentes para el cliente para el modelo 2, así como la implementación completa del modelo 3.

Esta conversación ha sido útil, pero permanecer en este repositorio de Laverna no es particularmente útil ya que no puedo hacer nada con él. Seguiré revisando aquí para ver si alguien publica algo nuevo, pero si quieres seguir hablando de esto (¡y espero que todos lo hagan!), Les pediría que lo hagamos en el mío en https://github.com/daed. / laverna / issues / 1.

Y gracias a todos.

No sé qué significa Forking (¿y no estoy seguro de si debería hacerlo?) Pero de todos modos; Probé la aplicación laverna y parece que la sincronización no funciona con ella. Lo estaba intentando con 5storage. Parece que hay otra versión de Android en otra página pero no hay lanzamiento, tengo que construirla y con mi escaso conocimiento simplemente falló.

@xreqx Significa que el proyecto está muerto, y estoy tomando el código y comenzando de nuevo por mi cuenta (con quien más quiera ayudar).

Sinceramente, todavía no he mirado la versión móvil. Realmente no tengo ninguna experiencia con la escritura de aplicaciones móviles para ser honesto. Sin embargo, es algo que me gustaría poner a trabajar.

valdría la pena mencionar el archivo estándar ; la biblioteca utilizada por las notas estándar .

Standard File es una biblioteca de sincronización y cifrado para aplicaciones web y nativas. Permite a los desarrolladores centrarse en la creación de excelentes aplicaciones orientadas al usuario y deja la sincronización, los servidores y el cifrado de extremo a extremo en esta biblioteca.
..
Standard File es un sistema de servidor y cliente reutilizable que le permite implementar un servidor backend "tonto" que no conoce ni se preocupa por su esquema de datos, y le permite cifrar datos en el lado del cliente y sincronizarlos con el servidor remoto. .

Entonces, wwebfor me respondió. Terminó con el proyecto.

Tenga en cuenta que creé esta wikipage hace un tiempo. He vinculado a tu comentario:
https://github.com/Laverna/laverna/wiki/DEAD-PROJECT-ALERT