Before we started internalizing the jargon from across the pond, we Italians had a habit of simply calling someone a “testa di cazzo,” roughly “dickhead.” It was neutral and inclusive: it could apply to anyone. We didn't need words like fascist, racist, homophobe, antivaxxer, Russian troll, or whatever else is trendy. Someone could simply be a dickhead. Nothing less, nothing more.

True, though I think initially the words built on a genuine observed diversity or lack thereof, for gender choice. Where the "techbro" refered to a stereotypical tech solutionist, Silicon Valley mindset. Then extended to FOSSbro to refer similar mindset in different context.

But today the words are deliberately used, in online fights, in the way you say.

In the past I suggested using alternatives for similar often used gendered terminology, just because a simple rename would lead to a friendlier online environment. Like rename "reply guy" to "reply sigh", and "mansplaining" to "oversplaining".

These days (I hate to say “these days”, but I need to use it now), it seems to be fashionable to add “bro” to every group considered “harmful.” It often takes a particular demographic stereotype, usually white, straight men, who show a strong passion for a particular interest, and turns them into a caricature onto which a whole set of negative traits can be projected.

It is not a favorite term of mine too. I usually do not use it. But it is a term that is being used. Guess its explanation is similar to techbro "I can create all the tech I want", and not dealing with / caring for externalities.

This "fossbro" term really bothers me for some reason. What does that mean?

Is that somebody who shares most of, if not all of your values, and provides volunteer labour to give you platforms to express those values, but then makes something that doesn't initially seem like something you'd want to use so now you hate them and encourage everybody else to hate them too?

Because that sure is what it sounds like. Please correct me.

But in the cases I'm aware of where it did blow up, they the either said something that made it clear that they had intentionally not designing for informed, affirmative consent ... or made an intentional choice to ignore (or pushed back on) the initial feedback.

These repeated firestorms really are an unfortunate pattern but as I've said for quite a while it's going to keep happening until fedi influencers with big megaphones change their behavior.

• start repeatedly emphasizing that consent and resistance to surveillance capitalism are very important norms here.

• share and model best practices for how to avoid unintentionally violating norms -- including asking before releasing something (because it's not always obvious what will set off a firestorm) and listening to the feedback rather than dismissing it

It's frustrating because it's been over two years since I wrote https://thenexusofprivacy.net/consent-for-fediverse-developers/ and @deadsuperhero did a remix of it on We Distribute at https://wedistribute.org/2024/07/fediverse-privacy-and-consent/ In fact I think you might have even been at a #FediForum session (probably in 2024) where we discussed this! And yet, there really doesn't seem to be much interest from high-profile developers in getting the word out about this.

@evan

Eight tips about consent for fediverse developers

An opportunity? A minefield? Both!

The Nexus Of Privacy (thenexusofprivacy.net)

So in terms of respecting people's boundaries for their posts, the issues are more like email then they are like web publishing.

When I send this post to bsd.cafe, can that server forward it? Should it? If I don't want that to happen how can I prevent it?

But there's also a bit like blogging: if I want my posts to be single-server so you have to visit my site to see them, is it even possible? But then how would multi-party conversations like this one work?

But if you're saving it a way that's not for your own private personal use but as part of offering access to others, you need to be following the protocol for deletion and privacy. And you can't be making derivative works that aren't fair use.

The API part comes in in situations like this one, where I'm replying to a reply. That wouldn't normally be copied all over, so some servers will lose continuity, perhaps receiving my reply to your reply without your reply.

So to help fix that ActivityPub servers request posts from one another to do backfill using the API.

I guess I'm confused by the notion of slurping.

Mostly when you create a post in ActivityPub it is pushed to other servers or services where you have at least one follower. So it's like email: your content gets distributed all over the Fediverse, by design.

* I'm glad you didn't call it scraping, because that would be a silly thing to do with a public API available.

I feel the hidden question of the #poll is: Given the #technology base exists, can you just code against it at will? I.e. the tech #ethics question is asked. Where on one end of the spectrum we find the techbro / fossbro, and on the other end of the spectrum we are still learning what we should have there as an alternative to make a social web be social and keep it that way. As "social web" technology by itself offers zero guarantee of that.

#SX #SocialWeb #ActivityPub

FWIW identi.ca launched in 2008.

That's very Mastodon-centric.

When I think of new things on the Fediverse my first thought is of something like the 3D print library Manifold, or of the federated review tool for OpenStreetMap that somebody needs to build.

Respectable Mastodon instances do not do that. (The flagship tried and got such backlash they backed down.) This means there is no legal basis for doing *anything* with other people's posts. It's all potentially copyright infringement, relying on the author's intent and goodwill not to take action. But if you are doing stuff that clearly violates the author's intent and consent, you don't have any legal defense for that.

There is no explicit or implicit license to do anything with anyone's posts except display them temporarily, honoring any future block/deletion/etc. events, to users who the protcol indicates are allowed to see them.