GA Nostr. I wonder what the eventual implications of this are for folks running personal relays like HAVEN.
I mean, I run a pretty clean and heavily moderated set of relays myself… No porn, self-harm content or anything of the sort.
One good thing about Nostr is that nobody has ever tagged me in any such content on Nostr (For those who say I’m unfair to Nostr: this has happened to me on the Fediverse… once… but still, it didn). If I were ever tagged by someone posting that kind of material, they'd be booted from my WoT pronto, and their content would of course be deleted from my relays.
Still, the question remains: do I need to implement any form of age checking right now? And even if not, if the UK government (or any other) decides that personal relays need to enforce age verification, what should we actually do?
Only the owner of the relay can write to the Outbox relay, so that should be fine (I think? Right?). Just don’t post stupid stuff. But what about the Inbox? How do we “age check” a bunch of bots and maybe a couple dozen people, most of whom are using pseudonyms and, let’s be honest, are unlikely to cooperate? Should I just give users a flag to disable the Inbox relay?
I have absolutely no idea what to do, or even whether this affects personal relays at all.
nostr:nevent1qqsd94dtg2tfjev3pfjg2q9h5e9ty7p5ta4yuur3htwgjwjd3lnk9cspzpmhxue69uhkummnw3ezumt0d5hsyg8ayz8w3j8jsduq492j39hysg7vnhrtl4zzqcugj4m3q62qlkf8cypsgqqqqqqst5dtuv
#GM #UKOnlineSafetyAct #haven #relay #personalRelay #ageVerification
In terms of what would hold up in court, I really can't say. I don’t want to sound too relaxed, nor do I want to paint too much of a dystopian picture… so I’ll focus more on the technical feasibility of deanonymising someone.
Yes, DNS is a major one that projects like pkarr, Onion Services, etc., try to address (pkarr is still pretty new, and Tor is no silver bullet). But for personal users, there are a gazillion other layers that can expose them, from software running on their mobile or desktop (starting with keyboard apps, AI tools users have "authorised" to learn from their behaviour, to shady background daemons like Meta was using to the OSes themselves …), them there's your ISP if you're self-hosting, CAs if you are using HTTPS, CDNs, the VPS or Cloud provider provider you're renting hardware from all owning bits and pieces of personal information and metadata that can be pierced together to paint a picture. Then there are all sorts of fingerprinting techniques… and about a gazillion other possible deanonymisation vectors.
Again, I can’t say what would hold up in court, but I’d work with the assumption that, for the vast majority of people exposed to Nostr, the authorities can figure out who’s behind an npub or operating a relay fairly easily.
Agreed. Morals are what emerge beyond fear of repression… Either when you're genuinely beyond repression (which is rare), or when you're fully aware of the consequences and still act according to your beliefs.
I don't think I need to state where I stand morally, or I wouldn’t be maintaining Haven as my most expensive hobby, nor encouraging people to self-host in the first place. If we had 20,000 people self-hosting relays (be it Haven or any other relay software), the picture would look very different compared to just a few hundred. And if Nostr blows up like torrents did back in the day, that would again be a very different scenario.
I strongly believe is that the default path on Nostr will be one of non-compliance (again, assuming there’s even anything to comply with).
Still, my take is that healing happens when, given the choice, people voluntarily choose correctly (which, as you're suggesting, might be doing nothing). I don't believe in imposing compliance, but I also don't believe in imposing non-compliance. That doesn’t mean I can’t hold strong opinions about it, of course.
This is more directed to nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40 than to you, but I’m replying here to avoid breaking the chain (and it touches on what you said anyway).
I was thinking about this tonight and, honestly, my position hasn’t moved much. DHT might be the "end game" (well, there’s no real end game, but you get me), but looking at the current state of Pubky, it feels like anything of the sort is still years away from achieving a Nostr-like multi-client, multi-intent ecosystem. That comparison isn’t entirely fair given how young Pubky is, but on the other hand, it’s not like the bar is set that high when you consider the competition from Big Tech and their unlimited engineering resources.
If we try to force DHT, fancy serialisation, complex contracts, etc. onto Nostr right now, we risk alienating the average pleb dev, someone who can maybe, kinda handle WebSockets and JSON if you give them a JavaScript library and a half decent LLM Agent, but who would seriously struggle with more complex, enterprisey architecture, nevermind R&D sruff. I’m not being dismissive of these devs by the way. I’m not the person who’s going to build the next viral Spotify alternative over Nostr, but they might be.
I'm not saying DHT R&D shouldn’t be pursued. In fact, I’m very bullish on Pubky and Pkarr. You've also announced your own greenfield R&D work, and I’m genuinely looking forward to seeing what comes of it. But if we’re being realistic, even though Nostr is small in the grand scheme of things, it’s already a large enough ecosystem to warrant a slower pace... Adopting new ideas only once they’ve matured and stabilised. I know that’s not what a lot of devs want to hear, but IMO it’s the right thing to do if we want Nostr to grow. We need to prioritise expansion over exploration.
That said, with a bit of imagination, we can keep Nostr working quite well while those newer ideas are being tested. If we move beyond the purist ideal of "one fully decentralised P2P solution that fits all," we’ll see that NIP-05/NIP-65 actually does the job fairly well (even if you, and I admit, even myself, don’t always give it enough credit). We just need to break the problem down a bit. DNS itself needs to be complemented by rDNS which, IMO, is a bit of a dirty workaround... but hey, it works (sorta). WKD works pretty well for PGP alongside traditional keyservers. Clients can and should cache NIP-05, Kind 0, Kind 10002, and other list/set data kinfs. So as long as we have a deterministic way to retrieve this info, I think it’s good enough for now.
The main short-term issue is that Gossip, as it stands, isn’t deterministic when all you know is someone’s npub, and, as Nuh puts it, it’s currently working mostly due to a set of coincidences that will fall apart as people get more serious about running their own relays.
My opinion on this is: is it really such a big deal if, for now, we have a bunch of index relays syncing with each other? Honestly, as long as index relays are lightweight and it’s easy for someone to run one and join the network (i.e. not Bluesky/AT Protocol levels of complexity), I don’t think it’s a problem.
Could it end up like HKP, where most folks rely on just 2 or 3 servers? Absolutely, in fact that’s actually very likely. But this is good enough for now. And once the experimental, fancy, quantum-resistant, DHT-based P2P solution is ready, we can build something like a gateway indexer relay to bridge the legacy world until clients are ready to migrate.
So, the TL;DR: I don’t think there’s anything wrong with playing the tortoise in the tortoise and the hare race of distributed social media protocols. The real issue we face today is that the Outbox model isn’t holding up in a world with thousands of personal relays. That’s the problem we should focus on solving now. Let other protocols run ahead with the fancy R&D stuff; we’ll learn from what they build, and later we can catch up and gradually move the majority of users to the fancier stuff. It might not be as exciting for engineers as working on greenfield projects, but it’s hard honest work, serving actual Nostr users.
Agreed... Client devs, especially mobile client devs, may be low-hanging fruit. And I guess that “My client just provides a WebSocket between the client and the relay” will work about as well as the old “Demonoid is just an indexer and search engine” excuse.
Still, as someone almost strictly on the relay side of things, I don’t think pushing all responsibility to clients with a "I’m just running some JSON backend thing" stance is going to hold up either. At a bare minimum, relay software should offer proper tools to manage Kind 0, Kind 1, and NIP-23 content. And folks running additional things like Blossom, NIP-96, etc., need solid ways to moderate media.
At the moment, Haven has neither. Well... the moderation tools are basically the file system and a database client 😅. I haven’t played with relay.tools myself, but given the scale of some relays running on it, I assume you already have some moderation tooling in place. I think that both client and relay software devs have to work with operators (and you and I are both people playing both roles at the moment).
Lol, got it. To be honest, I don’t have much access to client devs (and for the most part, I don’t even know where they hang out to begin with). I started this thread mostly with relays in mind, since the “Other things” folks seem to know what they’re doing. I really can’t say what they’re discussing at the moment—but I do wonder if there’s a plan.
nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp0g4rts7, nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9emkjmn99urf278z, nostr:nprofile1qqs8lft0t45k92c78n2zfe6ccvqzhpn977cd3h8wnl579zxhw5dvr9qpzamhxue69uhkvun9deejumn0wd68yvfwvdhk6tcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7eeth6c, nostr:nprofile1qqsvvcpmpuwvlmrztkwq3d6nunmhf6hh688jw6fzxyjmtl2d5u5qr8spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqs7amnwvaz7tmwdaehgu3wd4hk6xe6hvp, nostr:nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq3qamnwvaz7tmwdaehgu3wvfskueq5eg09w, nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9uq3wamnwvaz7tmkd96x7u3wdehhxarjxyhxxmmd9ukfdvuv, you’re some of the cool client devs I’ve had the chance to interact with. Some of you even reply to me occasionally 🤣.
Are you planning any changes to your respective clients in terms of moderation and compliance with the whole age verification thing?
Showing page 1 of
1 pages
