Oddbean

One of the most difficult decisions a Nostr client faces is whether to fix an incorrect or non-compliant post from another client or simply not display it. If you fix it, the original client may never correct their mistake because "hey... it works!" — why would they? On the other hand, if you don’t, your users miss the intended content, and the author’s message is either lost or less impactful. Fixing it on the reader's side adds complexity across Nostr, as every client would then need to code a way to handle the same issue. And if you don’t fix it, users flood us with complaints about a "bug" in Amethyst, which means there is a perception that Amethyst is buggy, even though it’s not our problem. If we fix it, other devs complain we are too permissive and "breaking" Nostr. If we don't, our users give us bad reviews. There is no right or wrong answer. There is only pain.

The way to solve this, is to fix the messages you approve of. This will ensure the content (which is the important thing here) spreads. Your purpose as a relay is to censor content you think is garbage and spread content that you think should spread. The protocol is “normative” and not consenus; i.e. it is of less importance. (This is a fundamental principle of these kinds of tech. see for ref: https://github.com/baumbit/treebit )

It's just today's issue. But every week is something different, from nip04-nip44 stuff to markdown, to markers, to reactions, to communities stuff, etc. It's usually a minor issue in the grand scheme of things, but it's always there.

I think this is far simpler: don't support grossly broken implementations or the surface area for the protocol will be infinite. I would much rather use a client that either ignores bad events or even better displays them with a nice warning saying "person X published a horrible event, click here to tell them to complain about their broken client" -- Ideally it would check if there's a `client` tag with a NIP-89 and p-tag the author of the client.

well, assuming the client is has client tagging and the user enables it, not many of them do that yet, identifying the source of a broken event can be a bit of a sherlock holmes type of job but making a note that alerts the user their client is buggy i think that's ok... building a client fingerprinter is kinda haha yeah nope

then maybe put it to a relay that keeps track of compliance fails by event id at least then we'd have a resource to identify the error and how it is malformed would then just be a typical telemetry option you'd want to nag the user one time for "please help us make the client better" "*sends data to developer relays to improve interoperability of nostr clients"

For relays, there is an easy answer: compliance testing apps. Like the check your DNS, or website for SEO applications. I think nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40 started one.

If you weren't talking about nostr, if you were talking about any other common-protocol-based network, would you think having one independent client act as error-correction for other clients is a reasonable strategy? I don't think so. It's not the job of one client to mitigate the incompetence of another.

this is a drawback of handling everything client-side and having server that is only a "dumb" relay that doesn't do message specific validation and feedback matrix has a similar problem, though there is sufficient client centralization that one client (element) pretty much decides what is going to be shown and what isn't

in a way i think relays rejecting notes that are non-valid according to the spec with a clear message would make for a better developer (and eventually user) experience, and not be censorship: you can post any content as long as it's correctly formatted, at least things are not accepted then silently hidden however, what it would trade away is flexibility; that relays have knowledge of the message kinds and do checking makes it harder to experiment with new extensions and kinds, and possibly get in the way of "other stuff" uses, i definitely get the point why it was designed like this

Quite the conundrum. The way I see it, it's entirely in your selfish interest as a client dev to be completely permissive, but better for the ecosystem to be compliant. We have seen this with browsers where back when normal people made their own shitty webpages, the browsers would compete to be the most lenient and work with whatever shitty code they saw. The problem is that eventually those wrong practices became common and now there is a whole bunch of pseudo specs that aren't actually part of the HTML/CSS/JS spec. I think this is part of the reason why browser engines are so centralized nowadays with only a few options. Any newcomer has to implement a bunch of non existent conventions that a ton of websites use. Many of these being bugs from IE or NN. By being permissive and working with everything, you might be upholding specs that future client devs will have to support, that won't even be written anywhere. Its literally tech debt that trancends your codebase. I think you personally are one of the top people who need to be strict. Amethyst is such a big client that you genuinely have the power to uphold a spec or create a new one by not doing so. I think developers need personal responsibility and especially if good error messages are provided, they can quickly fix their shitty code if forced to. I know I often don't give a shit and will leave wrong code that works, even if it's not hard to fix.