Discuss concept: List All Notes

[cfstras]

Motivation

Hi 👋
I'm using a few instances of Codi (or Hedge 😁 ) privately and at work, and am always kind of bummed out that there's no central discovery feature.
If a Pad is not in your history, or you don't have an up-to-date "all our pads"-pad, you might never find that one note again.

This is why I started to work on a feature to list all notes there are on the server.
I would mostly like to gather some feedback, whether something like this is wanted, and what it would take to get it merged, if I get to actually implementing it.

Overview

• Configuration Option allowIndex to turn on the feature
• Only accessible to logged-in users
• Lists all non-empty, accessible (non-private or owned by yourself) notes
• Provides pagination
• Nicely formatted list, suitable for very long listings
• Performance-tested (server-side pagination & filtering?)

Further Work

Just an idea that could make this more awesome in the future. I want to wait what comes out of the linked discussions, though.

• Detect prefixes / folder paths in titles/tags/aliases/etc to allow for folder structure
  • cf. https://community.codimd.org/t/inter-page-navigation-structure/118, Discuss group concept of organize notes #178

Implementation

Currently, there is a very basic but functional prototype in here: https://github.com/cfstras/codimd-server/commits/feat/pad_index
I'll hopefully find some time to continue work on that soon...

[ccoenen]

I would like to suggest to not mix this with folders/prefixes/tags (as per "further work") at this stage. Those are huge ongoing discussions that will only slow this particular request down.

[cfstras]

Yeah, I thought so. It's mainly just an idea that could take it further. I edited the post to be clearer on that.

[davidmehren]

Hi @cfstras!

We are currently working on a 2.0 release, which will come with a brand new API and frontend. I think you idea would be a nice addition to the current plans for 2.0 (which already include a "list my own notes" view).

To include this feature in 2.0 we would need to

• build UI for that (pinging @codimd/frontend)
• include it into our API: the current draft of the public API can be found in WIP: Public API v2.0 #367. We would need to add a GET /notes and somehow handle the "this feature is disabled" case.
• add all the code in the backend (will have to wait a bit, we are still in the planning phase there)

[DougInAMug]

(Just want to add that this functionality, however its implemented, would be really useful for an organization I'm part of!)

[cfstras]

Sounds great!
I don't want to get in the way of the release, and my time for side-projects like this is very scarce right now. However -- if there's anything I could build to get this further along, let me know where I can help without causing a mess :)

[truh]

If this feature is added I would like a privacy level for notes at which notes can be shared by URL without appearing in the list of all notes.

[cfstras]

Hmmm... sounds interesting. Generally, I think the privacy levels are a bit confusing, but that's a different discussion.

For the first draft, you could always turn the feature off.

[DerMolly]

@cfstras Which privacy levels are you referring to?

[cfstras]

The privacy level that can be set on a note. It always takes me way to long to parse which level I want to use.
I'd prefer to see something like this instead, but maybe that's just the unix talking:

Level	You	Users	Public
freely	📝	📝	📝
editable	📝	📝	📄
limited	📝	📝	❌
locked	📝	📄	📄
protected	📝	📄	❌
private	📄	❌	❌

[truh]

We currently also have freely, which can be edited by everyone.

Another consideration are public instances that allow guests to create notes. I think for public instances it would be rather bad if all the guest notes can just be listed by anyone who signs up.

[cfstras]

That's why I planned for this feature to only be accessible for logged-in users.
Updated the table.
I misread your comment -- Yes. This feature is probably not good for public instances.

[davidmehren]

Hi everyone!

In the meantime, we have continued planning for 2.0 and developed a new permission system. It basically mirrors Nextcloud: you can share a note to users or groups and can optionally enable editing for each share. There will be default groups "everyone" and "everyone logged in" to mirror the old behavior. Based on this, the 'list all notes' feature could look like this:

• config option to turn on the feature
• for non-logged-in users: list all notes shared with "everyone"
• for logged-in-users: additionally list all notes shared with "everyone logged in"

Note that there is no way to not have a public (as in 'shared with everyone') note appear in the global list, if the list-feature is enabled. The "URL share" feature which would solve this problem has been proposed in #471 and will have to wait until after 2.0 as it adds quite a bit of complexity.

[rastapopougros]

Thanks, I made this request 2 years ago, when there was only one project, here : hedgedoc/react-client#439
So +1000 :)

It totally fits our usage :

• we are a compagny
• user accounts are for people inside
• when we share a direct link to a pad to clients, they are anonymous, and so they just have to see only the one we shared
• we, inside, want to see all notes created which are public or shared with us (= all notes accessible to my particular account)

[ccoenen]

Note that there is no way to not have a public (as in 'shared with everyone') note appear in the global list, if the list-feature is enabled

I am not a fan of this. One is an admin's choice the other is a user's choice. It is not immediately obvious how a server is configured. How would you communicate "this not will be publicly listed and may be indexed by a search engine and/or found by random strangers"?

Additionally, an admin might choose to change this setting from "no list feature" to "list feature enabled" at any time in the future. They might not even know the consequences, or may not care, or may not have the means to notify all their users.

To sum it up: I do not believe "public listing a note" should occur without making an obvious choice to do so.

This is not against having a list "like" this, I just thing that this should be tied to something very explicit. Even if it is a per-user setting (not per-server). Yes, even if that user-setting might default to "everything listed" on a company server.

[davidmehren]

Good point @ccoenen. I'm not sure about making this a per-user setting though, I would propose the following:

• config option to turn on the global list (the admin can enable/disable the list altogether)
• if you share a note to "everyone" or "everyone logged in", an option "show in public list" is shown
• the admin can configure the default setting for this option
• only notes that have that option enabled will be shown in the public list

Would everyone be happy with that?

[ccoenen]

so a note has an additional, new, property "listed publicly" in its database schema (or something to this effect)? I think that's a good solution.

[davidmehren]

To centralize the discussion about this topic, I created #994.
Please take a look and comment if you feel I missed an important aspect.
Thanks!