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 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.
