Forking laverna

[daed]

Since PRs aren't getting approved anymore, I think the time has come to either fork this project or abandon it for something that's regularly maintained.

I'm considering doing this as I've already got several of the reported bugs fixed in my dev branch. I'm hardly a JS expert though, so if anyone else is interested in helping, that'd be good.

Should we change the name to avoid confusion? If so, any suggestions on a name?

[theryecatcher]

Have a decent programming background but I am just learning js and am ready to put in efforts if required to contribute to this project as it has been my goto app for a long time now. As for the name Laverna2.0... Heh.

[funilrys]

@daed Let's try to write @wwebfor && @wwwredfish first.

I'm pretty sure they can add every contributors or you to the organization so you can have write access...
Otherwise let me know when you have a name and a per-release so I can create the AUR package 😉

Can you contact me on keybase (preferred) or on email so I can transmit you the personal email of @wwebfor to you later today (Berlin Time) ?

P.S: If you generate new release on your fork I think it may be a good idea to also generate tarballs 😄

[daed]

Yeah, sure. I didn't want to snatch the project out from under anyone. I just wanted to make sure it didn't get left behind.

I'm in Central US time. I'll talk to you tomorrow on keybase if i can.

[daed]

So, wwebfor got back to me. He's done with the project.

He acknowledged that laverna doesn't solve issues with synchronization and multiple devices. He suggested that effort would be better spent focusing on other projects that do already. He also didn't give me access to the repo, so I can't do anything directly with it.

I think his concerns are valid, but I like laverna and I think it's worth trying to make something out of. I'm going to continue with my plan to fork it and develop it independent of the laverna organization.

I've spent the last few weeks trying to familiarize myself with the dev branch and working on minor bugs where I can. It's honestly not in very good shape right now:

• It looks like the project was in the middle of transitioning into more of a client/server model with the addition of the signal server and mongodb. That's not a bad model necessarily for hosting, but it becomes burdensome for standalone end-users who are syncing through dropbox (or not at all).
• The signal server appears to have been put together with a multi-user environment in mind, and there is the start of some useful features (like sharing between users) but that is incomplete, and I believe actually currently inhibits synchronizing across multiple devices.
• In spite of the above, https is not enabled by default.
• The electron-based desktop app version doesn't work.
• gulp is pretty broken in node 10 due to ancient dependencies. Supposedly this is getting fixed someday, though the current plan appears to be to force a newer version of the natives package, which is unsupported. I couldn't find an ETA.

I'd like to talk more about these problems and get recommendations / help on fixing them. I'm going to replicate this issue on my fork at daed#1.

I strongly encourage anyone who feels a vested interest in the project to come discuss, and I would like to warn anyone else that this project, as it exists at the Laverna organization, probably will not be updated any further.

[funilrys]

Nice summary @daed 🎉 ⭐

I'm in!

For reference: #931

[romu70]

Hi.
I used to run Laverna in the past, and gave up because of DropBox. My 2 cents: going to a real client/server model with a database back-end could be nice at preventing a lot of sync issues. And this will make the project almost independent.

[daed]

@romu70 That's one of the things I've been grappling with. For whatever reason, I never had the dropbox sync issues I hear everyone complain about and I like the fact that there's no central server. The dropbox method is kind of similar, but I can at least look at my notes and see they are encrypted. If one person or group owns the software and the database such as within a client/server model, it solves a lot of the headaches necessary, but, how do you prove your data really is being properly protected? Public api that you can push already encrypted messages to would be one such way, but that's the furthest thing off in the distance.

I was toying around with trying to find a way to provide it any way you want it with a hosted version, a Bring Your Own Server version, and a standalone Desktop version, but that sounds like it's going to be incredibly difficult to support.

I feel like the client/server really is the quickest and mostly likely route to the next release, but the further we move toward that, the harder a standalone desktop application is going to be to implement.

[romu70]

I tend to agree. Client/server is good if you think of your product to be installed on user servers. This way you are quite sure data are private, but the setup is less easy for sure.

Regarding the desktop application, I'm not sure this makes things harder, just think about packaging the front end with Electron, and you're almost done.

I'm impressed to see people who don't know this code base ready to dig into it. But one can also about an easier path, going to Boostnote which already offers the same thing (DropBox sync), with an already well maintained code base, community, support, etc.

Life is too short to reinvent the wheel.

[daed]

Boostnote is pretty slick, I'll agree with that. It is much further along and has a whole lot more polish to it. It doesn't handle encryption though (feature request has been open for just under a year), and the footprint of what needs to be installed on a computer seems much heavier than laverna.

Laverna can also be used completely from usb and still interact with Dropbox though, even if it's not installed. That's pretty neat too. I think there's a lot worth saving here even in the face of other note tools with more resources than a couple fixated people.

[glocalglocal]

A simple user here, but Laverna's key feature is zero-knowledge encryption with the strap-line 'Keep your notes private'. Without that I might as well return to Evernote.

[daed]

Okay the electron implementation of the laverna front-end was way easier to implement than I thought it would be for the dev branch. It still needs (working) automated build tools, but it's a step in the right direction.

@glocalglocal What is your definition of "private"?

Is "encrypted but on a server you don't own" considered "private"?
What about "encrypted but on your local hard drive"?

I guess in a round-about way, I'm asking if the first one is good enough, or if the second is a requirement to consider the software for use? No wrong answers; I need the user perspective here.

[eternaltyro]

Choice is always good. So it will definitely be worth the time and effort to fork this project despite there being other mature alternatives.

[daed]

Here's what I'm initially thinking will be the most flexible and maintainable compromise:

Currently in dev:
Laverna is two components, three if you count the UI, four if you count mongodb (currently a requirement). That's an unreasonable expectation to put on a user. The user-facing component talks to a signal server, which in turn talks to mongodb. Currently all mongodb does is store user names and what I think are public keys. All the signal server does (that I'm aware of) is decouple the database from the component that handles the ui. This means that it would be possible for a user to run a laverna "gui" (laverna in electron as an example) and connect to a public laverna "server" / db. The multi-user / multi-device implementation looks incomplete though based on my cursory tests. If it IS fully complete somehow, I couldn't figure out how to use it, which means that it's probably way too complicated.

What I propose for dev:
We merge the signal server and the UI together into one package. In addition, we build electron versions of this merged package. We process all data through the signal server to the database. Notes, notebooks, backup configuration files, everything except the private key. We include configuration allowing you to start a UI, a signal server, or both. In addition, we build an adapter for the signal server to be able to handle sqlite3 connections.

This takes laverna and lets you turn it into anything you want. The three obvious configurations with this scheme that you could choose one of any of:

1. fully managed: UI, signal server, and database all run on a server somewhere. You connect via browser. This is basically more or less what laverna.cc is today. You get most convenience, and don't need to download / install a thing, but have the least transparency and have to put blind trust in your server administrator. I'm going to call this the "Evernote configuration".
2. client / server: UI runs on client computer via node or electron, signal server and database run on a server somewhere. You have centralized storage and have available any collaboration features that might be included down the line, and you own the UI client, which you can build from source to have a reasonable expectation that security is being upheld at the client level. This is probably the best compromise of features, convenience, and security. This vaguely resembles how I understand keybase to work.
3. fully standalone: UI, signal server, and database all run on one box. Node or electron start the UI and the signal server for you when you run them. Database is your choice of mongodb or if you want the easy, no extra-install option, you can choose sqlite3. We completely dump the dropbox api method and go for dropbox syncing via filesystem. If you want dropbox to sync, you can choose to put the database in the dropbox directory at whatever path feels good. If you want your notes written to a flash drive or NFS or /dev/null, you just tell it to do it. This is probably the closest thing to how the current release of laverna works at this moment.

Note that I use "client" and "ui" above interchangeably.

My only real concern is the robustness of sqlite3, especially when synchronizing across dropbox. I've a hunch (and only a hunch) that most of the sync issues people have had with dropbox are api related though, and simply switching to the app / filesystem for dropbox access will cure a lot of those pains.

That's a lot to go over, and I'm probably not the best at explaining my thoughts, but questions? Concerns? Comments?

[glocalglocal]

@daed from a user's perspective, as long as encryption is strong enough and transparent, the db can be stored anywhere and that wouldn't raise privacy concerns for me.

I would favour the client/server model (2), with its open source desktop and mobile clients for scrutiny/auditing, and server storage for portability and shareability. Often applications offer the standalone model (3) as an option. Couldn't also the local copy of the db in model 2 be optionally stored in a Dropbox, MEGA etc folder? That would work even if the server disappears forever.

On model (1), doesn't client-side encryption/decryption solve the trust problem? eg Lastpass, Bitwarden. That's assuming that what runs on the browser is scrutinised. Model (1) would be convenient in certain circumstances.

[daed]

For model 1:
The 'client' in this case is just a 'dumb' webbrower that's connecting to the laverna ui. That gives us two options.

• We can either ask the user for their the path to their private key so that we can read it (locally) and do the crypto in brower-side js before handing the message off to the node instance running the laverna ui, which is inconvenient as it requires local files which defeats the purpose of a fully hosted setup to begin with. This would be kind of similar to how github works, but github technically has a client still in with git/ssh.
• Or, we can have the server keep/manage your private key (but NEVER your passphrase) and then we do things 100% remotely. You could download/change your private key, but you also have to trust that we're not keeping the passphrase and that we won't screw up keeping your key safe. This is closer to how it's implemented now I think. This is basically free evernote with friendlier ToS and a feel-good open source vibe to it. Not ideal, but could be sufficient for some.

There might be more options, but I'm not sure what they'd be at this point in time. Lastpass / Bitwarden store and obfuscate passwords, I thought. That's an encryption function that could be used in conjunction with this, but it doesn't solve the key management issue. I've never used either, so it's possible that I'm not fully understanding their utility.
All that being said, I'll probably set an "official" server up like this on AWS or something just in case that's good enough for some people if not all. I'd imagine free evernote even with some trust issues would be more than sufficient for some users. Maybe slap a donate button on it and see if I ever recoup the hosting costs.

For model 2:
This is actually my favorite implementation of the three possible. Technically, zero software needs to be installed on the computer still. You can run laverna from a usb drive and keep your key there. You could even embed it into a usb drive with tails installed on it if you wanted to go that far for public computers.
I hadn't considered a local copy, but some sort of note import/export/backup feature was on my list, so both of those kind of dovetail together nicely. If your server went away, you could just change to model 3 and import the notes and move on as if nothing happened. It might be a little weird going from data stored in mongodb to some local format, but that's probably something that can be dealt with.

As a general update, I made a proof of concept electron app late last night with the ui and signal server embedded into it and both launching on startup. It's entirely without polish and totally unfit for release, but it has shown me that it was 100% possible to still have model 3 with very little additional effort.

I think if we go with the 3 model scheme, I will create packages for a "server" version that contains the laverna ui and server stuff and no electron, as well as a "client" version that will contain the components for everything as well as electron. For the server version, configuration will need to be done by editing files, but it will be capable of providing server-side components for model 1 or model 2, whereas the client version will have a ui configuration page/wizard and be capable of providing components for the client for model 2 as well as the full model 3 implementation.

---

This conversation has been helpful, but remaining on this laverna repo isn't particularly helpful as I can't do anything with it. I'll still check here to see if anyone posts anything new, but if you want to keep talking about this (and I hope everyone does!) I would ask that we do it at mine at daed#1.

And thanks, everyone.

[taw00]

So, wwebfor got back to me. He's done with the project.

Note, I created this wikipage awhile ago. I have linked to your comment:
https://github.com/Laverna/laverna/wiki/DEAD-PROJECT-ALERT