Home / GitHub Page

Any suggestions on what web technology could be used to add support for sharing notes?

One important feature missing from Joplin is the ability to share a note with someone else, or more generally to allow multiple users to collaborate on a set of notes or notebooks. Enabling this is quite complicated because currently Joplin is only a set of clients (for mobile, desktop and CLI) and there’s no server application.

This is what I mean by “sharing”:

  • Share a note: You open note, click “Share”, and you get a URL you can give to someone to view your note. If you make a change to the note and sync, the person you shared with will see the updated note. It should be possible to share a note even if the recipient doesn’t have Joplin installed.
  • Collaborate on a note: Same as above, but the person you share with should also be able to make changes to the note, and will see these change when you sync. For this it might be ok to require that they have Joplin installed.

So far there have been a few attempts to enable note sharing, but all have their pros and cons:

  • First, I’ve done some tests with a Joplin-specific sync target. It would be possible to sync multiple clients with it and, since it’s Joplin-specific, it would understand the sync target structure and allow sharing notes more easily.

    • Pros: Since it’s Joplin-specific, it’s relatively easy to add features to it and to optimise it for Joplin. For example, now we sync with Nextcloud using WebDAV, but this is an inefficient and dated protocol. With a custom server we could do something more optimised. It would be implemented using Node.js, TypeScript and PostgreSQL which are technologies that are reliable and easy to work with.

    • Cons: It’s not standard, unlike WebDAV. It requires users to setup a custom server, unlike now with Dropbox, OneDrive or even WevDAV (which has many free service offers). So it’s not user-friendly for non-technical people.

  • Then I’ve done tests with a Nextcloud app.

    • Pros: For those who already use Nextcloud, you just need to get the app from the store and press install, and it works. Much easier than the custom-server solution.

    • Cons: Developing Nextcloud apps is hard as the doc is out-dated, and there’s no support on the forums. The app architecture feels dated and has a high learning curve. Also it’s not really possible to decouple your app business logic from Nextcloud due the way their framework is done. What it means is that it’s an all or nothing - once it’s done as a Nextcloud app, it can’t be converted to a standalone app. Finally they also don’t use standard packages for things like database or the framework itself, so anything you learn can’t be applied to anything else, which makes the time investment a bit wasteful. It’s also not much fun to develop for it unfortunately (which is important for open source software, if we want other developers to contribute).

That’s the current situation for sharing and it’s not so great at the moment. Sometimes I think the way to go is option 1, and sometimes option 2, but all have major drawbacks unfortunately, and that’s why things haven’t been moving much when it comes to note sharing.

But perhaps there are other options? Do you know of any other technologies we could leverage to allow sharing notes? One reason Joplin worked out well I think is that sync is based on already existing cloud platforms, so there wasn’t a need to develop a server for it. If we could do something similar for sharing and collaboration that would be perfect. Any suggestions?

1 Like

Unfortunately I don’t think there aren’t any real alternatives, unless you want to create a server that uses webdav in the backend, in which case people could still use webdav enabled services for their data.
(This would certainly be my preference.)
Although it would mean a perf hit due to WebDAV.

I use Nextcloud myself, but I have to say that the community forum is mostly useless and a lot of devs are whining hypocrites. I know that I can often come across as harsh and hostile (especially when people don’t read what I write, but start interpreting things or try to read between the lines), but the fact is that my complaints against certain Nextcloud problems are more than warranted. I’ve been complaining that their priorities are way off and got scolded for it every single time.
Yet, look at nc19. It’s just the latest example. They released a product that destroyed data. Yet it took weeks to release a fix.
Issues with core functionality (like sharing) and sync clients haven’t been adressed for years, but they find it necessary to put in badly designed and half baked features. I’m very sorry but this makes no sense to me.
Not all of Nextcloud is bad, otherwise I wouldn’t use it myself, but I certainly have my share of bad stories to tell. Good ones too, but as always the bad ones always stick out.

One solution may be to not use a web technology at all.
Instead, when users want to share a bunch of notebooks/notes, a file corresponding to it will b created by Joplin. The user can then send that file over to someone else in whatever way that pleases them. The user receiving that file should be able to a open the file with Joplin, much the way we open .docx files we receive from others.

The challenges to implement this technique are:

  1. Creating a file format that can store all the relevant data, attachments and metadata (Perhaps JEX can be modified to this end?)
  2. Opening that file in Joplin. This means that the notes can be displayed without pushing them into the user database. Perhaps in a separate window on a temporary profile. Also, the user must be able to move the notes into his own set of notes.

Pros:

  • Web technology agnostic. It can be maintained directly by Joplin devs and contributors.
  • Ease for the user. It involves no setup; in fact sharing notes could be made as simple as sharing PDF’s

Cons:

  • Significant increase to codebase.
  • There may be a problem of backward or forward compatibility

Laurent, come to think of it, I’m actually not quite sure what you mean by sharing.

Is it meant as in:

  • make notes available to others (1 person is the author and distributes it)
    or
  • collaborate with others on notes (several people edit the same note)

Good point, I’ve updated the top post with this info. It’s both actually, except for the first one there should be a dynamic element to it - so if you share a note (by giving a share URL), and make changes to the note, the person you shared with should see the changes too.

That could indeed solve some use-cases, if someone has a note and they want to quickly send it as a PDF by email, or indeed as a JEX file that could then be opened in Joplin.

However one of the requirement is that if you make a change to your note, the person you share with should see the changes too, and for this we need some kind of technology in between. I’ve updated the requirements in the top post now.

One idea could be to implement completely different requirement I have seen on this forum = multiple profiles and probably use them at the same time.
Then I could have

  • one tree of notebooks for my personal stuff (used only by me) synced with any available method (webdav, dropbox, nexcloud,…)
  • another tree of notebooks (used only by me) related to my actual job (as was requested by a few people). Again synced by any available supported method (would be great if it could be different)
  • another tree of notebooks shared by more people - they will have configured the same syncing method (either shared webdav account, shard dropbox folder, shared nexclud folder…).

This could be a solution for people demanding split notebooks (private, work-related,…) and solving the request for shared notebook(s) with more people too.

As a result, I will have a separate private tree of notebooks synced via my private webdav and one notebook shared with my colleagues synced via company nexcloud (for example).

I hope I have described my idea a clear way…

7 Likes

Yes, at their scale it’s a bit crazy that a bug as critical went in. You’d think they have a ton of unit tests to ensure their core functionality (hosting files) doesn’t corrupt data, but looks like not.

Also because of the locking bug, Nextcloud is basically broken by default. Like you can try to install their Docker image and within a short time you’ll hit the lock bug, which will make the instance unusable. This bug has been around for so long and affect many users (we get a post or two per month here), yet it doesn’t look like they have any plan to fix it.

These issues and other bugs means I don’t have that much trust in where they are going at this point. I think they need to clarify what’s their long term plan. If they want to drop their open source offer and focus on their enterprise offer, that’s fine but they should be clear about it.

1 Like

I think @Rado1 's idea is very good. Since Joplin note files are essentially a bunch of markdown files stored in folders, and most of our current sync platforms allows folder-sharing, if we can move the files we want to share into separate folders, it will become significantly easier to share notes.
(The thought here is: instead of implementing our own sharing methods, let those big platforms worry about it.)
As for the “sharee” end, if we can have something similar to Nexcloud’s “Federated Cloud” system, it would be great.

1 Like

This is indeed a tough choice. I have migrated many notes to Joplin, but there are some notebooks I still have to keep in Evernote (albeit now downgraded to the free tier) since I rely on them for collaboration. This ranges from work projects, to simply sharing a shopping list etc. with my wife.

Another advantage of the “self hosted” Joplin dedicated approach, although not good for the non tech-savy, would presumably be that one could also have a “true” web app, I would assume?

I have also been using Trilium recently, and the author uses this approach - you have to install on a server somewhere, but you get a lot of advantages (https://github.com/zadam/trilium/wiki/Synchronization).

Pretty much every note-taking app that I’ve looked at recently has gone this approach - either opting tor a free app with a potentially for-pay hosting service, or else “host your own” if you can… I would not want this to affect the core sync functionality, but it would offer an extra level of service…

3 Likes

This is also the main difference between RHEL and Fedora (and CentOS). Enterprise support I believe is the term they use.
Although if Laurent does make a paid service where the server will be provided, there may be some paper-work to settle before…

I thought about this option before of providing the server as open source and offer next to that a paid service for those who don’t want to set up everything themselves. That might indeed be an option.

For paperwork as I’m in the UK it’s not an issue. One thing they got very right here is how easy it is to setup a limited company - just a few clicks and it’s done on the same day.

From a user point of view, I’d ideally want to have as little effort as possible (not a new insight, I know).

If I can leverage existing infrastructure (nextcloud / webdav / …) and do not need to install a separate component, that’s one step closer to “this will actually be usable by ‘the masses’”. From an administrative point of view, it means “not an additional service to deploy / configure / maintain”; for a non-technical-user who e.g. synchronizes to dropbox and does not run their own server, it might be the difference between having access to this feature or not.

As nextcloud arguably has a large installation base (and I personally use different instances at home, at work and in associations), I’d argue strongly in favor of a solution that can make use of an existing nextcloud installation.

What @Rado1 proposes sounds like it would tick all my boxes.

Another quick question: For collaboration, what is the expected feature set?

  • the basic functionality: A note can be edited by multiple people and changes show up for everyone
  • conflict resolution: If two people edit something at the same time, whose edit wins?
  • potential additional “passive” collaborative features like “who made which changes” / edit history
  • potential additional “active” collaborative features: the ability to comment on something (propose a change, or explain why a change was made), and probably many more.

As the technical basis that is to be created now should not limit planned use cases, I think that the scope should be roughly defined before making a decision on the technical side.

Aren’t all these conflicts resolved already?

All these situations can happen if I will open my notes on PC and mobile at the same time.
All these conflicts can happen now and there is already some kind of resolution of such conflicts already.

My proposal doesn’t require any redesign of the logic.

O.K. If currently the conflict of editing the same note from PC and mobile could not be resolved, just report it as a limitation in case of editing the same note by more people.
IMHO - in 99% cases the people don’t need to edit the same note at the same time (does any other vendor has a solution for it besides Google?)

My proposal is just to allow the mapping of several sources with separate sync configuration for each of these sources.

It will resolve:

  • request of people to have separate notebooks (private, working,…)
  • possibility to have one of the source shared among more people - Joplin doesn’t need to resolve this sharing. People have to deal with it themselves. Either configure sharing in nextcloud, in dropbox, by syncthing,… Don’t care. Just let users use already existing supported sync method.
    Of course, there will be conflicts. The same way as the current possible conflicts using by one user.
    Just mention it as a limitation and later on, we will see how much people will demand real-time multiuser editing…
1 Like

Don’t get me wrong - I don’t want to argue against such a solution (in fact I rather like it, see above), nor do I think that the features I mentioned are necessary. Please see my post above as a collection of things to think about, not as a “this must be done!” or “I assume this will be a problem” :slight_smile:

OK, I agree with you.
I definitely not want to claim that there will not be issues with shared notebooks.

Anyway, we are on the same wave…
Have a nice day.

Could you use different folders in existing sharing solutions? I’m using OneDrive to share notes between multiple devices. While it’s always me on those devices it would be no different if it were a different person, if the folder could be shared with others (and Dropbox and OneDrive allow folder sharing) then Joplin would not know the difference - in fact I bet you could share a complete set of notebooks right now, but without granular control that would be desired.

To my mind “all” that needs to be done is to add to the Synchronisation options that one or more folders is specified within the Synchronisation target. The owner of the synchronisation target then specifies who the folder is shared with and read-only or read-write (by that I mean the owner of e.g. the OneDrive folder and using the OneDrive configuration so nothing to add to Joplin to control sharing).

So Onedrive/Apps/Joplin has all my private notebooks. I could add Onedrive/Apps/JoplinShared and any notebooks in there can be shared with others. Of course, it might be neater for all Notebooks to move down one folder level (so Onedrive/Apps/Joplin/Private contains what is currently Onedrive/Apps/Joplin and extra folders are created alongside Private).

Where notebooks are created could be controlled from the Sidebar (so within the Sidebar there is one section for private notes and one per each shared folder).

An extension to that might be sharing across synchronisation targets - so some shared notebooks might be on Onedrive and some on Dropbox.

It’s not an option as it means being more and more dependent to these third-party services, and developing bespoke code for all the sync target. It would also not solve many other issues, like the Nextcloud app or custom server would.

What about something like sharing Joplin screen in an authenticated Zoom session and allowing screen control on request? Not graceful, but it might work.