Laverna: Laverna bifurcada

Tenho um histórico de programação decente, mas estou apenas aprendendo js e estou pronto para me esforçar se necessário para contribuir com este projeto, pois tem sido meu aplicativo goto por um longo tempo. Quanto ao nome Laverna2.0 ... Heh.

@daed Vamos tentar escrever @wwebfor && @wwwredfish primeiro.

Tenho certeza de que eles podem adicionar todos os colaboradores ou você à organização para que você possa ter acesso de escrita ...
Caso contrário, avise-me quando tiver um nome e um por lançamento para que eu possa criar o pacote AUR: wink:

Você pode me contatar no keybase (preferencial) ou por e-mail para que eu possa transmitir o e-mail pessoal de @wwebfor para você mais tarde hoje (horário de Berlim)?

PS: Se você gerar uma nova versão em seu fork, acho que pode ser uma boa ideia gerar tarballs: smile:

Sim claro. Eu não queria arrancar o projeto de ninguém. Eu só queria ter certeza de que não foi deixado para trás.

Estou no horário da região central dos EUA. Falo com você amanhã no teclado, se puder.

Então, wwebfor voltou para mim. Ele concluiu o projeto.

Ele reconheceu que o laverna não resolve problemas com sincronização e vários dispositivos. Ele sugeriu que o esforço seria melhor gasto com foco em outros projetos que já o fazem. Ele também não me deu acesso ao repo, então não posso fazer nada diretamente com ele.

Acho que as preocupações dele são válidas, mas gosto de laverna e acho que vale a pena tentar fazer alguma coisa com ela. Vou continuar com meu plano de bifurcá-lo e desenvolvê-lo independentemente da organização laverna.

Passei as últimas semanas tentando me familiarizar com o branch dev e trabalhando em pequenos bugs sempre que posso. Sinceramente, não está em muito boa forma agora:

• Parece que o projeto estava no meio de uma transição para um modelo mais cliente / servidor com a adição do servidor de sinal e mongodb. Esse não é necessariamente um modelo ruim para hospedagem, mas se torna oneroso para usuários finais autônomos que estão sincronizando por meio da caixa de depósito (ou não estão sincronizando).
• O servidor de sinal parece ter sido criado com um ambiente multiusuário em mente, e há o início de alguns recursos úteis (como compartilhamento entre usuários), mas isso está incompleto, e acredito que atualmente inibe a sincronização entre vários dispositivos.
• Apesar do acima, https não é habilitado por padrão.
• A versão do aplicativo de desktop baseado em elétrons não funciona.
• o gulp está bastante danificado no nó 10 devido a antigas dependências. Supostamente, isso será consertado algum dia, embora o plano atual pareça ser forçar uma versão mais recente do pacote nativos, que não é compatível. Não consegui encontrar um HEC.

Gostaria de falar mais sobre esses problemas e obter recomendações / ajuda para corrigi-los. Vou replicar esse problema na minha bifurcação em https://github.com/daed/laverna/issues/1.

Eu encorajo fortemente qualquer pessoa que sinta um grande interesse no projeto a vir discuti-lo, e eu gostaria de avisar a todos que este projeto, como existe na organização Laverna, provavelmente não será mais atualizado.

Belo resumo @daed : tada:: star:

Estou dentro!

Para referência: # 931

Oi.
Eu costumava rodar o Laverna no passado e desisti por causa do DropBox. Meus 2 centavos: ir para um modelo cliente / servidor real com um back-end de banco de dados pode ser bom para prevenir muitos problemas de sincronização. E isso tornará o projeto quase independente.

@ romu70 Essa é uma das coisas com que tenho lutado. Por alguma razão, nunca tive os problemas de sincronização da caixa de depósito, dos quais todo mundo reclama e gosto do fato de não haver um servidor central. O método da caixa de depósito é meio semelhante, mas posso pelo menos olhar minhas anotações e ver que estão criptografadas. Se uma pessoa ou grupo possui o software e o banco de dados, como em um modelo cliente / servidor, isso resolve muitas das dores de cabeça necessárias, mas como provar que seus dados realmente estão sendo protegidos de forma adequada? A API pública para a qual você pode enviar mensagens já criptografadas seria uma dessas formas, mas isso é o que há de mais distante.

Eu estava tentando encontrar uma maneira de fornecê-lo da maneira que você quiser com uma versão hospedada, uma versão Traga seu próprio servidor e uma versão desktop autônoma, mas parece que vai ser incrivelmente difícil de suportar.

Eu sinto que o cliente / servidor é realmente o caminho mais rápido e mais provável para o próximo lançamento, mas quanto mais avançamos nessa direção, mais difícil será implementar um aplicativo de desktop independente.

Eu tendo a concordar. Cliente / servidor é bom se você pensa em seu produto para ser instalado em servidores de usuários. Desta forma, você tem certeza de que os dados são privados, mas a configuração é menos fácil com certeza.

Em relação ao aplicativo de desktop, não tenho certeza se isso torna as coisas mais difíceis, apenas pense em empacotar o front-end com Electron e está quase pronto.

Estou impressionado em ver pessoas que não conhecem essa base de código prontas para investigá-lo. Mas pode-se também encontrar um caminho mais fácil, indo para o Boostnote que já oferece a mesma coisa (DropBox sync), com uma base de código já bem mantida, comunidade, suporte, etc.

A vida é muito curta para reinventar a roda.

O Boostnote é muito bom, concordo com isso. Está muito mais avançado e tem muito mais polimento. Porém, ele não lida com criptografia (a solicitação de recurso está aberta há pouco menos de um ano), e a pegada do que precisa ser instalado em um computador parece muito mais pesada do que o laverna.

Laverna também pode ser usado completamente a partir de usb e ainda interagir com o Dropbox, mesmo se não estiver instalado. Isso também é muito legal. Acho que vale a pena economizar muito aqui, mesmo em face de outras ferramentas de anotações com mais recursos do que algumas pessoas fixas.

Um usuário simples aqui, mas a principal característica do Laverna é a criptografia de conhecimento zero com a linha 'Keep your notes private'. Sem isso, posso voltar ao Evernote.

Ok, a implementação de elétrons do front-end laverna foi muito mais fácil de implementar do que eu pensei que seria para o ramo dev. Ele ainda precisa de ferramentas de compilação automatizadas (funcionando), mas é um passo na direção certa.

@glocalglocal Qual é a sua definição de "privado"?

É "criptografado, mas em um servidor que você não possui" considerado "privado"?
Que tal "criptografado, mas em seu disco rígido local"?

Eu acho que de uma forma indireta, estou perguntando se o primeiro é bom o suficiente, ou se o segundo é um requisito para considerar o software para uso? Sem respostas erradas; Preciso da perspectiva do usuário aqui.

A escolha é sempre boa. Portanto, definitivamente valerá a pena o tempo e esforço para bifurcar este projeto, apesar de haver outras alternativas maduras.

Aqui está o que estou inicialmente pensando que será o compromisso mais flexível e sustentável:

Atualmente em desenvolvimento:
Laverna tem dois componentes, três se você contar a IU, quatro se você contar o mongodb (atualmente um requisito). Essa é uma expectativa irracional de um usuário. O componente voltado para o usuário se comunica com um servidor de sinal, que por sua vez se comunica com o mongodb. Atualmente, tudo que o mongodb faz é armazenar nomes de usuário e o que eu acho que são chaves públicas. Tudo o que o servidor de sinal faz (que eu saiba) é desacoplar o banco de dados do componente que controla a interface do usuário. Isso significa que seria possível para um usuário executar uma laverna "gui" (laverna em elétron, por exemplo) e se conectar a um "servidor" / db de laverna público. A implementação multiusuário / multi-dispositivo parece incompleta, embora com base em meus testes superficiais. Se estiver totalmente completo de alguma forma, não consegui descobrir como usá-lo, o que significa que provavelmente é muito complicado.

O que proponho para dev:
Nós mesclamos o servidor de sinal e a IU juntos em um pacote. Além disso, construímos versões eletrônicas desse pacote mesclado. Processamos todos os dados através do servidor de sinal para o banco de dados. Notas, notebooks, arquivos de configuração de backup, tudo, exceto a chave privada. Incluímos a configuração que permite iniciar uma IU, um servidor de sinal ou ambos. Além disso, construímos um adaptador para o servidor de sinal ser capaz de lidar com conexões sqlite3.

Isso leva laverna e permite transformá-lo em qualquer coisa que quiser. As três configurações óbvias com este esquema para que você possa escolher qualquer uma das seguintes:

1. totalmente gerenciado: UI, servidor de sinal e banco de dados, todos executados em um servidor em algum lugar. Você se conecta via navegador. Isso é basicamente mais ou menos o que laverna.cc é hoje. Você obtém mais comodidade e não precisa baixar / instalar nada, mas tem o mínimo de transparência e tem que confiar cegamente no administrador do servidor. Vou chamar isso de "configuração do Evernote".
2. cliente / servidor: a IU é executada no computador cliente via nó ou elétron, servidor de sinal e banco de dados executado em um servidor em algum lugar. Você tem armazenamento centralizado e tem disponíveis quaisquer recursos de colaboração que possam ser incluídos no futuro, e você possui o cliente UI, que pode construir a partir da origem para ter uma expectativa razoável de que a segurança está sendo mantida no nível do cliente. Este é provavelmente o melhor compromisso em termos de recursos, conveniência e segurança. Isso lembra vagamente como eu entendo o funcionamento do keybase.
3. totalmente autônomo: interface do usuário, servidor de sinal e banco de dados, todos executados em uma caixa. O nó ou o elétron iniciam a IU e o servidor de sinal para você ao executá-los. O banco de dados é sua escolha de mongodb ou se você quiser a opção fácil, sem instalação extra, você pode escolher sqlite3. Nós descartamos completamente o método da API da caixa de depósito e partimos para a sincronização da caixa de depósito por meio do sistema de arquivos. Se quiser que a caixa de depósito sincronize, você pode escolher colocar o banco de dados no diretório da caixa de depósito em qualquer caminho que lhe pareça adequado. Se você quiser que suas notas sejam gravadas em uma unidade flash ou NFS ou / dev / null, basta dizer para fazer isso. Esta é provavelmente a coisa mais próxima de como a versão atual do laverna funciona no momento.

Observe que eu uso "cliente" e "ui" acima de forma intercambiável.

Minha única preocupação real é a robustez do sqlite3, especialmente ao sincronizar na caixa de depósito. Eu tenho um palpite (e apenas um palpite) de que a maioria dos problemas de sincronização que as pessoas tiveram com a caixa de depósito estão relacionados à API, e simplesmente mudar para o aplicativo / sistema de arquivos para acesso à caixa de depósito vai curar muitos desses problemas.

Isso é muito para repassar e provavelmente não sou o melhor em explicar meus pensamentos, mas perguntas? Preocupações? Comentários?

@daed da perspectiva do usuário, contanto que a criptografia seja forte o suficiente e transparente, o banco de dados pode ser armazenado em qualquer lugar e isso não aumentaria as preocupações de privacidade para mim.

Eu preferiria o modelo cliente / servidor (2), com seu desktop de código aberto e clientes móveis para análise / auditoria e armazenamento de servidor para portabilidade e compartilhamento. Freqüentemente, os aplicativos oferecem o modelo autônomo (3) como opção. A cópia local do banco de dados no modelo 2 também não poderia ser opcionalmente armazenada em uma pasta Dropbox, MEGA etc? Isso funcionaria mesmo se o servidor desaparecer para sempre.

No modelo (1), a criptografia / descriptografia do lado do cliente não resolve o problema de confiança? por exemplo, Lastpass, Bitwarden. Isso supondo que o que é executado no navegador seja examinado. O modelo (1) seria conveniente em certas circunstâncias.

Para o modelo 1:
O 'cliente', neste caso, é apenas um webbrower 'burro' que está se conectando à interface do usuário do laverna. Isso nos dá duas opções.

• Podemos pedir ao usuário o caminho para sua chave privada para que possamos lê-lo (localmente) e fazer a criptografia no js do lado do navegador antes de passar a mensagem para a instância do nó que está executando o laverna ui, o que é inconveniente, pois ele requer arquivos locais, o que frustra o propósito de uma configuração totalmente hospedada para começar. Isso seria semelhante a como o github funciona, mas tecnicamente o github ainda tem um cliente com git / ssh.
• Ou podemos fazer com que o servidor mantenha / gerencie sua chave privada (mas NUNCA sua senha) e então fazemos as coisas 100% remotamente. Você pode baixar / alterar sua chave privada, mas também tem que confiar que não estamos mantendo a senha longa e que não faremos bagunça mantendo sua chave segura. Isso está mais perto de como é implementado agora, eu acho. Este é basicamente o Evernote gratuito com ToS mais amigável e uma vibração de código aberto agradável. Não é o ideal, mas pode ser suficiente para alguns.

Pode haver mais opções, mas não tenho certeza de quais seriam neste momento. Lastpass / Bitwarden armazena e ofusca senhas, pensei. Essa é uma função de criptografia que pode ser usada em conjunto com isso, mas não resolve o problema de gerenciamento de chaves. Nunca usei nenhum dos dois, então é possível que não esteja entendendo totalmente sua utilidade.
Dito isso, provavelmente configurarei um servidor "oficial" como este na AWS ou algo assim, apenas no caso de ser bom o suficiente para algumas pessoas, se não para todas. Eu imagino que o Evernote gratuito, mesmo com alguns problemas de confiança, seria mais do que suficiente para alguns usuários. Talvez dê um tapinha no botão de doar e veja se algum dia recupero os custos de hospedagem.

Para o modelo 2:
Esta é, na verdade, minha implementação favorita das três possíveis. Tecnicamente, nenhum software precisa ser instalado no computador. Você pode executar o laverna a partir de uma unidade USB e manter sua chave lá. Você pode até mesmo incorporá-lo a uma unidade USB com caudas instaladas, se quiser ir tão longe para computadores públicos.
Eu não tinha considerado uma cópia local, mas algum tipo de recurso de importação / exportação / backup de notas estava na minha lista, então ambos se encaixam perfeitamente. Se o seu servidor falhou, você poderia simplesmente mudar para o modelo 3 e importar as notas e seguir em frente como se nada tivesse acontecido. Pode ser um pouco estranho ir de dados armazenados em mongodb para algum formato local, mas provavelmente é algo que pode ser resolvido.

Como uma atualização geral, fiz um aplicativo de prova de conceito de elétrons na noite passada com a interface do usuário e o servidor de sinal embutido nele e ambos lançando na inicialização. É totalmente sem polimento e totalmente impróprio para lançamento, mas me mostrou que era 100% possível ainda ter o modelo 3 com muito pouco esforço adicional.

Acho que se formos com o esquema de 3 modelos, vou criar pacotes para uma versão "servidor" que contém a interface do usuário laverna e coisas do servidor e nenhum elétron, bem como uma versão "cliente" que conterá os componentes para tudo também como elétron. Para a versão do servidor, a configuração precisará ser feita editando arquivos, mas será capaz de fornecer componentes do lado do servidor para o modelo 1 ou modelo 2, enquanto a versão do cliente terá uma página / assistente de configuração da interface do usuário e será capaz de fornecer componentes para o cliente para o modelo 2, bem como a implementação completa do modelo 3.

Esta conversa foi útil, mas permanecer neste repositório de laverna não é particularmente útil, pois não posso fazer nada com ele. Ainda vou verificar aqui se alguém posta algo novo, mas se você quiser continuar falando sobre isso (e espero que todos façam!), Eu pediria que o fizéssemos no meu em https://github.com/daed / laverna / issues / 1.

E obrigado a todos.

Não sei o que significa bifurcação (e não tenho certeza se deveria?), Mas de qualquer maneira; Eu tentei o apk laverna e parece que a sincronização não funcionará com ele. Eu estava tentando com 5storage. Parece haver outra versão do Android em outra página, mas sem lançamento, tenho que construí-la e, com meu conhecimento insuficiente, ela simplesmente falhou.

@xreqx Significa que o projeto está morto, e estou pegando o código e iniciando novamente por conta própria (com quem mais quiser ajudar).

Sinceramente, ainda não olhei para a versão móvel. Eu realmente não tenho nenhuma experiência em escrever aplicativos móveis para ser honesto. No entanto, é algo que gostaria de trabalhar.

pode valer a pena mencionar arquivo padrão ; a biblioteca usada por notas padrão .

Arquivo padrão é uma biblioteca de sincronização e criptografia para aplicativos nativos e da web. Ele permite que os desenvolvedores se concentrem na criação de excelentes aplicativos voltados para o usuário e deixa a sincronização, os servidores e a criptografia de ponta a ponta para esta biblioteca.
..
Arquivo padrão é um sistema de cliente e servidor reutilizável que permite implantar um servidor back-end "burro" que não conhece ou se preocupa com seu esquema de dados e permite criptografar dados no lado do cliente e sincronizá-los com o servidor remoto .

Então, wwebfor voltou para mim. Ele concluiu o projeto.

Note, eu criei esta página wiki há algum tempo. Eu coloquei um link para o seu comentário:
https://github.com/Laverna/laverna/wiki/DEAD-PROJECT-ALERT