Although I agree we should focus on public posts first, I strongly approve to do it for limited posts later.
@jhass: I think @augier just had a bit of trouble explaining his solution, but if I understand it right, I think it’s a very good solution.
When the URL is requested, here is what is happening on the server:
The ID of the post (:id) will give the contacts of everyone involved in the post (post author + comments authors) + the list of contacts the author allowed for the post (the visibility list)
Then the ID of the user (:user_handle) will give its contact list
We intersect the visibility list with the user’s contact list; we get the list of user’s contacts that can actually see the post
We merge 1. and 3.
We remove the user itself
The result is the list of contacts the user can mention in his comment.
Creak: I repeat, a pod the post was sent to, which does not host the author of the post, doesn’t and shouldn’t know the contact list of the author nor the full list of recipients of the post.
@jhass: I see your point, but what is the solution then? I understand we can’t trust an external pod, but it seems that this problem is unsolvable within these conditions. In order to have this feature, I always see a contact exchange.
The other solution would be to allow to mention the post author, the comments authors and the user’s contacts. Then if the contact mentioned in the comment can’t see the post… well too bad for him!
That would work without having one pod to see the contacts of a user from another pod. But for the end user, that will be very confusing.
The compromise to have this feature somewhat is rather to limit the mentionable contacts to those that already participated in some way (commented, liked, reshared).
That being said, I think most of the time, this feature is only used to mention the post author or the comments authors and, less frequently, to ask someone for an opinion on the matter.
That would be easier to understand for the end user that, in limited posts, he can only mention active users on the post.
(BTW an active user could be someone that liked or reshared the post, doesn’t it?)
Bumping this old discussion with a question about the implementation of this excellent feature.
It’s been pointed out to me that mentions in comments aren’t included in the @Mentions stream.
Was it considered whether or not they should be included in that stream when the feature was implemented? I’m not saying they should be – I’m not sure whether it’s better to include them or list only mentions in posts – but I thought it worth raising here in case this is something that was overlooked during the earlier discussions.
I feel like mentions in comments should’t be included there. All the other links there refer to posts, not to comments, so for me it would be confusing if it was different for mentions.
With /notifications?type=mentioned_in_comment there’s a nice way available to find all these mentions and for me, this is enough.
I’m not sure. I think it was intentionally not added to the mentions stream, because (as wai said) until then all streams were only about posts. But since the liked and commented streams, this is already a bit different (it’s still not about the content of a comment, but already comments).
I think it could be useful to find all posts where you were mentioned (in the text or the comments), because going via the notifications is far more hidden than the mentions stream. So I probably wouldn’t be against it, if somebody wants to change that behavior.
I feel like my UX expectations would lead me to a “it should be included in the mentions stream for consistency”, but then reality hits: stream generation is already a complicated mess; and complicated in both database terms and code terms. I’m oversimplifying here, but in basic terms, we loop through each post that you can see and check if it’s relevant for the current stream. For the mention stream, things are already a bit more complicated: we have to look for posts that have no direct connection with the person querying the stream. And things would get more complicated if we added more types of sources.
Now, a mention in a comment and a mention in a post is more or less the same database-wise, so this probably could be done without much pain, but it would probably lead to more “what should be included in what stream” changes, and that could be painful…
Thanks for your replies, all of you. Just to make it very clear, I’m happy for it to remain as it is; it does make sense as it is when looked at in one way. It was pointed out to me that comment mentions weren’t included, so I thought I’d check whether that was intentional/desired or whether it was something that was overlooked when comment mentions was implemented.
