Re: [Hangout - NYLXS] duplicated messages and NYLXS cross-posting

[Alexandre François Garreau]

Le dimanche 16 février 2020, 12:20:07 CET Daniel Pocock a écrit :
> On 16/02/2020 09:43, Alfred M. Szmidt wrote:
> >    Can there be a more efficient way to achieve this?
> > 
> > Since the GNU project isn't in control of the ghost list, we can't do
> > much to address that. :-( Do you have any suggestions on how to tackle
> > this?
> 
> The first thing is transparency.  It is useful to document factually,
> not politically, what has actually happened.  E.g. foo was censored, foo
> forked the list, how many people have copies of subscriber data,
> unsubscribe links for each list.  This can be written without taking
> sides or blaming anybody.  Most users can decide for themselves how
> they want to proceed.

+1

Though some will be lazy, tided anyway, and unsubscribe anyway :/

Anyway, this is illegal and bad behavior (subscribing people to something 
(especially something controlled by a different person) without their 
consent).

> Users who control their own mail servers probably have tactical
> solutions they can use, e.g. /etc/postfix/access

Overkill, it’s not made for that, you’d better use client-side stuff, or 
antispam tools.

> Mail filters can also be used.  For example, telling the filter to match
> on certain things in the Received headers.

The canonical way is to use list-id.  The hangout list conforms to that, 
so that can be used to filter/separate both lists.

But yeah “received” allows to use information from your own webserver and 
be sure it works even if other mailservers and headers lie.  But this is 
not the case, fortunately.

> - what is the best way to build an electronic communications platform
> that is de-centralized, without gatekeepers/censors/moderators but also
> not susceptible to abuse?

Client-side spamfilter, willingly shared blacklists and bayesian antiwords 
list.  But willingly sharing blacklist is tedious.  It ought to be 
automated.  So I’d recommand something recursive and indirect, like liquid 
democracy: a WoT of blacklists, ponderated by social distance to you (how 
many bonds).  But that’s complex to implement.  And, to be decentralized, 
has to be clientside.

Or at least mail-server side but I find that pretty bad as it suffers from 
issues of *federation* [1] and emprison users into the will of their 
providers (providers they might not be willing to change, to keep some 
technology, service quality, or simply internet address (domain name)), 
and it is as easy to implement client-side than server-side (except if 
server-side, the work is to be done by admins, so you’re back with the 
initial problem, plus you need compliant server, plus if you want user to 
have a say need a platform for it)

[1] https://secushare.org/federation

But generally “decentralization” and “moderation/antiabuse” go against 
each other.

> - taking a step back even further, can and should free software
> communities operate without discussion lists or any mailing lists?

They do.  With private and member-only lists.  And this is what chief 
GNUisance asked for several time: use the private GNU mailing-lists.  But 
Ludo&al don’t want this.  They want to act in the public light… yet they 
don’t want the disadvantages of it :/ (trolls).  They want the fame and 
reputation of freedom, without its downsides.