Overview

last week we saw multiple INPC posts flagged by the tagr-bot but when we went to look at the logs we could not find evidence of the bot tagging them or anyone else. Instead we found that they had flagged their own account back in May???

Our flagging labels should be clear for all use cases.

Acceptance criteria:

• only posts that are flagged by the bot itself or go through our manual moderation system should be publicly flagged by Tagr-bot
• Self reported and publicly reported posts should follow the following labeling structure:
  [Display name] has reported this note for [topic]
  [Display name has reported [Display name] account for [topic]

Update the API endpoint so users can change their ID.

Acceptance Criteria

• User can change the ID.
• The new ID shows up in search when searching for the user
• The old ID does not show up in search when searching for the user.

We need to make sure people creating IDs can't mess with existing IDs, create inappropriate IDs, use all the IDs - leaving none for anyone else.

• Users should only be able to edit their ID using NIP98
• Restrict ID creation to happen on nos.social so others outside the app are not using it for nefarious purposes.
• Blacklist the following terms from being used as names: https://docs.google.com/document/d/1zEZYFTFNZE75uEA7cR149ab5yO1UbgATrJh33-PB4ZY/edit

• Copy db
• Sync db with negentropy
• Ensure certs are ok
• Point dns

Once a moderator has approved an account report, the approved flag out to Nostr should only contain an npub and not an nevent for Account flags

This will probably mean a javascript worker but some checks would be good before beginning

Some event are reported multiple times. There was a system to avoid duplicates so it's strange, this used to be working fine so we need more investigation

A dedicated worker should pick up results from the OpenAI moderation queue. This worker will then generate and publish new Nostr events that tag content based on the moderation results, adhering to the nip-32 and nip-36 standards.

Acceptance Criteria:

New Nostr events are being successfully generated from moderation results.
The generated events are correctly formatted according to nip-32 and nip-36 standards.

We want to switch the account of the Reportinator to Tagger.
npub - npub12m2t8433p7kmw22t0uzp426xn30lezv3kxcmxvvcrwt2y3hk4ejsvre68j

If you need the nsec, ask Linda

These are the places in the BE this switch needs to happen:

• Connect to cleanstr code
• Connect to reportinator code
• Update links in https://relay.nos.social

I think that it would be a good idea to show flagged events to ease debugging and show how it works. We should take care on how to present this to avoid an ugly wall of disgusting material. I think just linking to an njump would suffice.

Once we serve nos.social through a proxy_pass we can host a well_known url to implement nip05. We could use openresty for this because it should be a simple endpoint inside nginx

Right now we can deploy any change in the function by locally running pnpm run deploy. We should also be able to deploy through a push in the repo as exlained in https://cloud.google.com/functions/docs/deploy

Process the queued events by sending the content to OpenAI for moderation checks. Once results are received, push them to a separate pubsub queue.

Acceptance Criteria:

Content is successfully moderated using OpenAI's service.
Results from OpenAI are queued without delay in a separate queue for subsequent processing.

See this nostr note from this slack convo

Our system will probably have a rate limit bottleneck on the OpenAI endpoint if we happen to be popular. This is partially covered by #14 but we can also prepare a pool of OpenAI keys that we randomly select on function processing.

Set up a pubsub feed mechanism that actively fetches new Nostr posts from Firebase in real-time.

Acceptance Criteria:

Successfully fetching and receiving new Nostr post updates from Firebase.
The system is scalable and handles large influxes of data without significant latency.

Linda to figure out the regs and the product specs for this.

These are the results of trying to publish the moderation events to each of the relays we use in the NDK lib pool ¹:

• wss://relay.damus.io: Works
• wss://relay.protest.net: Works
• wss://nos.lol: Works
• wss://eden.nostr.land: Error: blocked: not on white-list
• wss://relay.snort.social: Error: blocked: no active subscription
• wss://relay.s3x.social: Error: blocked: pubkey not admitted
• wss://rss.nos.social: Error: blocked: event blocked by relay

These issues may be related to using an npub that never used the clients associated with the relays that don't work but we'd need to investigate further

Someone could attack us by making us moderate fake events that make it look like some known npub say something they didn't. We should verify event signatures before mapping an npub with a moderation result

Doesn't even need to read from the queue

Dev should be done in another test account nobody knows about so that we don't litter it before we launch

• Update the encrypted messages in the Reportinator to support encyrption of nprofiles
• Update encrypted messages in iOS to support encryption of nprofiles

Connect NIP05 work to grafana so we can track the following:

• When the API endpoint is not working / crashes
• How many users are creating new IDs
• How many users are updating IDs
• How many users are deleting IDs

In the backend, update the API endpoint to allow users to delete their NPI05 ID.

AC:

• The ID should not be findable in search
• The ID should not be restricted for users creating a new account (??? Do we want a time delay for this ????)

Description:
In our pursuit to improve user experience and maintain a moderated environment on Nostr, we're exploring options to establish a relay tailored to manage content warnings and reporting events. The strfry relay software is one of our primary considerations, but we remain open to other promising solutions.

Objective:

• Evaluate potential relay software, including strfry, for their fit in hosting and managing content warnings and reporting events.
• Implement the chosen relay solution to serve as a centralized hub for accessing or contributing to these specific events on Nostr.

Tasks:

1. Research: Compile a list of reliable relay software solutions in addition to strfry that might fit our requirements.

2. Evaluation: Assess the relay solutions, focusing on:

   • Compatibility with Nostr's infrastructure and event management.
   • Scalability and performance benchmarks.
   • Ease of setup, maintenance, and potential integration points.

3. Decision: Based on evaluations, choose the best relay solution that meets our criteria.

4. Infrastructure Setup: Provision necessary resources (like servers, databases) for the chosen relay.

5. Relay Setup: Install and configure the selected relay software, ensuring it's optimized for our needs.

6. Event Management: Establish systems to efficiently receive, store, and distribute content warning and reporting events.

7. Testing: Conduct robust tests to ensure:

   • Stability under high traffic.
   • Rapid event propagation.
   • Seamless interactions with Nostr clients and nodes.

8. Deployment: Roll out the relay in our production environment.

9. Documentation: Provide detailed documentation about the relay's setup, architecture, and any associated APIs or endpoints for developers or services.

Acceptance Criteria:

• Successful evaluation of relay solutions, leading to a well-informed decision.
• Consistent relay performance, capable of managing extensive concurrent events without disruptions.
• Effective hosting and dissemination of content warnings and reporting events.
• Comprehensive documentation for developers or services interfacing with the relay.

This ticket now suggests strfry as a potential solution but doesn't mandate its use, and it incorporates an evaluation task to ensure the best relay software is selected.

The moderator google cloud function checked signatures for each event to moderate. These are expensive CPU bound operations and @mplorentz discovered that we were incurring in high costs, I assume the signatures were the cause. For the moment I disabled the verification but this is not ideal. One alternative to consider is to host an instance in Google Cloud Engine and there host a Rust server that just does the Schnorr signature work needed. We could test with some feature flag and see if gives better results

Last week I noticed that all of INPC's posts were being flagged by the Tagr Bot and then then yesterday I noticed the same issue happening for https://njump.me/note15tw0pr35wt6umuhgs7ptt2ywtzq42hhdtyh6xjk3fv9550jgt2ysv6p7az - posts.

Steps to reproduce:

1. Follow the tagr-bot and use Nos
2. Follow a test account
3. Log into another app with the test account
4. Post objectionable content to the test account
5. Post 3-5 other bland posts with no objectionable content.
6. Return to your original account and scroll through your feed.
   Issue: all posts by the test account will have a label that the account itself is causing harassment. Instead of flagging the individual post.

See these slack threads for examples:
https://planetary-app.slack.com/archives/C041FUVEHJ6/p1723722558635889

https://planetary-app.slack.com/archives/C041FUVEHJ6/p1723317658852099

This will also be used in the future for nos.social so we can host our nip05s there

FediCheck from IFTAS has a database of labels for Fediverse servers which have been defederated for some reason. These provide a good set of content warnings we can apply to users who come through the mostr.pub gateway from those servers.

Something like: This user is on a fediverse server which is known to contain: spam, harassment, sexual material

That way we can auto label the really bad content from users based on their server… this should really cut down on hate speech and other stuff coming from mostr.

https://github.com/iftas-org/resources/tree/main/FediCheck

In order to impliment this we’ll need to look at users nip05, check that server against the FediCheck list, and create a report from reportinator for that user based on their fediverse server.

Overview
For troubleshooting purposes it would be helpful to know on which client an account or content flag originated.

AC:

• Add the client marker to each content and account flag posted from Nos to say that it came from Nos.

Once a new and unique event is identified, it should be queued in a pubsub system so a worker can process it through OpenAI's moderation service.

Acceptance Criteria:

New and unique events are correctly queued for moderation.
There's minimal delay between identification and queuing of events.

More info in this slack convo

Investigate OOPSpam Anti-Spam API or alternatives.

AC

• Reportinator sends all flagged account IDs + Flag type to slack for manual review.
• The Reportinator server converts the npub into a nice njump me link for slack

If the event that the user want to "send to nos" was previously processed by cleanstr, it will be ignored and it won't let you send it to the slack channel. So I think we are safe to skip if the event was processed AND was flagged. But if it was processed but not flagged in the past, it should be accepted for the manual analysis

For each incoming event from the Firebase feed, validate against our local database/cache to ensure we're not re-processing old events.

Acceptance Criteria:

Events that have been previously processed are identified and ignored.
The checking process is efficient, avoiding undue load on the system.

We need to write down goals/outcomes, risks, and responsible parties for this project.