Mentions
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.
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. 🤔
Yeah, not sure how to do this technically. Wonder if this isn’t also a protocol concern?
An idea that I have is something like the following:
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)..contains(did)for checking if the user was mentioned – adding a flag to the inbox entryrudolfs mentioned you in a commentor whatever :)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.
Ok, so looking at the
heartwoodcode, it looks like we could extend theAliasStoretrait with something likefn lookup(alias: &Alias) -> Vec<NodeId>– this is already quite annoying that it’s notDid- but we can discuss that later when I’ve had my rampage on theheartwood, redefining what aDidactually is.From there, there are a couple of implementations of the trait 1) the policy store, 2) the address store. Since these are
sqliteDBs, it should be fairly straight-forward to implement. We would just query allNodeIds that have the matching alias – even using theLIKEcomparison 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:
Aliasesstruct fromProfileand calling the trait method@is used and filling in the text correctly on selecting the NIDheartwoodchanges because of this (more reason to migrate this stuff away :P)Maybe @sebastinez could give some kind of scope for the handler and inbox work :)