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.