Ability to use # character to help reference any linkable object on the Nextcloud instance

[jancborchardt]

Just like @ works for people and : for emojis, # would work for objects

Similar to Twitter hashtags and GitHub reference to issues / pull requests, # would help reference objects of any type in the Nextcloud instance. It could be used in apps like Talk and Text, but also elsewhere. It would essentially be a little quick search-in-place to help quickly post links/references.

It’s probably best to do it as Twitter does it, because in their implementation you can still just type a number like #1 (referring to "number 1") normally, while the suggestion dropdown shows as soon as you type the first alphabetic character after the #.

Twitter	GitHub

Objects which could be referenced are

• Files & folders
• Talk conversations
• Deck cards or Tasks
• Calendar events
• Collectives pages
• Profiles
• Systemtags?
• …

References from this can also count towards being a related resource #28320

cc @marcelklehr @sunjam @nickvergessen @max-nextcloud @nimishavijay @marcoambrosini @juliushaertl @GretaD as discussed in the design call.

Also cc @AndyScherzinger @karlitschek and @PVince81 @ChristophWurst since this is all about cross-app integration.

[sunjam]

Other maybes...

• Bookmarks
• Comments (on files & folders) visibility
• System Tags
• Perhaps supported Nextcloud Flows could be called from this.

Might by completely out of scope, but this would also make for an awesome way to quickly share with others if it was possible to share by referencing a:

• circle
• group
• user
• project

[AndyScherzinger]

In general I think this would be nice since it saves you the trouble of looking for the "object" you want to reference, copy the link, go back to where you want to reference/paste it. The issue I currently see is its performance. While #-auto-completion for talk room titles might be fast, typing the file-name will be very slow since that is more or less the same as our current search then. So for this type-ahead feature to be very responsive with the suggestions we would need proper indexing of it via a search index nothing you can achieve with a 'LIKE' search in the database.

But yes, I think this would make life a lot easier by having a more search-based interface which is where you tend to go for with growing amounts of data to interact with at your finger-tips.

[ChristophWurst]

The implementation would be similar to the unified search. Each app that wants to hook into this needs to register this capability and when the user searches we need to ask all n apps for their results.

[nickvergessen]

the main question would be how to store the data afterwards as well.

Not sure it is satisfying if we store the resulting link afterwards in the text message, or if possible instead we find a way to map it to RichObjects so "clients"/consumers of the API can render the items afterwards, showing potentially changed names/previews etc for the items.

[Spartachetto]

First of all the idea is really cool!

Second, for your consideration: what about a character to reference tags ?

I put this question here as:

1. It could be useful to have a comprehensive discussion
2. You could pick in advance the most intuitive characters, as often the # is for referencing tags (at least in twitter)

[nickvergessen]

We can not have a character per object, tags are one object and they need to live under the same control character as well.

[karlitschek]

really good idea!!

[Spartachetto]

@nickvergessen , thanks for considering my proposal

[nickvergessen]

Just to have it mentioned. Comments API was extended in the past and allows to parse @<user> as well as @"<user>" for users.
Additionally @"guest/<guest identifier>" and @"group/<group identifier>" can be used. This was passible because user ids can not contain slashes, so it was forward compatible all the way.

maybe that could be the syntax as well for the #"<object type>/<object identifier>" on a backend level and then it can be parsed/rendered similarly to mentions nowadays.

[Spartachetto]

If you follow the syntax suggested by @nickvergessen , you could have a "default" object type that can be omitted.

What would be the default type is up to consideration. I'd think that files are too much to put them as the default.
Maybe tags...? 😁

[nickvergessen]

Default is "user" as already used across comments in all kind of apps

[max-nextcloud]

Default is "user" as already used across comments in all kind of apps

Default is user when starting with a @ - but i think @Spartachetto was proposing a default for starting with a #. One problem there might be that the default could not contain / in order to enable this. I just checked and tags can contain slashes.

However I'm not sure if the default even matters for objects... wouldn't we just have an autocomplete that lists all things matching the typed chars? Similar to unified search as @ChristophWurst pointed out.

[nickvergessen]

One problem there might be that the default could not contain / in order to enable this. I just checked and tags can contain slashes.

I still think we should use @ and then make it quoted like we do in talk. If you mention a guest, we insert @"guests/sessionid". Basically we can split on the first slash and then have the type and the identifier. For tags that could then be the ID as well and the data is translated on rendering then to show the actual tag name that has any characters.

[juliusknorr]

Just leaving this here for later, once implementing the autocompletion this can be based on the reference rendering work that has been done with #33494 which currently matches http/https links but could be reused to match any #hashreference or @reference in a text.

[juliusknorr]

• Come up with a UX/UI spec for the insertion/search (similar to / on notion/confluence)

[juliusknorr]

@jancborchardt @nimishavijay Could you mabye come up with some UI mockups about how this autocompletion should behave for different examples like:

• Insert a file
• Insert a deck card
• Insert a github ticket
• Insert a calendar events
• Insert a link to a profile

From the previous discussion i think we should mostly stick to how notion does it and avoid directly searching due to performance reasons, but it would be good to have some spec available from the UI side.

[jancborchardt]

@juliushaertl btw, since Notion and Confluence (and Slack) use / we should probably do the same.

And interaction-wise, I agree we should stay pretty close to them.

So to be light on performance and do it similar to Notion, when you put in a slash, it would show a list like the emoji inserter, just with the list you posted above? And then when you type more it could start searching?

Let me know what the technical possibilities and restrictions are, maybe a call is better to spec this out.

[juliusknorr]

@julien-nc A few things we chatted about but also some more things to keep in mind:

• Actual implementations of reference autocomplete/picker still needs discussion with designers (e.g. for GitHub a proper search/autocomplete might be hard)
• We need to implement this autocomplete mechanism in text but also https://nextcloud-vue-components.netlify.app/#/Components/NcRichContenteditable

[juliusknorr]

From the discussion with @julien-nc

UI flow

• UI User enters /
  • First level picker is shown for the reference provider type
  • After picking that the individual picker
    • If registered: Custom UI with registering a vue componentn for the reference provider picker
      • e.g. for files, potentially github/gitlab
    • If available: Search through unified search (backend of reference providers would need to expose supported search providers)
      • Same layout as unified search UI
    • Default: Text input for URL

Implementation details

• Require a reference provider to be able to search and autocomplete, as without a rendering, inserting doesn't make much sense
• Server: Add new interface to let reference providers return a list of supported search provider ids
• Server: We need to pass registered reference providers and search handlers from the backend to the frontend
• No automatic matching for search providers
• Text/talk input component
  • on type / render the vue-richtext PickerComponent
• vue-richtext
  • Used for registering custom picker views
  • Implements the PickerComponent which emits an event to text/talk input once the reference was selected
• Possible design discussions:
  • Search results may have different title/description than what the reference provdider will show then actually.
• Implementation steps:
  • Server: Implement the new interface for returning serach provider ids in the reference provider
  • PickerComponent: Implement picker component with input field + search results
  • Text: Implement /command and triger the picker component
  • vue-richtext: API to register custom picker view for reference providers and render them in the PickerComponent
  • nextcloud-vue: Implement /command in the - NcRichContenteditable component
  • Talk: Switch to the - NcRichContenteditable component for the message input

[nickvergessen]

Since in talk we use / for commands (and that is expected pattern across many chat platforms), is there a way to have that either suggest commands as well, or at least display something telling users that commands also work, etc?
It's only relevant on the first character of a message as commands are the full message.

[juliusknorr]

Right, might be something to then discuss with @nimishavijay and @jancborchardt if we should settle on a different character (like #)

[AndyScherzinger]

@ChristophWurst could you please check with @julien-nc if there is an "easy" way to integrate the link-picker component in mail? Potentially in a stripped down way to limit it to features that work for mail? Thanks in advance.

[juliusknorr]

Closing as the server related topics are finished

[ChristophWurst]

@ChristophWurst could you please check with @julien-nc if there is an "easy" way to integrate the link-picker component in mail? Potentially in a stripped down way to limit it to features that work for mail? Thanks in advance.

nextcloud/mail#7986. Sorry, somehow missed the comment here.