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

Development
#18

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.

#19

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.

#20

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

#21

How about email? Note updates are sent as emails to note followers. Update emails are shown as a conversation thread in an email client and have a predefined structure for automatic import to Joplin that has access to the inbox.

Pros:

  • Open, free and distributed
  • Control who receives the updates by adding/removing the note followers.
  • Easy to implement, no custom server
  • Users without Joplin can edit the note by sending an update email manually

Cons:

  • No link sharing
  • No real-time collaboration like in Google Docs
#22

Hi @laurent.

TLDR; Sharing a single note is a feature that would bend Joplin into something that Joplin is not designed for. Don’t do it. Read on for fact-based argumentation.

  • My Suggested solution: Adding multiple sources / syncronisation directories
    • Pro: Possible to realize within reasonable time.
    • Pro: Reuses current Joplin architecture and code.
    • Pro: allows to collaborate with others on a subset of notes
    • Pro: keeps the Core Joplin App easy and usable
    • Pro: pushes the nasty parts of synchronization / permissions / user login / authentification / authorization / distribution / 24/7 reachability / web app / … to other providers who are focussing just on that, namely the currently supported Joplin data stores: Nextcloud, Dropbox, WebDAV and OneDrive.
    • Con: people who want to share a single note with one other person have to use one of above mentioned compatible stores. They may demand that Joplin has a web app and supports sharing of single notes and whatnot and may whine loudly about it.
      • Solution: please use Google Drive if you want to edit a single document collaboratively. Not even Evernote supports editing a single note collaboratively. Let’s be realistic here.
    • Con: a Joplin “store” is a heavy thing. It has sync database, the individual files, etc. Making a store just to share one note is bad
      • Solution: make a folder in a store backend a Joplin store

On “Share a note” as described above (click “share”, get URL for someone to view, recipient doesn’t need Joplin")

  • Background assumptions: Joplin does not have a server part. Joplin is primarily a client-side software, the server part is the data store backend (Nextcloud, Dropbox, Webdav, OneDrive). The only way to share an URL to a note would be via one of those store backends and using their capability to create URLs.
  • Solution: program a complex read-only-note-rendering-static-html-thingy that creates a static html version of a note, stores it on the store backend, retrieves the URL to view, and updates this static note on any change
    • Pro: feature would be implemented as described
    • Con: Each store backend has different approach to user management, public urls, signup, authorization, authenticiation, URLs, …
    • Con: Feature needs to be implemented X times
  • Solution: send the note to the recipient via E-Mail. Do not share URL. Person can look at it. Person doesn’t get update.
    • Pro: easy to do by i.e. storing note as HTML on device, start email software pointing to this file to “send it”. If no OS library call available to start email software, just point user to exported note and tell user to send via email.
    • Pro: send via email is culturally well understood
    • Pro: no magic expectations regarding URL and auto-updates

On Collaborate on a note as described above: I want to focus on the key points “they can edit…” “require they have Joplin installed”.

  • Solution argumentation:
  • Assumption: the recipient has Joplin installed.
  • Assumption: If the recipient already has Joplin installed, the recipient already has her or his personal notebook on one of the many available storage backends.
  • Assumption: the sender also is using a storage backend
  • Assumption: the sender wants to collaborate with the recipient for long-term or project-term duration
  • Assumption: the sender has multiple parallel projects going on. The sender is OK to create project-specific sources/subfolders/etc. for each sharing context/group of recipients
  • Solution: The sender creates a subfolder/store for each project/group of recipients.
    • User Story: The sender puts the project notes into the store. The sender sends the store credentials to the recipients or invites the recipient to sign up to the store (Webdav, Dropbox, OneDrive) and shares the folder with the recipient using hte store’s magic of sharing. Recipient is a Joplin user, knows how to use stores, adds store to his Joplin, starts editing.
    • Detail: sending store details to a recipient should be easy, such as in a json config file “ourprojectstore.joplinstoreconfig.json” or in a url-encoded way that the recipeint has a “one click” operation in Joplin to add the new store.
    • Detail: auth/signup/storage is all handled by the store backend
    • Note: this is basically repeating my first solution pointing to issue 3546

@laurent you noticed that NextCloud is answering slow and hard to program. I have met Frank Karlitschek about 12 years ago when we were working on Nepomuk-KDE and found him very responsive, so I could not believe that NextCloud is slow answering. Also, NextCloud is the premiere solution when it comes to open source enterprise-grade file management, so if they can’t manage it, who can. But yes, some forum entries are not answered yet and there are not dozens of posts and replies each day, but maybe I looked into the wrong forum: https://help.nextcloud.com/c/dev/11 . Anyway: the gist is: whatever platform you use as server backend for Joplin, you are stuck with. Be it Google Drive, NextCloud, Drupal, Wordpress, Typo3, Django, grav.org, picocsm, etc… you end up with endless choices. Should you use PHP/MYSQL as basis because everyone has it? Should you use Python as it is nice? Should you use X Y Z?

@Laurent, you write: “different folders in existing sharing solutions […] is 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.” I want to deconstruct this:

  • “not an option” - seems like you are digging into an argument here, please consider this option, open up
  • “more and more dependent … developing code for sync target” VERSUS “custom server”. You just compared building a new CMS/file-management-system versus using an API to an existing system. That sounds like hte “not invented here” fallacy and the “it’s quicker to write a new CMS from scratch than to reuse dropbox”. Also you seem to be tired of “developing code for the sync target”. But the main point of Joplin is to make the code of the sync target more stable, fix bugs, make it more performant, keep it compatible for the existing user base who have been using Dropbox/onedrive/webdav to keep their notes. Lets look at the elephant in the room here: making the existing sync code better and keeping it compatible with chaging store APIs is essential for Joplin to survive over the decades to come.
  • “like the nextcloud app would” - you wrote above that you are unhappy with the NextCloud community and that the interfaces and framework is complex. A couple of days later, you hope that using NextCloud will magically sove all problems. It is obvious that this is a hope that will not realize itself in any given time, given the existing developer base. Given that there are dozens of tickets open.

What @cph5489 writes is essential “if we can move the files we want to share into separate folders, it will become significantly easier to share notes.” --> exactly. All the store backend platforms have some way to share folders with different people. If the Joplin store format for sync would not be “one big folder with many UID-numbered files” but something else, a new look on Joplin would come.

What @Rado1 writes is essential: " My proposal is just to allow the mapping of several sources with separate sync configuration for each of these sources.". Which is issue 3546.

The idea of a note-taking application is to use it for weeks, months, years, decades. If you look into the use cases - personal information management - you notice that people are using note-taking apps as a lifelong companion. That said, the more simple/stable/future-proof the architecture, the better. The less moving parts Joplin has, the better. The more we focus on the GUI of the desktop/mobile app and the sync code, the better. The less (or later) we add a web-server, the better.

8 Likes
#23

Reusing stores and existing folder structures may also help to make Joplin more “sharing”. I wrote this up here: Embed Joplin store structure in existing folder structure (local or remote)

1 Like
#24

Joplin could probably use an external sharing service like textdb as a secondary sync target. It seems to have what a lot of people would want out of sharing with a simple service (although it certainly lacks security).

1 Like
#25

I don’t have a concrete proposal. I had an occasion in which a friend and I wanted to collaborate on a set of notes for a particular task. We tried using a Google Docs Sheet (spreadsheet) on my Google Drive, and that worked really well. No installation necessary, and the functionality we needed was pretty minimal. The Drive infrastructure took care of the mechanics of sharing.

Again, I don’t really have a working idea for how Joplin can use this technology, but wanted to toss it out in case it inspires someone else. Maybe for purposes of sharing a Joplin note, rather than trying to use Joplin’s native data store and functionality, a more basic export/import approach is possible using Google Drive’s native capabilities. And I’m not sayng to focus just on Google Drive; DropBox also has a sharing capability. So export a note, let participants collaborate on it on Google Drive, DropBox, whatever, and at the end, if desired import that note.

1 Like
#26

@leobard, adding support for multiple profiles would definitely handle certain use cases, for example you could have personal notes on one profile and work notes, shared with colleagues, on another profile. Since it’s indeed easier to support this than developing a new server, it’s relatively high priority to add this.

The main obstacle at the moment is that it’s difficult to restart a mobile app, and for iOS, it looks like it’s going to be forbidden soon. Without being able to restart the app, we’ll have to develop complex logic to allow switching the profile dynamically which would a huge task as Joplin wasn’t designed for that.

Also a drawback of this approach is that you have to install Joplin, setup the sync target, etc., which is too much for just sharing a note. Let’s say you want to organise a day trip somewhere for several people, you create a note in Joplin with the schedule, maps, etc. then you share this note with everybody. For this scenario, we need to be able to share a single link without a requirement to install Joplin.

#27

Alas, with regard to collaborative editing, I think it is possible to reuse existing tools, such as Live Share. Collaborative editing is a very complicated matter. I don’t recommend Joplin to touch this.
As for sharing, I think that as long as there is a static site generator, and then deploy some content that needs to be shared on the public network, send the link out, and it’s over.

For encryption issues, you can refer to existing static blogs and use the salted hash string as the password. Only the author knows the salt.

ref link: https://visualstudio.microsoft.com/services/live-share/

1 Like
#28

Hi @laurent

Sharing a note: the user story you describe - “organize a day trip, share it”. It does not need the recipient to always have the latest version. The sender can send the update. The straightforward approach would be to pack the note into a HTML or PDF and send it over. The HTML embedding would be quickest for you, as it is JS-friendly. If you use canvas and toDataURL() you can embed image as base64. That leaves you with one cross-plattform compatible HTML and you are done.

I would start with that and declare the following design decision to go forward: “joplin is currently a single-user note-taking tool supporting multiple store backends and no server. Sharing notes is a good case, I want to support that, so we do (HTML|PDF) export. That is a minimal incremental improvement and satisfies the immediate case. For collaborative editing, we also have this on our agenda, but it needs account switching.”.

The approach I would go for is multi-sync-target config and switching in the gui. Having multiple stores in parallel is something people know from other note-taking tools or from email clients. I would start by letting people “switch”. Have two folders on disk that carry the storage data. Once this works and is established (which will take months, if not years), an integrated “all notes from all stores” view is something to think about. But only then. One step after another.

Users needing collaborative editing right now should use a popular plattform that supports this today such as NextCloud or Google Docs.

#29

If I had 2 Joplin app (the blue one and a green one for instance) it will fit my needs. Ok maybe it’s not very efficient but it will allow me to share some notes with my family and keep others for me.

#30

DevOps, eh? :wink:

#31

My thoughts are like this:

  • There’s a desktop client
  • There’s an android/iOS client
  • There’s a CLI client

They all operate via SYNC functionality.

So in order for collaboration to happen, or to have something like Evernote, all that’s missing is a web server which operates on the same SYNC functionality that will act as a web client.

For collaboration on the web client you can have:

  • Owner user/password
  • Invited user with password
  • password-less access to notes (public)
  • anyone with password can access

like the CLI, nodejs can be leveraged. Some framework like hapijs, fastifyjs or whatever.

If set up right, the web server could be deployed on Heroku.com for example (would be free for this use-case) or if you have your own server.

#32

Does anyone here know
https://convergence.io/?

they even list some competing products


but also check the so called dead ones, e.g. TogetherJS is still alive
#35

After reading all the comments I can see there are many options with their pros and cons and we just need to find the option which is suitable for most of the users, easy to develop and don’t restrict the further development of Joplin.

  1. We have the option to use NextCloud, Google Drive, or any such service as a sync target:
    • Pros:
      This is a great option for the user’s point of view as users won’t have to do anything and they will get the option to share notes with others.
  • Cons:
    Users have to use different sync and set up everything just to share notes.
    Devs have to setup code for every sync targets and make sure they’re also synced with each other.
    Some services have good docs for their services like google drive and all but many sync targets have bad docs.
    No. of shared folders is limited by no. of sync targets.

  1. Creating a nextcloud server:
    Pro: Very easy for the user to use it.
    Pro: Less work for the devs.
    Con: Bad ( at least for me ) docs.
    Con: Will depend on NextCloud for many things and features in Joplin, so very restrictive in my opinion.
    Con: Will have to learn differently techs and make a separate server that can rarely be used later as many tech and frameworks are NextCloud specific.

  2. Creating a Joplin Server:
    Cons: Will be difficult for the user to setup
    Cons: Too much work.
    Cons: Need payment method if we’re going to provide the user an option to use the Joplin server instead of setting up their server.

Pros:
According to me best option here is to go with the Joplin specific server. I have a few reasons for that:

  1. All cons are solvable and we don’t have to depend on third party services.
  2. Will allow Joplin to add much new functionality and ease to user after having a custom server.
  3. We can develop a “real note sharing feature” with both link sharing and live editing options.
  4. Will be very easy for the user to use ( if they are using Joplin server, if they want to install it on their own we need to make the server with a good GUI so that a non-tech person can also install it in an easy way, also if someone can install NextCloud server, I don’t think they’ll have issues installing Joplin server ).
  5. As we can use the latest protocols and tech, we’ll see a performance improvement.
    and many more.

Flow of the feature:

Users just have to click on a note and they’ll get a sharable link and a password for the note ( password is optional ), they can share that with anyone and they can see and edit that note and that’s it. Easiest and simplest it can get and now there are no issues of folders, sync targets handling different scenarios. Those who want to share a single note or multiple notes or a folder will be the same for everyone.

Technicalities

First of all, as we’re going to use our own server, we don’t have to change much in the existing codebase and in a very vague way, we just have to take the content from a note and send it to the backend and show it on a link and for the changes, we just have to make an API call and then update the content of the note in the app.
We can create a Node.js (or any other tech) backend which will receive the data and generate the note and will send the link to that note.

2 Likes
#36

My two cents: Existing platforms like dropbox, nexcloud, … already offer lots of sharing-related features that users probably expect nowadays. Examples are

  • sharing data publicly (easiest)
  • sharing with password-protection
  • sharing with selected users (who have credentials)
  • time-limited sharing (this share expires at date XYZ)

Using a custom server means that these cannot be leveraged (so either are not available, or need to be rebuild which I guess is vastly out of scope).

#38

As for sharing read-only notes for non-joplin users, don't reinvent the wheel.

Right now, I copy everything over to a hugo site, relinking any attachments. The attachments are quite time-needy, as they need to be renamed (in markdown or the file). For basic text, this is fine, but for special syntax, it might not work.

The preview view is an iframe anyways, I would guess getting / exporting as html not that hard, as you don't have to build much new.

Of course, exporting markdown with attachments, then re-implementing all rendering in a SSG is possible, but it's not very practical.

html files can be hosted easily. Now, from the user side, making joplin upload a file unencrypted to a remote (the ones implemented), in a specified directory (joplinroot/hosted-notes for example), and then generating a link based on configuration is possible.
The webserver serves from the directory (or the directory is synced to it) to domain.tld/j/. When the user decides to share, generate a short either mnemonic or 4-6 alphanumeric string, allowing the user to rename it. Say user named it to my-note, the attachments will be in domain.tld/j/my-note, and the rendered result in domain.tld/j/my-note/index.html. From preconfigured settings, joplin knows it needs to pre-append https://domain.tld/j/. This could also be present in the UI on renaming the path.

Now who likes setting up stuff with webservers? Joplin-hosted notes. It's a revenue source for the developers, and provides easy setup to users. When selected, and stored, credentials are synced with clients. 3$/yr for example (warn: maybe load cap of like n visitors per note per month.. or just auto-scale). The public directory is just pushed to a different remote.

Pardon for bad unedited writing, have to go atm.

Tldr take output of rendered html in joplin, along with downloadable attachments (non-images), throw them in a directory (optionally hosted by joplin), where it reaches the web server. Web URL path is pre-appended, and presented to the user. User may change path/sub-path or choose to remove (simple move, remove commands), select, if the note should be auto-updated, and select a (latest) version to be hosted.

I would imagine there really wouldn't be many sync conflicts, for the public directory, but the area needs to be thought of anyway.

Ping me to remind me. I can draft up code design docs and UI examples.

#39

how about having a public notebook folder? the public notebook folder is a special share folder (like trash folder) that contains unencrypted files like txt or md. We can then use any 3rd party cloud provider that support collaboration like onecloud or dropbox to share and collaborate on notes. After the person is done with editing, you can move the notes into other notebook to make it private.

#40

Many of the issues regarding syncing, resolution, and agnostic connections may be addressed by this collaborative framework; it's gained some purchase recently, and appears robust enough to handle cited use cases.

Looks like other note taking apps may have also leveraged it already, so may offer some road tested scenarios against which to plan and test.