distributed moderator #823
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-08-21#823
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I heard that for public channels there is thoughts to centralize the moderators for each channels. This is a problem in that it increases your legal liability.
There are other methods to consider instead:
As you can notice, this does not require any centralized moderator. This is more of a federated approach.
First of all, thank you for your suggestions. I will review them later.
That "there are thoughts to centralize the moderators for each channel" is at best a misunderstanding and at worst an attempt so seed discord among the PyBitmessage users/developers. I oppose the idea of centralised anything, including grabbing too much power myself.
Due to increased amount of spam in public channels, a while ago I started thinking about giving the users more choices in filtering material they don't want to see, and I asked for user input on this. If people are unable to filter what comes through the channel, then there cannot be such a thing as a channel topic, because a subscriber must read everything anyone posts there.
My conclusion is that more research needs to be done. Yesterday I added blacklisting to the context menu so that people have it easier to add entries to the blacklist directly from the spam message, see
c09981bd42
. Previously, adding a sender of an existing message into the blacklist was a usability nightmare. I couldn't even figure out how to do it myself, now it's one click. This is the level of filtering I consider sufficient for the near future and don't intend to do anything else about it anytime soon. Only one additional thing comes to my mind, the default label for the blacklisted entry could be improved.If I ever revisit this issue, I will involve a broader community of experts and it will be a long term project.
Nothing wrong with trying to grab power and is a successful strategy in the short term, but it does artificially cripple the long term viability of a technology. Multiple examples include the crippling of MiniDisk by Sony (Minidisk would be nice on the PC, but it came too late before the USB thumb drive took over), and when certain providers of fidonet started charging money (which lead to the adoption of the more free and open standard worldwideweb protocol taking over, if the interview with the creator of the internet is correct)
But anyway I digress.
Is the bitmessage sent as a simple "string of text"? If so, have you considered actually structuring it somewhat so that its easier to extend with extra metadata? E.g. using json or msgpack ? (So you can add extra fields like "previous message replies")
The current approach of blocking sender is okay in the short term. This would need to be revisited eventually thought as spammers learn to rapidly change address (Is there a higher proof of work cost to joining the network the first time with a new address?).
Btw, do you mind if I make a new issue about the chan interface? It's quite clunky.
Currently, a message only contains a subject and a body. I believe there are tickets open to make it more complex, but it's not on my radar at the moment.
If you have issues about the new interface, please put them in https://github.com/mailchuck/PyBitmessage/issues, at least until that's where I primarily develop.
Not a problem. Both topic added. Cheers