Mute note with presence of keyword (1,000,000 sats bounty) #856

alltheseas · 2023-04-02T23:49:39Z

Tracking issues

Muting bugs #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")

The text was updated successfully, but these errors were encountered:

alltheseas · 2023-08-01T19:47:13Z

@jb55 mentions this is related to nostrscript, and is on list of top priorities

Muting words, nostrscript filters

alltheseas · 2023-11-17T15:38:14Z

Would be useful to mute a phrase

fishcharlie · 2024-01-07T20:27:43Z

Going to start working on this.

Muted users + unfollowed users test ------------------------------------ PASS Device: iPhone 15 Pro simulator iOS: 17.0.1 Damus: This commit Setup: - Two phones running Damus on different accounts - Local relay with strfry-push-notify test setup - Apple push notification test tool Steps: 1. Unfollow the user who is the author of the saved notifications 2. Disable notifications for people you don't follow 3. Trigger a push notification (Resend push notification from test tool) 4. Ensure that the notification is not received on the other device 5. Enable notifications for people you don't follow 6. Trigger a push notification (Resend push notification from test tool) 7. Ensure that the notification is received on the other device 8. Mute the user who is the author of the saved notifications 9. Trigger a push notification (Resend push notification from test tool) 10. Ensure that the notification is not received on the other device 11. Unmute the user who is the author of the saved notifications 12. Trigger a push notification (Resend push notification from test tool) 13. Ensure that the notification is received on the other device Result: PASS Closes: #1705 Signed-off-by: Daniel D’Aquino <daniel@daquino.me> Signed-off-by: William Casarin <jb55@jb55.com>

fishcharlie · 2024-01-10T22:45:20Z

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: #1241 (comment).

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

alltheseas · 2024-01-10T23:18:16Z

@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.

jb55 · 2024-01-11T00:04:17Z

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.

fishcharlie · 2024-01-11T00:13:42Z

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.

jb55 · 2024-01-11T00:38:35Z

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: 1. User mutes Account A for 1 month 2. User never uses Damus again (or deletes the app) 😢 3. 1 month passes (or longer) 4. 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.

fishcharlie · 2024-01-11T00:46:03Z

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.

karnagebitcoin · 2024-01-11T01:12:51Z

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)

jb55 · 2024-01-11T01:46:00Z

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

fishcharlie · 2024-01-11T01:49:26Z

@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.

alltheseas · 2024-01-11T02:03:09Z

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?

jb55 · 2024-01-11T02:19:55Z

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"

fishcharlie · 2024-01-14T21:01:44Z

https://groups.google.com/a/damus.io/g/patches/c/gy7WlaGYRKE

- Adding MuteItem & DamusDuration - Changing RefId hashtag associated type from TagElem to Hashtag - This is done because in MuteItem, we can not create a RefId.hashtag TagElem instance since we don’t have a note associated with a given hashtag mute item. Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

- Adding MuteDurationMenu & AddMuteItemView - In a future patch I will update AddMuteItemView to actually update and relay the new mute list Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

fishcharlie · 2024-01-23T04:54:14Z

Thanks again @karnagebitcoin!!!

alltheseas · 2024-01-24T16:18:47Z

@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.

fishcharlie · 2024-01-24T16:22:57Z

@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

jb55 · 2024-01-24T16:59:40Z

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.

alltheseas · 2024-01-24T18:03:34Z

Added these as new issues. Links are above.

- Adding MuteItem & DamusDuration - Changing RefId hashtag associated type from TagElem to Hashtag - This is done because in MuteItem, we can not create a RefId.hashtag TagElem instance since we don’t have a note associated with a given hashtag mute item. Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

- Adding MuteDurationMenu & AddMuteItemView - In a future patch I will update AddMuteItemView to actually update and relay the new mute list Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

This patch depends on: Adding new structs/enums for new mute list - Rewrites Lists.swift to use new mute list option - This leads to a lot of changes for changing the type from RefId to the new MuteItem - Update & relay new mute list in AddMuteItemView.swift (fixing previous patch TODO) - Renames `list` to `list_deprecated` - We need to keep this since existing users might have an old mute list Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

This patch depends on: Migrate Lists.swift to use new MuteItem - Makes request for new mute list type (kind:10000) - Processing new mute list type (kind:10000) Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

This patch depends on: Receiving New Mute List Type - Changes NewMutesNotify, NewUnmutesNotify & MuteNotify to use MuteItem instead of Pubkey - Changes is_muted in Contacts.swift to take in a MuteItem instead of a Pubkey - A lot of changes here were just modifying callers of that to accept the new parameter type Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

This patch depends on: Adding filtering support for MuteItem events - Gives more specific mute reason in EventMutedBoxView - Showing all types of mutes in MutelistView - Allowing for adding mutes directly from MutelistView - Allowing for choosing duration of mute in EventMenu Related: #1718 Related: #856 Lighting Address: fishcharlie@strike.me Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

This patch depends on: Updating UI to support new mute list - Adding the ability to mute a hashtag from SearchView Related: #1718 Related: #856 Lighting-address: fishcharlie@strike.me Changelog-Added: Add ability to mute hashtag from SearchView Signed-off-by: Charlie Fish <contact@charlie.fish> Reviewed-by: William Casarin <jb55@jb55.com> Signed-off-by: William Casarin <jb55@jb55.com>

jb55 · 2024-01-28T02:18:20Z

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.

karnagebitcoin · 2024-01-28T12:15:00Z

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 ;)

alltheseas · 2024-03-19T21:37:15Z

@jb55 you ok to keep these open til merged to testflight or appstore?

This one is on master, and not yet on appstore.

jb55 · 2024-03-20T08:20:02Z

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.

jb55 · 2024-05-06T22:35:16Z

Tracking remaining issues before we can close this:

Muting bugs #2222

This was referenced Apr 4, 2023

Auto Mute hellthreads [feature request] #862

Open

How can we stop hell-thread spam? #885

Closed

alltheseas added the enhancement Improvement label Jun 30, 2023

alltheseas added the bounty Sats label Sep 24, 2023

alltheseas changed the title ~~Mute note with presence of keyword~~ Mute note with presence of keyword (500,000 sats bounty) Sep 24, 2023

alltheseas changed the title ~~Mute note with presence of keyword (500,000 sats bounty)~~ Mute note with presence of keyword (1,000,000 sats bounty) Sep 24, 2023

alltheseas added feature New feature request signal-to-noise-ratio labels Nov 17, 2023

alltheseas mentioned this issue Jan 7, 2024

Follow keyword #1858

Open

fishcharlie mentioned this issue Jan 7, 2024

Move to kind 10000 for mute lists #1718

Closed

alltheseas assigned fishcharlie Jan 8, 2024

alltheseas mentioned this issue Jan 18, 2024

Unmuting user doesn't reshow events in Home view #1888

Open

alltheseas mentioned this issue Jan 24, 2024

Filter DMs with muted keywords #1905

Open

This was referenced Jan 24, 2024

Fix cannot change duration of mute keyword item when adding keyword #1907

Closed

Separate muted keywords from muted users list #1908

Open

jb55 reopened this Jan 28, 2024

jb55 closed this as completed in 71c9bd6 Feb 26, 2024

alltheseas reopened this Mar 19, 2024

alltheseas mentioned this issue Mar 19, 2024

Phrase muting does not work #2076

Open

This was referenced Apr 14, 2024

hashtag mute is broken #2140

Open

1.9 wipes mute list (likely due to other clients) #2144

Closed

Bug: 1.9 hang / freeze ( mute related ) #2146

Open

alltheseas added the mute label Apr 16, 2024

jb55 mentioned this issue May 6, 2024

Muting bugs #2222

Open

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mute note with presence of keyword (1,000,000 sats bounty) #856

Mute note with presence of keyword (1,000,000 sats bounty) #856

alltheseas commented Apr 2, 2023 •

edited by jb55

alltheseas commented Aug 1, 2023

alltheseas commented Nov 17, 2023

fishcharlie commented Jan 7, 2024

fishcharlie commented Jan 10, 2024

alltheseas commented Jan 10, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 11, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 11, 2024

karnagebitcoin commented Jan 11, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 11, 2024

alltheseas commented Jan 11, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 14, 2024

fishcharlie commented Jan 23, 2024

alltheseas commented Jan 24, 2024

fishcharlie commented Jan 24, 2024

jb55 commented Jan 24, 2024 via email

alltheseas commented Jan 24, 2024

jb55 commented Jan 28, 2024

karnagebitcoin commented Jan 28, 2024

alltheseas commented Mar 19, 2024

jb55 commented Mar 20, 2024 via email

jb55 commented May 6, 2024

Mute note with presence of keyword (1,000,000 sats bounty) #856

Mute note with presence of keyword (1,000,000 sats bounty) #856

Comments

alltheseas commented Apr 2, 2023 • edited by jb55

Tracking issues

Bounty

User Story

Acceptance Criteria

alltheseas commented Aug 1, 2023

alltheseas commented Nov 17, 2023

fishcharlie commented Jan 7, 2024

fishcharlie commented Jan 10, 2024

alltheseas commented Jan 10, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 11, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 11, 2024

karnagebitcoin commented Jan 11, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 11, 2024

alltheseas commented Jan 11, 2024

jb55 commented Jan 11, 2024 via email

fishcharlie commented Jan 14, 2024

fishcharlie commented Jan 23, 2024

alltheseas commented Jan 24, 2024

fishcharlie commented Jan 24, 2024

jb55 commented Jan 24, 2024 via email

alltheseas commented Jan 24, 2024

jb55 commented Jan 28, 2024

karnagebitcoin commented Jan 28, 2024

alltheseas commented Mar 19, 2024

jb55 commented Mar 20, 2024 via email

jb55 commented May 6, 2024

alltheseas commented Apr 2, 2023 •

edited by jb55