Auto-import of deny lists
Technical Discussion
4
Posts
3
Posters
2
Views
-
NodeBB has a very simple allow/deny list capability at present. You paste in a bunch of newline-separated domains, and we block (or optionally, only allow) them all.
On the road to more fine-grained controls, I discovered that IFTAS publishes a Do Not Interact list in an importable CSV format.
As maintenance of these lists is important (adding new entries as well as handling removals), it looks to be increasingly important that I add into NodeBB the functionality to follow these lists automatically and update as necessary.
-
The problem with the CSV format, is that it doesn't tell you what was removed, only the current state of the data, so you'd need to store previous CSV files to detect removals by diffing new versus old.
-
@julian you might want to check out what GoToSocial does on this front -- it seems very well thought out
-
This is not an issue if you are rebuilding the instance wide deny list every time it is updated.
In that case, whenever the list is rebuilt any removed entries will simply not appear in the new list.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
This is not an issue if you are rebuilding the instance wide deny list every time it is updated.
In that case, whenever the list is rebuilt any removed entries will simply not appear in the new list.
-
@julian you might want to check out what GoToSocial does on this front -- it seems very well thought out
-
The problem with the CSV format, is that it doesn't tell you what was removed, only the current state of the data, so you'd need to store previous CSV files to detect removals by diffing new versus old.
-
NodeBB has a very simple allow/deny list capability at present. You paste in a bunch of newline-separated domains, and we block (or optionally, only allow) them all.
On the road to more fine-grained controls, I discovered that IFTAS publishes a Do Not Interact list in an importable CSV format.
As maintenance of these lists is important (adding new entries as well as handling removals), it looks to be increasingly important that I add into NodeBB the functionality to follow these lists automatically and update as necessary.
-
>Would update work better?
On a second thought, Update is better because posts and conversations could be addressed to multiple groups. A common example of this is a post that @-mentions two or more groups.
I think updating a single property (to or audience) is more straightforward than Move with multiple origins and multiple targets.
-
If we're going to be publishing activities regarding resolvable context collections then it may be time to introduce a new object type.
It would be backwards compatible with f228 OrderedCollections... using the new type would signify support for the various activity types perhaps...?
Edit: if this is what you were proposing with client managed collections, then my apologies 😅 the naming threw me off
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g. isClientManaged: true. And they shouldn't be paginated.
I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
-
@julian that might be it, yeah. languages outside of javascript generally don't make a distinction between null and undefined, and even in javascript these are used inconsistently. for example localStorage.getItem will return null for a missing key. practically speaking, the "intentionally" distinction is a distinction without a difference in most processing contexts.
