distributed moderator #823

New Issue

2015-11-14T16:02:44+01:00

mofosyne commented

2015-11-14 16:02:44 +01:00

(Migrated from github.com)

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:

Perhaps what if you can subscribe to a group or individual, to which you can listen to their recommendation of post to not display or forward (or both) within bitmessage. (e.g. they send bitmessages of recommendation to approve or revoke or block senders or messages).
Interface could be based on a 3 star rating. You or others that you subscribed to as moderator can vote up or down up to 3 to -3 points. If a user subscribes to multiple moderating teams, these score are aggregated together, with user defined weighting.
Every post should have an optional field to carry a recommendation for a moderator or moderating group's broadcast channel, so that if you find a poster that you can trust... you can instantly subscribe to them to listen to their moderating advice (or a group they recommend).
Oh and instead of simple allow/block judgement, perhaps moderator groups could do other things like: Increase proof of work requirements to forward, view, etc..

As you can notice, this does not require any centralized moderator. This is more of a federated approach.

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: 1. Perhaps what if you can subscribe to a group or individual, to which you can listen to their recommendation of post to not display or forward (or both) within bitmessage. (e.g. they send bitmessages of recommendation to approve or revoke or block senders or messages). 2. Interface could be based on a 3 star rating. You or others that you subscribed to as moderator can vote up or down up to 3 to -3 points. If a user subscribes to multiple moderating teams, these score are aggregated together, with user defined weighting. 3. Every post should have an optional field to carry a recommendation for a moderator or moderating group's broadcast channel, so that if you find a poster that you can trust... you can instantly subscribe to them to listen to their moderating advice (or a group they recommend). 4. Oh and instead of simple allow/block judgement, perhaps moderator groups could do other things like: Increase proof of work requirements to forward, view, etc.. --- As you can notice, this does not require any centralized moderator. This is more of a federated approach.

PeterSurda commented

2015-11-14 16:22:04 +01:00

(Migrated from github.com)

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.

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 https://github.com/mailchuck/PyBitmessage/commit/c09981bd420d3c0233132967235d5e0eb40acb07. 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.

mofosyne commented

2015-11-14 16:33:49 +01:00

(Migrated from github.com)

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.

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.

PeterSurda commented

2015-11-14 16:39:56 +01:00

(Migrated from github.com)

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.

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.

mofosyne commented

2015-11-14 16:58:11 +01:00

(Migrated from github.com)

Not a problem. Both topic added. Cheers

This repo is archived. You cannot comment on issues.