From f52b0c39dcc549bd13dd40617738e341790d55cf Mon Sep 17 00:00:00 2001 From: PC-Admin Date: Fri, 11 Aug 2023 04:41:11 +0800 Subject: [PATCH] update technical again --- README.md | 4 ++-- technical_spec.md | 12 ++++++------ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index ec4a32f..e5a3aca 100644 --- a/README.md +++ b/README.md @@ -18,12 +18,12 @@ The goal of this tool is to simply block this content as efficiently as possible Easy, setup for homeserver owners via Synapse Module Private, hashing is used to prevent redlight clients from sharing room_ids with redlight servers Decentralised, many people can run redlight servers with their own blocking policies, redlight clients are free to pick a provider - Safe, access restrictions and ratelimiting are used to guard the content of rdlist + Safe, access restrictions and ratelimiting are used to guard the content of Redlight list ## How it Works -"Redlight servers" will be trusted homeservers that are modified, they'll cache rdlist in memory while providing an API interface to "Redlight clients". Redlight servers will pick their own "content tags" that they are filtering, which by extension will allow clients to pick a level of filtering that suits them. +"Redlight servers" will be trusted homeservers that are modified, they'll cache Redlight list in memory while providing an API interface to "Redlight clients". Redlight servers will pick their own "content tags" that they are filtering, which by extension will allow clients to pick a level of filtering that suits them. Redlight clients will be untrusted homeservers that are whitelisted by their desired Redlight server. When a user on a client homeserver attempts to join a room, the hash of the room_id will be sent to the redlight server, which will confirm or deny if the room is abusive, the client then denies the user entry to that room if it is flagged. diff --git a/technical_spec.md b/technical_spec.md index 2b394fe..e6ca57c 100644 --- a/technical_spec.md +++ b/technical_spec.md @@ -10,7 +10,7 @@ Redlight List - A comprehensive list of abusive rooms on the Matrix network, abu Tags - Content tags that describe the type of abusive material found in a room, for example 'csam', 'lolicon' or 'terrorism'. -Redlight Server - Will be trusted homeservers that are modified, they'll cache rdlist in memory while providing an API interface to "Redlight clients". Redlight servers will pick their own "content tags" that they are filtering, which by extension will allow clients to pick a level of filtering that suits them. +Redlight Server - Will be trusted homeservers that are modified, they'll cache the Redlight list in memory while providing an API interface to "Redlight clients". Redlight servers will pick their own "content tags" that they are filtering, which by extension will allow clients to pick a level of filtering that suits them. Redlight Client - Will be untrusted homeservers that are whitelisted by their desired Redlight server. When a user on a client homeserver attempts to join a room, the hash of the room_id will be sent to the redlight server, which will confirm or deny if the room is abusive, the client then denies the user entry to that room if it is flagged. @@ -39,10 +39,10 @@ This creates a chain of trust where each party using this system must be account The following methods will be used to secure the redlight list: - Avoid writing the redlight list to disk, redlight servers will simply pull the latest copy and store it in memory only. - Whitelisting clients, redlight servers will only serve approved clients. - Ratelimiting the amount of requests, if a client is requesting too many rooms in a specified timeframe their access will be automatically cut-off, forcing them to ask their redlight server to re-enable them. - Ratelimiting the amount of hits, if a client is finding too many abusive rooms in a specified timeframe their access will be automatically cut-off, forcing them to ask their redlight server to re-enable them. +- Avoid writing the redlight list to disk, redlight servers will simply pull the latest copy and store it in memory only. +- Whitelisting clients, redlight servers will only serve approved clients. +- Ratelimiting the amount of requests, if a client is requesting too many rooms in a specified timeframe their access will be automatically cut-off, forcing them to ask their redlight server to re-enable them. +- Ratelimiting the amount of hits, if a client is finding too many abusive rooms in a specified timeframe their access will be automatically cut-off, forcing them to ask their redlight server to re-enable them. # Other Design Goals @@ -62,7 +62,7 @@ All documented endpoints require a bearer token supplied in the `Authorization` ### **PUT** `/_matrix/loj/v1/abuse_lookup` -The `abuse_lookup` endpoint returns if the supplied `room_id` is reported to contain a filtered tag in rdlist. The endpoint will +The `abuse_lookup` endpoint returns if the supplied `room_id` is reported to contain a filtered tag in Redlight List. The endpoint will return either `200 OK` to signify a match or `204 No Content` to signify no match. - `room_id_hash:` String. A valid Room ID that has been hashed twice with sha256