Switched back to @Tusky as my fediverse client (bye fedilab)

@mayel @Tusky I use both, but I prefer Tusky's cleaner UI. What made you switch?

@codewiz @Tusky

It's a political choice. Tusky decided to take a stance against fascism, while @fedilab is not.

@mayel @codewiz @Tusky @fedilab centralization does not suite such an anarchistic structure as a Fediverse. it’s all users’ (and yours too) and instance admins’ responsibility to fight fascism, not only developers’. and if you try to shift your responsibility to developers, it’s a questionable behaviour.

@fuzzylynx @Tusky @codewiz @fedilab

It is the responsibility of *all* of us! We should block them, and definitely not enable them. Everywhere we can.

To paraphrase Churchill: "Even though large [instances] have fallen or may fall into the grip of the odious apparatus of Nazis, we shall not flag or fail. We shall go on to the end. We shall fight in the code, we shall fight on the seas and oceans, we shall fight in the configs, we shall fight with growing confidence and growing strength in the air, we shall defend our federation, whatever the cost may be. We shall fight on the beaches, we shall fight on the app stores, we shall fight in the servers and in the streets, we shall fight in the hills; we shall never surrender."

@mayel but you are trying to blur a border between a tool and a user of that tool. what you propose is literally kinda “let’s oblige baseball bats makers to make bats that do not work in the hands of nazis! let’s oblige gun makers to ban their guns from shooting in the hands of nazis! let’s oblige cell phone makers to mute their phones if they are used by nazis!” first, you try to fight consecuences, but not the cause. and second, you try to use wrong tools to realise right idea.

@Tusky @codewiz @fedilab

@fuzzylynx @fedilab @Tusky @codewiz @mayel TBH if there were a way for a weapon to know it were wielded by a nazi, and makers failed to implement guns nazis couldn't use, that'd be a nuremberg trial right there.
Weapons nazis can't use sound like a good idea.
And, if you *know* someone is using your app to access a gab account, you *know* they're aligned to fascism, so choosing not to prevent them is rendering assistance.

@cathal we can exclude them from communication and therefore socially isolate and ostracise them. and there are already right tools to make it real. it’s server-level and application-level options, that are production-ready. and these tools are enough for that goal. deveopers already done all that they can. they just can’t keep track all domains, that people consider dangerous. it’s just a waste of their time. imagine that gab will buy a hundred of new domains. and what’s next? devs have to maintain actual black lists in their apps? %) it’s real scenario, and it can be avoided by proper communication between instance admins and users.

@mayel @codewiz @Tusky @fedilab

@fuzzylynx @cathal @Tusky @codewiz @fedilab

Apps could implement something akin to adblockers, where users can subscribe to several blocklists curated by the community. And apps (whether client or server) and server admins could preconfigure defaults, just like extensions like uBlock Origin do.
Follow

@mayel I think this is a very good idea, not only on the application level, but also for instances and end users. It would be a much better way than word-of-mouth and public-service-announcement block recommendations.

That idea sounds exactly like mail blacklists (RBLs), which have already existed for some time, so I wonder if that infrastructure could be minimally modified for this purpose.

tools.ietf.org/html/rfc5782

@therealraccoon @mayel

@therealraccoon @mayel

Maybe allow for democratic input into the lists?
(/he says hand-waving wildly...)

@bhaugen @mayel See "curated by the community."
The same thing kind of happens already, but most of it is redundant manual efforts.

@therealraccoon @bhaugen

Yeah, once we have federation working on CommonsPub/MoodleNet we could for example use the existing functionality to enable this, with communities (ActivityPub Group Actors, meaning several users working together) curating lists of links (ActivityPub Collections) to instances or users/actors they suggest blocking. Then users/apps/instances could subscribe to those lists (ActivityPub Follow) in order to keep their copy (which is added to their blacklist) up to date. Future functionality could allow more open collaboration on those lists too (upvote/downvote of entries, submission of suggested additions or amendments, etc)

@mayel @therealraccoon @bhaugen @cwebber

I love being looped in, but I don't see the relevant thread? URL?

@mayel @cwebber @bhaugen @therealraccoon

Thanks.

There's a lot here, but let me say that you can encourage toolmakers to help allow for content filtering based on a number of criteria- spam, hate speech, etc.

As for Software Freedom, we need Freedom 0: "The freedom to run the program as you wish, for any purpose"

We need this requirement to protect many interests. It's well intentioned not to (usually) but we've seen when it's applied, it can be awful, especially to the dis-empowered.

@emacsen @therealraccoon @bhaugen @cwebber

I'm not sure what you meant, but IMO Tusky (as an example) is not violating Freedom 0 because any developer can modify the code as they wish, and redistribute the fork as well. It would be going against the Tusky team's freedoms to expect them to distribute a build that can be used by anybody for any purpose they wish (not to mention technically impossible to create software that contains any feature imaginable!)

Anyway, I looped you in more for the discussion about federated blocklists.

@mayel @emacsen @therealraccoon @bhaugen It's not nonfree if a distributed build blocks an instance. But it's also so trivial to make a build that doesn't that I'm not sure it's doing anything.

It seems like the wrong layer to do a block. Firefox doesn't come with a blacklist of sites that says "we're not going to let you visit these", and I don't think it would be *effective* if it did either... it would even provide a marketing opportunity for "removing" the restriction that could backfire.

@cwebber @mayel @emacsen @therealraccoon @bhaugen They do have a blocklist from Google of spam and malware sites.

Before you ask: while I do distrust Google, the privacy protections on that service are superb. Hash-prefix lookups mean Google doesn't know what sites you visiting via *this* service.

@cwebber @mayel @emacsen @therealraccoon @bhaugen

Actually it does. Firefox has an embedded blocklist of trackers (which is enabled by default on private mode). Different case than Tusky and Gab of course, but it is a block functionality on the application level.

@comzeradd @mayel @emacsen @therealraccoon @bhaugen That functions differently though: it's a warning-list, not a hey-user-i-don't-want-you-to-use-this-list

@cwebber @comzeradd @mayel @emacsen @bhaugen I feel like there's much too much focus on the application level right now, when we really wanted to talk about shared amendable blocklists that could be subscribed to (also) at the admin and user levels.

@mayel @emacsen @therealraccoon @bhaugen @cwebber The point of Free Software is to prevent developers from controlling users. Whenever a developer tries to limit the user, a free software license provides a work around, but it would be better if there was no malicious feature – a feature designed to hurt the user of the software – in the first place.

@mayel @therealraccoon @bhaugen This is a great idea. I like the approach of generic software which most people choose to use in a pro-social (and anti-fascist) way because it's the *best* way to use it.

Sign in to participate in the conversation
Octodon

Octodon is a nice general purpose instance. more