“Hub and spoke” architecture for Joplin

Features
1

I am coming from the world of SOA (ESB, Microsoft Biztalk, Web/REST services etc…) and each time I see an app I am wondering: “How does it connect or could connect to the rest of the world?”

And here is my answer for Joplin

. The only possible architecture for Joplin is “Hub and spoke”. A central repository where spokes send their posts to the hub and forget (“fire and forget” as said for smart missiles). Then any other client can come, search or browse, and get what it needs.

. What do we put in the hub? Of course, not the posts, they are too heavy. So only the tags, with a link to the posts. Repositories (Nextcloud, Dropbox, web servers if any) storing posts must have been declared as shared. Then the published post and its tags that will be indexed too, using a simple user interface added to Joplin.

. For your personal use you can create any tag, because you know that “Holydays summer 19” refers to your last summer trip in California. In order to have common tags in Joplin they must be grouped in families (and maybe sub-families) so that “arm” in “Body” family is understood differently as “arm” in “Military” family. Some families should so have a closed list of values as other could accept new tags. Families could be as familiar as “Food” or “Clothes” for instance but also very specific as “Immunochemistry/Enzyme-Linked Immunosorbent Assay” for (very) specialized users.

. A rule could oblige commercial posts to wear the “Commercial content” tag (this is my main motivation, but this is another story …).

. A web app could then allow searching in the central index of tags on families and tags, using SELECT, AND and OR statements, directly with command lines or using a user interface. Then it will return the user the list of URLs of Joplin notes (with maybe an excerpt of files). In short: Exactly the same as all web search engine as it should be a web search engine, indexing tags of Joplin notes in place of full text of web sites.

Interest for content creators: No need to create and maintain a blog, no need to compete with commercial content that use SEO techniques and hide their blogs in Google search. And last but not the least: They remain proprietary of the content they publish; they remain always capable to edit or delete or reuse it.

Interest for content consumers: Get accurate results including or not commercial content .

Additional features for V2: Reboot Collaborative work requirement, “private” publishing using encoded tags, …

Work: Posting tags to the central index, browsing it and retrieving URL’s of content is quite easy to realize because this is about new features. The most touchy work should be Joplin access notes not only from the local database but also from URL’s of web repositories.

2

I thx for the input, that could be quite a change in the code but that has to be answered by @laurent.

I like your approach the only think what has to be taken into account, how to make notes searchable by the other apps?
If you store the notes on Nextcould, Nextcloud search could do it. If not there must be an API allowing to send search queries, isn’t it ?

3

Using the index of tags which can be implemented with a traditional RDBMS

On local notes are stored with SQLLite - good choice - but in NextCloud, may be in order to manage replications conflicts, as independant md files you can access using WebDav. There are probably authentication things to fix but folder/file sharing should fix this (however I don't get anything on my screen when I try to share a file in Nextcloud ...)

4

sorry I meant full-text search of the notes, that would only allow querying against tags