Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support twitter-style @username mentions #149

Open
umputun opened this issue Jul 9, 2018 · 7 comments
Open

support twitter-style @username mentions #149

umputun opened this issue Jul 9, 2018 · 7 comments

Comments

@umputun
Copy link
Owner

umputun commented Jul 9, 2018

if every @username in the comment's text translated to user info and returned back by API as a list of mentions []store.User we could do some nice things with this, like:

  • click on @username can show user info
  • reply RSS may include those even if it wasn't the actual reply
  • potential in-browser notification

The biggest problem here - the server doesn't know anything about @username until user posted at least one comment. Even for such users, we don't have any method to translate username to ID directly.

@akosourov
Copy link
Contributor

akosourov commented Jul 22, 2018

@umputun what do you think about this solution:

  1. Add new bucket to store user info per site. Key is user_id and value is a new struct UserInfo like
type UserInfo struct {
    store.User
    LastTS         time.Time     // last published comment
    Count          int           // all comments per site
    ...
}
  1. Populate UserInfo bucket when user posts a comment (or even login via provider) in case this is a new user. It should be modified in several server events (like users was deleted or user published new comment).

Next steps is about ability to mention (not about showing user info)

  1. To mention @someone we need endpoint to get users (id) by name.
    2.1. Get most relative users when prefix is empty (like @ ). Maybe it could be a list of admins or last mentioned users. I think this step can be done later
    2.2. Get users by prefix (@som should return someone, sOmebody, etc). Limited up to max possible (5). For bolt db implementation we have Seek method that helps find all keys that match to prefix. Therefore if we create new bucket (index for UserInfo) and build keys like strings.ToLower(username) $separator$ user_id with values user_id it would be possible to find users by prefix name. The restriction is that this search is not case sensitive. Also it should me modified (add or delete) when data in UserInfo modifies (adds or deletes).
  2. Add something like engine.Accessor.UsersInfoByPrefix(siteID, prefix string) []store.UserInfo
  3. Add API endpoint like GET /users?site=site-id&name=prefix. This should touch engine.Accessor.UsersInfoByPrefix and should return list []UserInfo or simpler list of data contains two fields username and user_id.
  4. Add MentionIDs field to Comment struct. It should keep list of user_id that were mentioned in this comment. UI should modify it when create\edit comment (when user select appropriate user to mention)
  5. Extend RSS reply logic. If user_id exists in MentionIDs field add this comment to RSS reply.

@umputun
Copy link
Owner Author

umputun commented Jul 22, 2018

some suggestions:

  1. one method should be added - UserInfoByName(siteID, id) store.User. Implementation for bolt will need new user info bucket for such index, key=name, val=userid. Create, Put and Delete will set/remove kv. Mongo's implementation can do find by user name directly. One potential issue here - username may not be unique.
  2. UserInfoByName will be called by the server on each create/edit/preview event as a part of text parsing and will fill MentionIDs. Probably some little regex to catch @name patterns. Those mentions won't be just ids but a struct with ID and name, so probably we want to call it just Mentions.
  3. UI won't fill/edit Mentions. The only thing UI should do is to highlight @name and make a link to the same place it's doing for regular users, i.e., info block.
  4. We can drop the ability to mention users without comments. I don't see much value in mentioning someone who didn't write a thing.
  5. Prefix search is nice to have, but we can do it without new interface method(s) if we restrict context to the current post only. I think it the majority of cases this should be enough. If so, we may add Mentions (collects mentions from the whole tree) to the PostInfo and completion can be done by UI.

@umputun
Copy link
Owner Author

umputun commented Jul 22, 2018

@akosourov see also #155 Maybe we should postpone mentions implementation until bolt part switched to storm? It will simplify new index creation significantly.

@akosourov
Copy link
Contributor

UI won't fill/edit Mentions. The only thing UI should do is to highlight @name and make a link to the same place it's doing for regular users, i.e., info block.

What do you think about the situation when several users have one name? I mean how server should guess what user was selected to be mentioned if UI only send @name. I aggree that if we restrict context to post (list of possible users to me mentioned) it hardly happen. But if this collision makes sense maybe UI should encode @name in comment body to something like @name+user_id?

Prefix search is nice to have, but we can do it without new interface method(s) if we restrict context to the current post only. I think it the majority of cases this should be enough. If so, we may add Mentions (collects mentions from the whole tree) to the PostInfo and completion can be done by UI.

But maybe "site" context instead of "post" context might be helpful for customers like radio-t site. For example with "site" context each regular user will be able to post comment refering it to announcer (to leader of show). Like direct question, for example to ask something, referring to this episode (post). But maybe it can be done adding predefined list of vip Mentions to PostInfo - of course if it makes sense

@akosourov see also #155 Maybe we should postpone mentions implementation until bolt part switched to storm? It will simplify new index creation significantly.

Of course but if you have something that I can deal - I will be glad :)

@umputun
Copy link
Owner Author

umputun commented Jul 23, 2018

I mean how server should guess what user was selected to be mentioned if UI only send @name.

I don't see how moving this responsibility to the frontend will help. The user will type @blah and we have no way to realize which @blah he meant. Probably we can show a selection of possible IDs, but practically this won't help that much.

But maybe "site" context instead of "post" context might be helpful
Such a list can be too big for active sites.

it can be done adding predefined list of vip Mentions

good idea. We can also collect the latest mentions in some sort of cache (on the server side) and keep smth like 100 latest and mix them into PostInfo mentions.

@akosourov
Copy link
Contributor

@umputun I'd like to deal with something in remark where I could be helpful. I can deal with something relative to this issue (start to switching to storm, or start implementing mentions without it) or something other. So If you need help - let me know :)

@umputun
Copy link
Owner Author

umputun commented Dec 9, 2019

@akosourov sorry, missed your message. There is a ticket you may want to take a look #488

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants