Radish alpha
r
rad:z4D5UCArafTzTQpDZNQRuqswh3ury
Radicle desktop app
Radicle
Git
Mentions
Open rudolfs opened 1 year ago feature

While we said we won’t do them for the current “sprint” (March), I keep wanting to tag people in the app. So I think it’s something we should maybe start at least talking about how we could pull this off.

It would be awesome if you could start typing @ in any input field and it would show you a dropdown of available aliases that your node knows about. You could keep typing and the options would narrow down, hitting tab would select the top-most option from the dropdown. It would just save the full DID in the underlying data model. We’d do the DID <-> alias look-up on render.

And then on the other end we’d have to scan all data for DIDs and for every mention (DID === your node ID) we’d create a notification.

z6MkkfM3...sVz5 commented 1 year ago

I fully agree that we need to do this at some point. Also I think the typing @ and selecting from aliases should be able to be done.

The thing that is a bit fuzzy for me is the scanning all data for DIDs and create notifications. But maybe that could be something to take into account for the next iteration of the inbox. 🤔

rudolfs commented 1 year ago

Yeah, not sure how to do this technically. Wonder if this isn’t also a protocol concern?

fintohaps commented 1 year ago

An idea that I have is something like the following:

  • For UX purposes, there could be a reverse lookup of aliases. So, in radicle, there would some functionality that takes an alias and gives you a list of DIDs – this could even be scoped by the remotes in the repository. That would give the desktop a way to give a dropdown of DIDs when I type something like @rudolfs (can later become reactive by taking a prefix and giving the completed aliases, then follow up with the DIDs).
  • Selecting the DID would then add the text in a special form, e.g. markdown link @fintohaps.
  • On the other side, when an inbox item is being processed, we could do .contains(did) for checking if the user was mentioned – adding a flag to the inbox entry
  • That could be displayed as rudolfs mentioned you in a comment or whatever :)
rudolfs commented 1 year ago

This all sounds great and also how I imagined it would work. Would you be willing to scope out this work a bit more? To see what’s missing in the protocol and how we could get to an mvp for this.

fintohaps commented 1 year ago

Ok, so looking at the heartwood code, it looks like we could extend the AliasStore trait with something like fn lookup(alias: &Alias) -> Vec<NodeId> – this is already quite annoying that it’s not Did - but we can discuss that later when I’ve had my rampage on the heartwood, redefining what a Did actually is.

From there, there are a couple of implementations of the trait 1) the policy store, 2) the address store. Since these are sqlite DBs, it should be fairly straight-forward to implement. We would just query all NodeIds that have the matching alias – even using the LIKE comparison to do a “fuzzy” search.

Without any foreseeable issues, that’s probably a week of work + review.

I’m not sure what the scope would be for the desktop then. Something like:

  1. Integrating some kind of request handler for asking for the NIDs – this is basically getting the Aliases struct from Profile and calling the trait method
  2. Frontend integrating some kind of dropdown when @ is used and filling in the text correctly on selecting the NID
  3. For the inbox end of things – I’m not sure how we’d incorporate the mention feature locally, I think we would need to add some kind of column to the inbox DB. Might need some heartwood changes because of this (more reason to migrate this stuff away :P)
  4. Frontend needs to change the display text based on mention or not.

Maybe @sebastinez could give some kind of scope for the handler and inbox work :)