-
-
Notifications
You must be signed in to change notification settings - Fork 113
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
Ephemeral items #570
Ephemeral items #570
Conversation
I'm torn on charging for ephemeral items. Happy to be to be outvoted. It seems kind of big brother-y to me and complicates things more than we might want. Every fee has to be communicated as a receipt. |
Make it free and let's see! I agree, it's big brother-y. We're not trying to prevent any abuse like spam here. Charging fees for deletes makes us less privacy focused. So I changed my mind on that, especially because you mentioned yesterday that we charge sats to prevent abuse, not to make them pay for something like storage costs since they're negligible :) |
I'm good with making it free. It will make the changes a lot simpler. Just for the sake of discussion, I thought it made sense to charge because deleting messages kinda lowers the quality of the experience for other stackers, so increasing the reward pool felt like a nice compensation for that. Plus, manual deletes are still free, this was just charging a fee to have it handled automatically. But if we think free is the right first approach, I'll make the necessary adjustments! |
Yes, that was my point but @huumn convinced me that it's not a good argument because it's a runaway hypothesis and it makes sense to favor interests of producers:
Also (to put it more into my own words), if we would charge fees just for the sake of it - so without proofing that it's actually beneficial for the overall experience on SN - then stacker and SN incentives start to drift which is a bad precedent. Keep in mind here that we're stackers on SN ourselves. Even though I can't see myself using this feature right now ... how would I feel if I want to in the future but then have to pay for it? We also had an internal discussion where I asked if we have a moat or if we even want a moat a few weeks ago.
Truly inspirational but still kinda lol because it reminds me of Konfuzius and the "There is no spoon" meme: |
backend impl and some of the UI for ephemeral item support more to come, this is just a WIP so far Consolidate client-side ephemeral fee logic in FeeButton components for easier reuse * update the update_item function to handle the case where an item was not ephemeral, but now is, so we charge the user accordingly * introduce `hasDeleteCommand` for a better logical abstraction for some use cases in the code * introduce `EPHEMERAL_FEE_SATS` which is derived from `EPHEMERAL_FEE_MSATS`, so we don't have to the same calculation over and over Remove fees for ephemeral items * remove unused markdownField prop in FeeButton * remove empty migration minor code cleanup Centralize delete item by author code to reduce duplication
0a55d28
to
b96a992
Compare
Closes #472
Introduce support for ephemeral items, i.e. items that delete themselves after a specified amount of time.
Stackers can enable this by including text in their items that follows this pattern:
@delete in <number> <unit>
e.g.
@delete in 1 minute
,@delete in 5 days
, etc.<number>
must be a positive integer<unit>
must be one of:second
,minute
,hour
,day
,week
,month
,year
, or the plurals of eachIf there are multiple "delete commands" found in the text of an item, the last command found in the text is honored.
If an item is edited, the delete commands are re-evaluated. In other words, if there was a delete command originally and it was removed in the edit, the deletion will not occur. Likewise, if there was not a delete command originally but one is added, it will take effect. Finally, if the delete command is changed in an edit, the old one will no longer take effect but the new one will.
Making an item ephemeral does not cost the stacker any extra sats (see discussion on this PR for context).
Note that since link posts don't have a text property, they cannot be ephemeral.