Replying to Avatar Blake

A limitation today is clients not being easily able to tag a new event with a content-warning. Could be due to App Store approval concerns. I’d start understanding that first.

Personally I think in depth pre-defined tags are the wrong approach. Net nanny and FWs use them, and it’s often inaccurate (e.g. lots of false gambling flags) - it encourages opinionated blacklists. My only exception is what would normally be under NSFL - almost always watching death occur.

I see normal hashtags as being flexible enough if you want some descriptors for searching or knowing what to expect before you un-blur media content. Explicit websites seem to just list tags. And Nostr events can be tagged without hashtags in content.

We are missing an explicit key in the kind0/profile metadata today. A profile image or banned could be explicit - not just their events. I think that’s easy to add - just add content-warning to the kind0 json. An edge case is showing an event before a profile event first loaded - you could see an explicit profile icon, if the event is not tagged (if it is tagged, and profile isn’t known, it could just blur by default).

An obvious issue is also different language. Which to use in events, how to handle typos, and so on.

And as always, it’s best effort as we have no guarantee the publisher will tag or use some pre-defined list. Reporting can be abused for censorship. For open networks I advocate better client filtering tools - rather than protocol level rules.

If you want some explicit content network on Nostr - just submit a NIP with a new kind. And you can spec it however you want. It can be perfected for indexing porn content or whatever you like.

I think anything else pushed into kind 1 is overkill. Kind 1 is for short messages, not a media gallery.

** and to clarify.. “you” wasn’t used to refer to anyone specific.

Reply to this note

Please Login to reply.

Discussion

Agree with this. Is a shame that NIP-69 is taken 😹

Last point as posted to GitHub too with a few extra points.

If you want explicit content - start an explicit only relay. The far majority of relays will be 99% general consumption.

However client apps lack private relay connection lists today. As apps to support them - and start a relay.

There are a few problems with using a different kind.

First, people won't publish on the correct kind and you can't change the kind after it's been published. LOTS of porn will be published as regular notes, and conservative groups will start publishing anti-porn, anti-LGBT messages in the new kind that's meant for porn.

We had this problem with the .xxx TLD - some people called for all porn to be on .xxx domains. It was a bad idea.

At the end of the day ghettos and marginalization are never a good idea.

The kind problem is generic and applies to all notes.

Kind 1 will always sadly be a dumping ground for bots, automating, testing, random content, advertising, etc. Because it’s the easiest and widest audience.

If you want a dating app.. you don’t need kind 1. If you want only fans, you don’t need kind 1 - keep a non-explicit kind 1 account if you like - which is how Twitter is often used today in addition to an adult account elsewhere.

I’m not suggesting a single kind either. It depends on the use case.

Again. Separation at a relay level makes a lot of sense and makes almost all this simple and easy today without changes. Relays are dumb and easy to stand up - you are still censorship resistant with this approach. It’s not banishing the people or content. It’s just centralising the communities.

Another feature you may wish to push for is ability to select which relays to publish to. And multiple accounts in a single app. Both useful for this. This will come anyway.. but it’s valuable for what you want to achieve.