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

Deleted comments cause the ^^ notation to point to the wrong comment #1024

Open
tillulen opened this issue Sep 15, 2019 · 7 comments
Open

Deleted comments cause the ^^ notation to point to the wrong comment #1024

tillulen opened this issue Sep 15, 2019 · 7 comments

Comments

@tillulen
Copy link

When your comment contains a ^^^ reference to one of the comments above and someone deletes a comment that comes after the referenced comment, the ^^^ link will point to a different comment than originally intended. That is confusing and counter-intuitive, especially for the readers who have never had a chance to see the deleted comment.

@tillulen
Copy link
Author

We have two options. First, we can edit the text of existing comments to adjust the number of carets whenever a comment is deleted. The downside is that there will inevitably be some false positives where a user carefully creates some ASCII art or smiley faces and our parser mistakes that for a comment reference and breaks it.

Second, we can keep the original text of a comment intact but annotate it with metadata containing the ids of the comments referenced by every ^^^ sequence. Clients will use that metadata to highlight the right comment rather than count the number of carets. This option introduces complexity and requires client-side support. Tracking comment references according to the author’s intent when they edit their comment after some comments above have been deleted is going to be rather non-trivial.

@tillulen
Copy link
Author

Should this bug be filed with the server, the client or both? I’m not sure.

@tillulen
Copy link
Author

A third class of solutions involves having a permanent placeholder for every deleted comment. We can show those placeholders to the users, which will be great for correctness but will look ugly.

If clients hide the placeholders (but still use them to determine the intended target of a ^^^ reference), the authors of subsequent comments will enter the wrong number of carets because they can’t see any placeholders.

@davidmz
Copy link
Member

davidmz commented Sep 15, 2019

We already have a partially implemented solution with playholders. We already show placeholders for comments from blocked users and comments in the archive. The server has support for a deleted comments type: https://github.com/FreeFeed/freefeed-server/blob/freefeed_release_1.68.0/app/models/comment.js#L14-L17

@davidmz
Copy link
Member

davidmz commented Sep 15, 2019

It is only left to replace the removal of the comment on the server to replace it with a placeholder.

@atarka
Copy link
Contributor

atarka commented Dec 20, 2019

What if we just make ^ link an absolute link to comment id? It solves soooo many problems:
a) banned users that disappear from comment stream are automatically accounted for individually for each user
b) deleted comments are automatically accounted for
c) mentions are now possible - we can directly notify users when you refer to their comments via ^ link
d) ^ can even be patched mid-comment so when you refer to a comment and another user posts his comment before you finished yours, you don't have to patch it after you post yours, it will be adjusted accordingly.

refererred comment ids can be stored as metadata for a post and automatically rendered properly on client.

@tillulen
Copy link
Author

@atarka Do you think we also need to store the substring coordinates where the ^^^ characters appear in a comment to make those metadata independent of any parsing algorithm that detects the ^ references? Currently the official Freefeed.net client’s parsing algorithm has some false positives where it highlights parts of a ^_^-style smiley as ^ references, so the algorithm might change in the future. Also, different clients might want to parse ^-references slightly differently, which may complicate things.

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

No branches or pull requests

3 participants