Self-destructing comments

[ekzyis]

Is your feature request related to a problem? Please describe.

Some stackers manually delete their comments after some amount of time for privacy reasons (I assume).

This is bad UX and we could maybe accommodate their needs better.

Describe the solution you'd like

We could help them by providing a setting in their settings and/or during posting/commenting that will delete their comment automatically.

We could charge extra sats for that since I think we don't want everyone to delete all their posts and comments after some amount of time, lol. The faster it gets deleted, the more sats it requires?

Describe alternatives you've considered

• a script that we could provide which they can run to do it themselves

Additional context

https://stacker.news/items/245650

[ekzyis]

Another name: "ephemeral comments"

[hellmanhellman]

Forgetfulness is the only mechanism we humans have for gaining wisdom, so they say.. uhhhhh anyway so yeah I agree, lets do this 🤓

[SatsAllDay]

I am considering picking this up. I have a few thoughts/questions:

1. The title of this issue specifies comments, but should this apply to posts, too? IMO it should apply to comments and all post types.
2. What is the logic around charging more to delete it sooner? I'm not arguing against it, I don't have a strong opinion either way, I'm just curious what would be best and why.
3. What kind of options should be supported for when to delete the item? Maybe we follow the search pattern and have a few options (a day, a week, a month, a year), and then a custom date/time picker for something specific?
4. For posts, the placement of the UX seems fairly intuitive, probably another option in the options accordion section. But for comments, how might we expose this option in a clean way? I know @huumn likes to keep the Reply component clean :)
5. Do we want this to be a user-level setting or should it just be specified on a per-item basis?
6. I'm curious if folks have any ideas around implementation of the deletion. My first thought would be to store a deleteAt timestamp in the item table and have a job that runs every minute (in the worker, maybe?) that "deletes" all items whose deleteAt has passed (not delete the row, but convert the title/content to deleted by author, as we do today). Maybe there's a better implementation idea floating around?

[huumn]

The title of this issue specifies comments, but should this apply to posts, too? IMO it should apply to comments and all post types.

Yes, the symmetry is nice.

For posts, the placement of the UX seems fairly intuitive, probably another option in the options accordion section. But for comments, how might we expose this option in a clean way? I know @huumn likes to keep the Reply component clean :)

Perhaps it's a directive in the text itself? Maybe it's a "builtin" bot, in other words acts like a bot but is NOT a bot? @delete in 7 days ... we could then parse the text for @delete mentions.

This would also make it clear to onlookers that the item will be deleted soon.

I'm curious if folks have any ideas around implementation of the deletion. My first thought would be to store a deleteAt timestamp in the item table and have a job that runs every minute (in the worker, maybe?) that "deletes" all items whose deleteAt has passed (not delete the row, but convert the title/content to deleted by author, as we do today). Maybe there's a better implementation idea floating around?

I think it might be better to schedule a job to run when an individual item is supposed to be deleted.

INSERT INTO pgboss.job (name, data, startafter) VALUES ('deleteItem', jsonb_build_object('id', NEW.id), now() + interval '10 minutes');

[ekzyis]

we could then parse the text for @delete mentions.

_checks if delete is a reserved name here and realizes it is_

Where did you find that list of reserved names btw? Looks really thorough.

What is the logic around charging more to delete it sooner? I'm not arguing against it, I don't have a strong opinion either way, I'm just curious what would be best and why.

Sorry, forgot to answer. The logic was just that deleting your content faster may be more in the interest of the user but conflicts with the interests of SN. For example, assume everyone does that and SN becomes a wasteland - at least I thought it would be against the interests of SN, @huumn might disagree

But I don't have strong feelings about that. A fixed fee for any time might also be okay.

[huumn]

Google?

[ekzyis]

Google?

haha, could have thought of that. Sometimes, I think too complicated or think you're some kind of wizard, haha

[huumn]

For example, assume everyone does that and SN becomes a wasteland

I don't love runaway hypotheticals. If people delete a lot of stuff, we'll just try to make it interfere with other people's experience less.

at least I thought it would be against the interests of SN, @huumn might disagree

Stacker's interests are SN's interests. But when the interests of stackers conflict, do we favor the interests of producers or consumers? I say if content creators want to delete stuff, it's their stuff to delete. If other people don't like that, they should make better content than the people deleting stuff.

[SatsAllDay]

Thank you both for the feedback. I will get to work on this and we can iterate/adjust as we see fit!

[ekzyis]

For example, assume everyone does that and SN becomes a wasteland

I don't love runaway hypotheticals. If people delete a lot of stuff, we'll just try to make it interfere with other people's experience less.

Makes sense that we can approach this issue when it actually happens. So I agree, it's a runaway hypothesis which makes it not a good argument

at least I thought it would be against the interests of SN, @huumn might disagree

Stacker's interests are SN's interests. But when the interests of stackers conflict, do we favor the interests of producers or consumers? I say if content creators want to delete stuff, it's their stuff to delete. If other people don't like that, they should make better content than the people deleting stuff.

Also makes sense, I can see how my idea with variable fees is actually worse than the strictly hypothetical case of too many people using/"abusing" this feature. This even excludes the amount of complexity we would introduce just for that. I also think now there is no such thing as "abusing the system". If you can abuse the system, the system is just bad, lol

As you said, if there is a problem with something, the solution is not to make the experience worse but to make it better :)

Thanks for the "visionary guidelines", I appreciate it!