Just hard to implement and put code and hours where my mouth is 🤣. But we'll get there :)

I'm encountering some bizarre AI enabled Bots today, lol.

On my side, I was thinking more about personal or small community relays. But honestly, even at scale, it’s either a big team of human reviewers or a mix of that and algorithms à la big tech social mefis (and given the current state of things, I’d much prefer to go back to the army of mods). My take is: give operators the tools and let them decide. Want to whitelist everyone by default? Fine. Want to blacklist everybody but yourself by default? Also fine. Want a moderation queue? Here you go. Want to be notified about new items to review? No problem, just let me know the level of granularity you want for notifications. This is what we can do on the relay development side without imposing our own views.

was experimenting a bit with it. Can't wait, it's the one missing piece to have a Nostr based alternative to GitHub

Think of this from the relay operator’s perspective as well. You care less about immediately releasing someone else's content and more about filtering out bots and weird stuff, but there may be new people writing interesting content worth spreading around. If they do it often enough, you’ll eventually whitelist their npub. But if there’s no grey middle ground, you’re forced to choose between allowing by default (and risking the spread of awful content) or blacklisting by default (and creating a bubble). Another way to look at it is the GitHub-like PR model: send enough helpful PRs and you may eventually gain write privileges my repo. IMO, this is a fair middle ground for moderation. I agree with you that this should be mentioned somewhere to make users aware that their notes might remain in limbo for a while...Maybe via NIP-11. As for making sure operators don’t simply forget about notes, maybe daily reminder emails? That’s what Mastodon offers.

Lol, I somehow missed Freddy Vegeta 🤣

Yeah. That’s where I want to go with Haven as well. Having a nice, private UI where you can say: * This person is trustworthy; let their followers write to my relay. * This person? I don’t know. If three other folks follow them, then let them write to my relay (default). * This other person? I love them, but they follow bots and weird people, so their follows don’t count when deciding if someone can write to my relay. This is all "private" and local. I’m currently running a private fork of Haven with a barebones implementation of this. No UI, just local files with npub / trust-level pairs, and so far it’s sorta working for me. It’s still essentially a dumbed-down version of PGP ownertrust, but (hopefully) something that can be done in a way that’s more intuitive and attractive to normies than the whole PGP “signing key party” stuff.

If I was his instructor his grade would be over 9000!

Hey Greenwood, nice to meet you. You are not an AI Bot are you? (This is coming from someone often accused of being AI, so not an accusation at all, just wondering 🤣). But regardless, for sure, folks are cooking all sorts of things on Nostr. It's even hard to keep up (in the WoT space alone I hear about something new almost every week).

I noticed. Endorsing content you like and people you trust is a powerful tool. Your followers doing this (interacting with your main profile) is the reason your content reaches me, and why we have all sorts of interactions despite not following each other directly. They stop following you, your content stops reaching my feed (and vice-versa unless you are using one of the indirect ways to keep up with me mentioned above). There has to be a way to solve Nostr’s cultural issue of “degrees of separation and endorsement from Jack / Odell / Derek / Lyn / Will, etc.” as a measure visibity without burning down the social graph and scorching the earth behind us. My hypothesis is that we need a culture of more intentional following like what you're advocating for, but with proper ownertrust-style tools. I've asked around and a lot of people want to “follow that one person who produces crappy content we’re all embarrassed by, but we still love them regardless”. So kind 3 is better than nothing but not sufficient for WoT. My main problem is how to bake in that intentionality in a way that’s accessible and fun instead of recreating a dumbed-down version of the PGP Web of Trust experience. It’s definitely an interesting research problem, one I don't have an immediate answer for, unfortunately.

To be fair I think that noStrudel is not in the worst position given that it doesn't rely on app stores, etc. But I assume that sooner or later all layers will have to do something about it. I really can't imagine noStrudel doing face verification or asking for a photo of my ID, but I really wonder what any clients planning to comply will do. I hope that you all just don't block the UK (as you will be having to do the same for several other countries soon)

Agreed. And there are exactly zero clients I know of that actually support all the variations. With rare exceptions, even p-mutes are restricted to either public or private, at least when it comes to writing. (Reading is a bit better; a lot of clients can handle it). NIP-51 really needs a reality check. Kind 10000 and 30007 are just two of many, many things I struggle to find a good reference implementation for. From a relay perspective, you wouldn’t believe how much junk those lists contain, and how much clients spam them. I have some generous rate limits to my relays, but as soon as I open certain clients I know that they will reach rate limits in seconds reading 10000, kind 10002, etc. Even on personal relays 🤣.

You may have created the folder with another user (e.g., root). You can always change the owner of the folder, see: https://linuxize.com/post/linux-chown-command/ If you run the command with sudo, then the root user will own the files and folder. That may or may not be what you want, depending on your goals. From a security perspective, the ideal approach would be to create a separate user specifically for Haven, though that setup can be a bit more technically involved. I'll make sure to document this in the future — thanks!

Makes sense, and agreed. Still… it's a difficult ecosystem, with clients and users doing things in very different ways. For example, some clients encrypt all tags in the user mute list; some people may argue that even publicly muting someone shouldn't influence the social graph; and kind 1984 is what should really count as negative signal. But then again, NIP-56 specifically asks relays not to perform automatic moderation based on reports... But (but after but after but), one could argue that aggregated results based on WoT analysis (where one trusted npub report = one vote) are a bit harder to game. Lots to think about, and no easy answers here. My current take is that people use all these tools in such unique ways that it may be better to keep a private ownertrust list for keys in the relay itself…sort of like how PGP does it. I.e., I'm leaning toward using the followers list to build the trust graph, ignoring all other kinds, and allowing users to privately set how much they trust a given npub. For example: 1. I follow a certain npub but don’t trust it at all because I know it follows bots, ignore it when computing WoT scores. 2. I marginally trust an npub, so I’ll use its follow list for the WoT score. If 3 users follow a npub, I'll trust it as well (default case - What we do in HAVEN right now) 3. I fully trust a key, so I’ll allow all of its followers to write to my relay My dilemma is that a PGP-like WoT is too complex, and I don’t want to build yet another model that only security folks can use. But then again, I’m struggling quite a bit to simplify it. It feels technically correct… just… hard to use.

Makes sense, and agreed. Still… it's a difficult ecosystem, with clients and users doing things in very different ways. For example, some clients encrypt all tags in the user mute list; some people may argue that even publicly muting someone shouldn't influence the social graph; and kind 1984 is what should really count as negative signal. But then again, NIP-56 specifically asks relays not to perform automatic moderation based on reports... But (but after but after but), one could argue that aggregated results based on WoT analysis (where one trusted npub report = one vote) are a bit harder to game. Lots to think about, and no easy answers here. My current take is that people use all these tools in such unique ways that it may be better to keep a private ownertrust list for pubkeys in the relay itself…sort of like how PGP does it. I.e., I'm leaning toward using the followers list to build the trust graph, ignoring all other kinds, and allowing users to privately set how much they trust a given npub. For example: 1. I follow a certain npub but don’t trust it at all because I know it follows bots, ignore it when computing WoT scores. 2. I marginally trust an npub, so I’ll use its follow list for the WoT score. If 3 users follow a npub, I'll trust it as well (default case - What we do in HAVEN right now) 3. I fully trust a key, so I’ll allow all of its followers to write to my relay My dilemma is that a PGP-like WoT is too complex, and I don’t want to build yet another model that only security folks can use. But then again, I’m struggling quite a bit to simplify it. It feels technically correct… just… hard to use.

Mostly kind 10000 (which a surprising number of clients don’t encrypt), but it can also be done with kind 30007, which presumably carries less weight than 10000. I mentioned both because I was wondering if folks might prefer different WoT behaviours, for example, 30007 might be seen as more "neutral" than 10000. You might want to mute someone's Kind 1s but still receive their DMs. No idea if it means anything in terms of "trust".

Alright. Makes sense. I think that moving Haven to Khatru v2 will be a future thing. For the mirroring, redirect and Blossom fixes, is it worth contributing to "v1" GitHub as well? (Arguably everything that I have to do is a "fix", but I'll be breaking some of the current callbacks to add extension parameters).

, side question as I'm still working on some Nak, Khatru, and Njump-related stuff. Are all of those staying on GitHub for now, or do you plan to move any of this to grasp any time soon (say, within the next couple of weeks)?

GM Nostr. Build and fix the software you use. Use the software you build. Geek out with the community. Help where you can. Ignore the noise. Give zero f*s. #gm #devstr #lyfestyle #buildi