Ok, it's time to gripe a little bit, as I discovered an annoying lack of interoperability between various #Nostr clients that really ought not to be the case:
Mute lists.
Beware, this is a bit of a long one...
When a user mutes an npub, or a word, they don't want it to only be muted in Amethyst, and not muted at all in Primal. They want it to be muted across all Nostr clients they use.
The standard mute list, according to NIP-51 is kind 10000. All users should have exactly one of these, and relays should only keep the most recent version.
Mute lists may contain a few different types of muted content:
1. Muted users/npubs, designated by a "p" tag.
2. Muted hashtags, designated by a "t" tag.
3. Muted words, designated by a "word" tag.
4. Muted threads (such as hellthreads), designated by a "e" tag.
Some clients also encrypt the entries added to the mute list. While not required, it is part of the spec that clients should expect to see within a kind 10000, and I think it should be preferred. A given npub should not be aware that another npub has muted them and unencrypted mute lists are readable by anyone, unless we move to only saving mute lists to relays that can require AUTH to read them.
Yet, I see a wide variety of handling of mute lists by clients.
#Amethyst uses kind 10000 as expected, and encrypts all content saved to the mute list (hooray!). It seems to support muting npubs and words, and has no support for muting hashtags or threads. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, please chime in to correct me if I have misrepresented anything here.
#Coracle uses kind 10000 for muted npubs and also decrypts the muted npubs that were added by Amethyst, so they are also muted on Coracle. However, users muted on Coracle are not encrypted. I imagine this is because Coracle is trying to use mute information for the sake of building web-of-trust scores (mutes by those within your WoT count as -1 in the scoring), and any encrypted mute information cannot be used to calculate those scores. Also, though Coracle supports muted words, it does not seem to see the words I have muted from Amethyst in my kind 10000, and seems to be keeping a separate list, because words I have added in Coracle don't show up on my kind 10000, and are therefore not seen by other clients. nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, can you offer some clarity on how Coracle handles mutes, especially regarding muted words?
#Primal web seems to have an old kind 30000 list with only two npubs listed, while Primal Android didn't show any muted users at all, but adding a muted user added the npub to my kind 10000, which suggests Primal simply doesn't support decrypting the other entries that were added from Amethyst. Also, muting an npub on Primal resulted in all the encrypted entries on my mute list from Amethyst being nuked.
#Nostur did not display any of the above. Not my kind 10000, encrypted entries or not, or the kind 30000 Primal had been using at some time in the past. Adding a "blocked" user in Nostur also did not add them to my kind 10000 and did not add any other list type that I could find on listr.lol either. I am guessing it is using a list kind that isn't recognized or is just storing blocked npubs locally. nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe, can you provide some insight into how Nostur is handling mutes/blocks, and why it doesn't seem to be using kind 10000?
#Damus appears to be using kind 10000, but only shows entries that have not been encrypted. However, when adding a new blocked user, it does not appear that Damus wipes out the encrypted entries in the list. If not supporting encrypted entries within your client, this is the best way to handle them, rather than erasing them when replacing the kind 10000 as Primal did.
#Nostrudel behaves much the same as Damus, using the kind 10000 and only showing entries that have not been encrypted, but also not wiping encrypted entries when adding a new entry.
#Pokey also seems to have trouble respecting mute lists for the sake of muting notifications. This appears to be because Pokey only looks for your mute list on your inbox(read) relays, while users publish their mute list to their outbox(write) relays, and those may not necessarily be the same. However, I wonder if it is also an issue of Pokey indeed being able to find a user's mute list, but not taking encrypted entries into consideration. nostr:npub1v3tgrwwsv7c6xckyhm5dmluc05jxd4yeqhpxew87chn0kua0tjzqc6yvjh, can you confirm whether Pokey is able to mute notifications from npubs that have been encrypted in a users mute list?
Is it possible to get these and other major clients on the same page about how to handle mute lists?
Yesterday, nostr:nprofile1qqsqddupn4l3cl65wggcyehd009g0pwuatsfudh28f90vewx68vrylqug8jsn posted this about what interoperability means on Nostr:
nostr:nevent1qvzqqqqqqypzqp4hsxwh78rl23eprqnxa4au4pu9mn4wp83kagay4an9cmgasvnuqyghwumn8ghj7mn0wd68ytnhd9hx2tcprdmhxue69uhhyetvv9ujuem9w3ekzen9vfhhstnpwpcz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqzq8kmkd9nu88hhs89dzfahs78pn9j73u5wfjxz8y972uzhapj4es66ad6zu
I pointed out that in order for this to be the case, we also need to agree on the format and expected content that will be contained in a specific note kind. From what I can tell, there is little agreement on how mute lists should be handled.
Should they include encrypted entries? If they do, should clients respect the encrypted entries, since the user who created that kind 10000 certainly doesn't want to see notes from the npubs they added to their mute list, encrypted or not? Clients certainly should not nuke encrypted content from the mute list if it is present, right? Or should we drop support for encrypted entries on mute lists altogether, since some clients are relying on mute lists from npubs within a user's WoT to determine what content is likely to be spam?
Users just want to know that when they mute an npub or a word in one client, that it will also be muted in other clients, and that muting in one client won't nuke their mute list in another client.
me and nostr:nprofile1qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcpzemhxue69uhk6mr9dd6juun9v9k8jtnvdakz7qpql5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqsc0mm8qand nostr:nprofile1qydhwumn8ghj7amgv4shgtngv9c8q7t5v9mx2unw9e3k7tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0w35x2en0wfjhxapwdehhxarjxyhxxmmd9uq32amnwvaz7tm5v4ehgtnjv4skc7fwd3hkctcqyqrgnh6cg75dxdmgjtdzjc3d0s8ac8h3jk85h3z8rkgfv64paj5lyensz6c and nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3eryvfwvdhk6tcpzemhxue69uhkyetkduhxummnw3erztnrdakj7qpq0npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qrdgfzw and nostr:nprofile1qyt8wumn8ghj76rfwd6zumn0wd68ytnvv9hxgtcpr9mhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmd9uqsuamnwvaz7tmwdaejumr0dshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyv8wumn8ghj7mnxv33zumn0wdmksetjv5hxxmmd9uq3zamnwvaz7tmwdaehgu3wd3skuep0qqs99d9qw67th0wr5xh05de4s9k0wjvnkxudkgptq8yg83vtulad30gdx66cm are all working in a loose alliance, with increasingly sophisticated tools to coordinate our work and communication, to improve interoperability by fixing the glaring and gaping problems of the current protocol specification scheme that the... rockstar devs, and their in group, and their big funder who is lost in nostalgia for the olden days of early web2 socials (you know who i mean) and funding "open" twitter which is increasingly toxic due to the influence of especiall the notion of "trending feed" which is mostly promulgated by #primal
nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0w35x2en0wfjhxapwdehhxarjxyhxxmmd9uq3vamnwvaz7tmwd9jkctnwdaehgu339e3k7mf0qyv8wumn8ghj77npwpkxzc3wdehhxarjxyhxxmmd9uqzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7ryxvpq also is connected to this group and what we want is to make an archaepelago, not a metropolis, of private, affinity, topic and organisational nodes, islands in the net, eliminating the friction (lowering the cost of transit between the islands) while increasing the privacy and security of these groups from infiltration and propaganda attacks.
when i was just focused on building a relay, i found it very annoying that clients don't respect my choices as a user to restrict the relays i want to access data from
it makes it very difficult to develop a new relay. this fact tells you that nobody who is paying for nostr dev cares about relays. They think, incorrectly, that this problem is solved. it is not. they haven't even considered the scalability issue, or the distributed replication issue, at all, let alone the developer experience.
this problem has only got worse over time, i thought i could maybe use nostrudel with only my defined relays in use.
nope... go try and put only one relay in your app and in/outbox relays of a fresh nsec identity on #nostrudel
and then go look at how many other fucking things the task manager says you are using in the relay tab
no
just no
and that was just as a relay dev
now, as a human being who doesn't want to be assaulted by the endless indoctrination signal of the #primal trending feed silo
on top of this inability to control my actual computer's use of network resources
you guys are assholes, i hate you, and i will have my revenge, by not being part of your dipshit brown nosing bullshit circle jerk.
have fun stayiing unpopular, and not being interesting to technically adept human beings.
one of the expectations people have of social media has to do with a distributed systems property called "consistency"
specifically, it is sometimes described as the "lack of boundaries between groups of people"
several of the projects i have had close dealings with including one i was working on were based on this mistaken perception of how social networks should be, based on the way that most of the popular ones, facebook, x, instagram, have such large userbases that it looks like there is no partitions between them
this is creating a negative feedback loop that is causing users to avoid new experiences that have too small a span of topics and smaller populations where they percieve this as a deficiency in the platform because of the friction of sign-up and sign-in between them and the problem of cross-posting being so difficult and many times platforms actively prevent it working, and the final problem being that you tend to get followers in one place but not in others and there is not really any point to this attempt to bridge the islands in the net
the primary thrust of #nostr is all about creating a single identity that doesn't have the friction between the islands for moving from one place to the next
yet most of the app developers are building on the assumption that they want to get as many people in one bucket as possible, but the problem with buckets is the crab bucket problem where the more embedded you get in one pool the harder it is to get out and see others
this "muh free relays" bullshit also is working against nostr's principal advantages as well
people will eventually figure it out, and it doesn't matter that we have these rushes of refugees arriving, which most of them back out because they don't understand the whole advantage of nostr because mostly they just get thrown at one app that is tied to one set of relays and one little group of people who mostly are following the same old influencoors due to the effects of #primal and #damus clients - clients that are very intensively trying to mimic the old ways and not leveraging the low friction advantages of nostr's independent identity system
people don't learn things easily especially not after being conditioned and brainwashed for decades into a particular setup
nostr is for niche groups and people who want to have the low friction movement between islands in the net
not for people who want access to the most popular things and the largest groups of users
it's the exact opposite, in many ways
nostr:nevent1qvzqqqqqqypzq32tcfm3560rpppaplx0mehpqhlnahzuvuues0hkzppxx0j2j4s6qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcqyrdeg25pd6p0c4gfr2pdc7flty64lgcq6ydm7j7kazwpwfhzr0mm28j8jxr
Showing page 1 of
9 pages
