damus
damus copied to clipboard
damus-io
Mute note with presence of keyword (1,000,000 sats bounty)
Tracking issues
- [ ] #2222
Bounty
1,000,000 sats posted by Karnage
https://damus.io/note1mefmevqeqqjghw4d7tzk6rp46n3sc0u3syazx2j6k8hqjxmv2svqz0fchn
User Story
As a Damus user looking to avoid notes with a particular keyword, I would like the capability to mute notes that contain a keyword I specify, so that I don't see any notes containing this keyword.
Acceptance Criteria
- User can specify a keyword they would like muted in settings
- User can see, and modify list of muted keywords by adding, or deleting words.
- If a note contains a muted keyword, the note is not displayed to user -in timeline -in universe view -in notifications -in DMs -in zaps
- User does not receive any notifications associated with notes containing this keyword
- User has an option to mute from everyone, or from people user does not follow
- User can select a mute duration: 24 hours, 1 week, 1 month, or forever. Default is forever.
- If no words are muted, the following message is displayed:
You aren't muting any words.
When you mute words you won't see any notifications for notes that include them, or see notes that include muted words in your timeline.
- Hashtag of muted word is muted.
- If in replies/thread, muted notes are collapsed to a single row stating: "Note contains a word you've muted." and moved to bottom of reply thread.
- User has a tappable option to show the muted note
Show(similar to
) - Bonus: user can mute a phrase as well (for instance the spammy/zero effort string "Hello world! #introductions")
@jb55 mentions this is related to nostrscript, and is on list of top priorities
- Muting words, nostrscript filters
Regarding acceptance criteria 6:
User can select a mute duration: 24 hours, 1 week, 1 month, or forever. Default is forever.
How would we feel about removing that item in the acceptance criteria? Currently I'm using the NIP standard for mute lists (see #1718). Which would make time based mute lists tricky. Especially for a client device that isn't guaranteed to always be online.
Please see @jb55's post here regarding similar difficulties for scheduled posts: https://github.com/damus-io/damus/issues/1241#issuecomment-1776279430.
There are some workarounds we can do here. But none of which really apply to the root ticket of Mute note with presence of keyword. I will also mention that Damus today does not support mute durations for threads or users. So regardless, this should be broken into two tickets. One for Mute note with presence of keyword & another for Allow user to choose mute duration. It's not one unit of work.
However. I'm hesitant to ignore that acceptance criteria because there is a bounty on this issue. It would be unfair to the bounty payer to adjust the requirements after the fact without their approval.
Also PS: I am planning on implementing the Bonus: user can mute a phrase as well (for instance the spammy/zero effort string "Hello world! #introductions") acceptance criteria.
cc/ @jb55 @alltheseas
@karnagebitcoin
How do you feel about removing the duration acceptance criteria? If we do this, the likelihood we roll out this feature soon increases substantially.
User can select a mute duration: 24 hours, 1 week, 1 month, or forever.
On Wed, Jan 10, 2024 at 02:45:31PM -0800, Charlie Fish wrote:
Regarding acceptance criteria 6:
User can select a mute duration: 24 hours, 1 week, 1 month, or forever. Default is forever.
How would we feel about removing that item in the acceptance criteria? Currently I'm using the NIP standard for mute lists (see #1718). Which would make time based mute lists tricky. Especially for a client device that isn't guaranteed to always be online.
Why would needing to be online affect this? Wouldn't you just need to store when to unmute? Then whenever you're active it can just check if its still muted. This is a bit different than scheduled posts. but yeah they could probably be separate tasks. We should have mute durations for users as well.
Why would needing to be online affect this? Wouldn't you just need to store when to unmute?
@jb55 If we are just talking about offline storing of mute duration, that is possible, yes. Easy almost.
The problem is with the kind:10000 mute list (#1718). Once that mute duration has passed, Damus (or some client) needs to be active to sign & relay an updated kind:10000 mute list that removed that item where the mute duration has passed.
I guess it's possible to do mute durations and sync it next time you're online. But there is a chance that your Damus mute list wouldn't match your kind:10000 mute list.
Example:
- User mutes Account A for 1 month
- User never uses Damus again (or deletes the app) 😢
- 1 month passes (or longer)
- Users kind:10000 mute list still contains Account A
Maybe a minor edge case, but an edge case nonetheless.
On Wed, Jan 10, 2024 at 04:13:53PM -0800, Charlie Fish wrote:
Why would needing to be online affect this? Wouldn't you just need to store when to unmute?
@jb55 If we are just talking about offline storing of mute duration, that is possible, yes. Easy almost.
The problem is with the kind:10000 mute list (#1718). Once that mute duration has passed, Damus (or some client) needs to be active to sign & relay an updated kind:10000 mute list that removed that item where the mute duration has passed.
I guess it's possible to do mute durations and sync it next time you're online. But there is a chance that your Damus mute list wouldn't match your kind:10000 mute list.
Example:
- User mutes Account A for 1 month
- User never uses Damus again (or deletes the app) 😢
- 1 month passes (or longer)
- Users kind:10000 mute list still contains Account A
Maybe a minor edge case, but an edge case nonetheless.
yeah I wouldn't get worked up over this edgecase. Having just an expiry time that is checked by whatever app you login to is fine.
Not sure if this is spec'd on the mutelist NIP but that would be cool if it was.
yeah I wouldn't get worked up over this edgecase
Fair enough.
Having just an expiry time that is checked by whatever app you login to is fine
Don't quite understand this. In the kind:10000 spec I didn't see any way to specify an expiry time. Obviously if that existed, it would be really easy, and this conversation probably wouldn't even be occurring 😆.
So the only way to do it is Damus sending a new kind:10000 mute list after the expiration time has passed. Which is possible if we accept the edge case that Damus has to be active for that new mute list to be signed & relayed.
Just wanna make sure we are on the same page about that.
If there are no issues I'll move forward with storing the expiration time locally (on Damus only). And once that time passes, if Damus is active, it will relay a new kind:10000 list removing that muted item. The expiration time/duration itself will never be relayed to other clients. It will be stored locally only. Only other clients/relays will see that an item has been removed after Damus is active and it sends that new kind:10000 list.
Totally fine by me if the duration is not implemented with this, and is split off into another task if it's too much. I just hope that it does get implemented eventually because I often forget to unmute. I use mute mostly as a "timeout" to get something out of my sight for a while, but it doesn't mean I never want to see it, except in cases where I do (crypto shit)
On Wed, Jan 10, 2024 at 04:46:13PM -0800, Charlie Fish wrote:
yeah I wouldn't get worked up over this edgecase
Fair enough.
Having just an expiry time that is checked by whatever app you login to is fine
Don't quite understand this. In the kind:10000 spec I didn't see any way to specify an expiry time. Obviously if that existed, it would be really easy, and this conversation probably wouldn't even be occurring 😆.
we can add it to the spec?
So the only way to do it is Damus sending a new kind:10000 mute list after the expiration time has passed. Which is possible if we accept the edge case that Damus has to be active for that new mute list to be signed & relayed.
it's not the only wany to do it
@jb55
we can add it to the spec?
Ok I'm new to that. I'll look into this tomorrow and let you know if I have any questions. If you have any tips/pointers in the meantime, let me know.
Here is the lists NIP, which includes mute kind 10000.
https://github.com/nostr-protocol/nips/blob/master/51.md
Would e.g. an expiry time be an added and optional tag?
On Wed, Jan 10, 2024 at 06:03:19PM -0800, alltheseas wrote:
Here is the lists NIP, which includes mute kind 10000.
https://github.com/nostr-protocol/nips/blob/master/51.md
Would e.g. an expiry time be an added and optional tag?
I would add the expiry as an extra element of the tag. For example:
["word", "etf", "1706149129"] ["p", "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245", "1706149129"]
aka "mute jb55 and the word etf until 2 weeks from now"
yeah you can pay them out. there are a few issues that we are fixing but it seems to be working.
@karnagebitcoin My nostr npub is: npub16amr0pgqzl8l57npcupjmv8j3055042g07w4qj4tu3zf4yd48nlsh96569. My lightning address is: [email protected]. For verification you can also view it in the commit description of the commit @jb55 merged in: f341a37
@fishcharlie fyi tested yesterday - DM with muted word is shown/not hidden. I wonder if we should have a "spam" or low signal folder perhaps based on muted words, and web-of-trust.
@alltheseas Mind creating a new ticket for that and assigning me? There is for sure some cleanup work we have to do.
Also I was gonna create a ticket for this issue @jb55 reported: https://damus.io/nevent1qqsyspz3g8qfctjh5aclktgxxlkpmrwvrg3gn57ux9gcsldduhs7y8qpy9mhxue69uhhyetvv9ujumtfdej8xtnrdakj7mn0wd68ytmkxyhhwucprpmhxw309akk7mnpvshx5c34x5hxxmmd8gurqwpsqy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqgswaehxw309ahx7um5wgh8w6twv5q3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7qgdwaehxw309ahx7uewd3hkcqgcwaehxw309amk2mrrdakk2tnwdaehgu3wwa5kuegpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg4waehxw309ajkgetw9ehx7um5wghxcctwvstmqgk3
However, I haven't gotten a chance to create that ticket yet. If you have some extra time and want to that would be great.
Other things @jb55 mentioned in direct messages that I haven't gotten a chance to create tickets for yet:
- another thing from testing: I can't see to change the duration when adding a word I'm guessing non-words as well
- also we should put the muted words at the top, my mute list is huge and I have to scroll down to see it. or maybe these could be tabs
On Wed, Jan 24, 2024 at 08:23:09AM -0800, Charlie Fish wrote:
Other things @jb55 mentioned in direct messages that I haven't gotten a chance to create tickets for yet:
- another thing from testing: I can't see to change the duration when adding a word I'm guessing non-words as well
- also we should put the muted words at the top, my mute list is huge and I have to scroll down to see it. or maybe these could be tabs
yeah these are most important.
Also:
I can't seem to change the duration when adding a mute item.
re-opening this because it's not quite ready yet. we should probably have a policy to only pay out when code is ready not when it's merged, since we can sometimes merge code that is not ready. @karnagebitcoin let me know if you want a refund for now since I said it was ready when it was not.
re-opening this because it's not quite ready yet. we should probably have a policy to only pay out when code is ready not when it's merged, since we can sometimes merge code that is not ready. @karnagebitcoin let me know if you want a refund for now since I said it was ready when it was not.
no refund necessary. I trust that it will work eventually ;)
@jb55 you ok to keep these open til merged to testflight or appstore?
This one is on master, and not yet on appstore.
On Tue, Mar 19, 2024 at 02:37:36PM -0700, alltheseas wrote:
@jb55 you ok to keep these open til merged to testflight or appstore?
We don't really have a mechanism for that yet, since github closes things automatically when patches/PRs are merged.
We could perhaps have a testflight branch and configure github to close the issue when it's merged into that? Otherwise we would have to treat master as our testflight branch and use another for tip dev.