Convener: Jon Pincus (@jdp23@blahaj.zone)

Participants who chose to record their names here:

• Laurens Hof (@fediversereport@mastodon.social)
• Ryan Barrett (@snarfed.org@snarfed.org)
• Jesse Baer (@misc@mastodon.social)
• Scott M. Stolz (@scott@authorship.studio)

Available Resource:

Scott M. Stolz - I didn’t make this session, but Hubzilla has implemented a lot of additional security & privacy & safety features and I am available to talk to anyone who wants to discuss other options and implementations.

Bullet point summary for debrief

• how can tooling improve, if there are dozens of consent decisions how to do it without overwhelming people? Too many questions up front is a barrier, burying it in a zillion differen settings is challenging.
• different expectations, some instances are going to have broad federation, others aren’t … how do people know? Different defaults for different instances, but also need to convey this to potential users . A first step is just putting it on the about page, also want to include it in onboarding.
• informed consent requires information, infrastructure like FIRES can be helpful here but also need to incorporate into tools https://privacy.thenexus.today/fediseer-fires-and-the-bad-space/
• the usual two camps: instances as communities vs. instances as service providers. and, lack of portability between instances makes this all a lot harder.

Detailed notes

First step: servers should just publish what they’re doing, machine readable, right now it’s very hard. Privacy policies are the same, but one one system

A proposed project for a different way of doing federation management in Pixelfed: more like a firewall, instead of “i allow this” or “block this”. Open federation as an idea is fundamentally flawed, expecting communication from everybody by default ignores that there’s a lot of horrific content out there. Allowlist works but Mastodon doesn’t let it work with blocklist, get beyodn duality, what you want is something where it’s more symmetric - allow / deny / filter.

How does this differ from the “limit” option? Limit does multiple different filters: remove content from public timelines, requires follower requests, a few others.

Two things:

• ability for people to have tightly-controlled federation and commuity, everything set to opt in
• people who are openly social with everybody, they want to opt out

(https://dbzer0.com/blog/can-we-improve-the-fediverse-allow-list-model/ also has ideas along these lines)

Search and discovery is a great example. For people coming in thinking it’s like Twitter, why do I have to opt in? Makes sense for people who are on the fediverse. Thinking of two buckets, things we can do right now and things that are important but will take longer (replies). What if we said there are two kinds of instances, one meant to be more private one meant to be more public. Basically the defaults are different, opt-out vs. opt-in.

Masto 4.3 will ask this during user onboarding. For “do I want to federate with X”, as well as instance-level federation, could also have an advisory . If you’ve blocked Threads and soembody boosts your post does it go to Threads? Can you prevent your profile go to Threads? AP doesn’t have privacy at the protocol level, everything needs to get built on top.

Default settings resonates. What are all the settings people need to consent to? People know about Bluesky, but there’s a much longer list of not clearly obvious behavior that folks are surprised by. The “informed” part of “informed consent”, there’s so much information that it’s not realistic for everybody to process, need to delegate some choices to admin. The threads demo of yesterday showed like 3 popups before you federate. i think thats good, but also illustrate how much info you need to give before people can have a proper choice. There’s a tough balance to strike here because the more user choice you put in front of people the more potential you have to create confusion. Even just choosing a server during onboarding I think created a lot of friction and caused people to say “mastodon is too hard”

Three parallel tracks:

• tools, need more switches for admins and users
• a need across applications, how does a user or server admin make the decision on which platform to implement, how to assess the aspects – need a meta-data curation for admins and users. something like fedidb that goes deeper, connect with info on what the various software offers
• “wetware”: improved education for users and admins.

Tech’s manipulated people to expect things that aren’t ineherent, but just have been embedded by Facebook et al. Need to highlght fediverse offers more ownership, also requires looking at it differently.

There’s a difference in perspective, some view instances as communities, others as service providers. Very impressed by Threads demo making opt in to federation explicit. With Bridgy Fed people were saying “I only signed up for Mastodon” or “I only sign up for ActivityPub”, but there are already a lot of bridges. We have to be realistic, if people are signing up for a public network then they need to know that, there needs to be a reeducation of what the Open Social Web is, looking at AT Proto and Nostr like they’re something different but AP is equally public. Needs to be guidance, Threads user-level opt in to federation, right now you come on in and then we make the decisions afterwards – dangerous place to be, especially for marginalized folks. If this is your concern, then maybe cordon off your network,

Complementary ideas:

• opt-in or consent-based federation, we don’t yet have enough servers and projects
• decoupling moderation work from individual instances - FIRES, Bluesky labeling

From chat: “i’m just gonna keep banging this drum: i think a huge part of the solution to these dilemmas is to make it vastly easier to switch instances, to reduce the stakes of the choice, and make it possible for people who aren’t ready to treat their posts as completely ephemeral to experiment, or “date around”. data portability is one way to do that, but a far easier lift is to make it so that we don’t consider someone’s “archives” to live in the same place as their real time interactions. that goes beyond portability, which implies that you only post in one place at one time. but the fact is many people post to multiple instances and networks, and I expect that will only become more so.”

Bridgy Fed has to build their own opt-in, what’s a more scalable approach? Having to dig ten levels into settings isn’t. A bunch of choices (that you may not yet understand) up front during onboarding isn’t either. Maybe this is similar to Mike’s point about configuratbility

Having to make a lot of decisions up front is a barrier to signup, the easier it is the faster things will grow – good lesson from Bluesky. We’ll never grow into a bigger network if people can’t find each other. Othewrise innovation will just be stunted and innovating around us. With flipboard.social, setting the defaults to on – you’ll be defaulted in to search and discovery, we’ll be clear that we’re going to federate with good networks (including Threads, which we assume is a good network with bad actors). Labeling server somehow “we’re a default public server”, not sure the exact language, Something about “disoverable”? Want to make it clear it’s the same way it works on flipboard.

it’s all going to come down to how you communicate with your users. You’ll need something in onboarding flow, make it explict – if not they’ll assume it’s regular Mastodon software. Doesn’t need to be overly complicated, think of it like going into a subreddit or a Discord server. People coming from big social don’t have these expectations that Mastodon folks do.

How hard would it be to pull out the admin choices that hae been made, put it on the “about” page?

We have to get out of this mindset of being Mastodon-centric. People who want communities should be able to have them but that shouldn’t be the main focus.

i think it’s good to empower instances as communities as long as we make it easier to switch.

At the end of the day, an instance is going to say “these are our rules and community guidelines”, somebody’s going to have to enforce them.

It does seem as though “Community Instance” is a very specific kind of instance and by definition the defaults and federation choices would be made differently than a “Discoverable Instance”

There’s an assumption that people are coming from Big Social and that’s the place for growth. There are many more people who don’t use platforms than who do use them. It’s limiting to think of how do we slice up the Twitter pie across different platforms as opposed to what about people who aren’t on Twitter, I think a good part of it is tied to notions about consent. On the other hand there are billions of users of these other platforms, people are more privacy-concious than they were in the past, but connectivity is king.

Unnamed: there are a lot of tools for privacy, there’s one place which has to be public - I can see the profile so I can send him a request. We’ve mixed the public part with private information, some platforms are taking a two-tier approach (if you’re unauthetnitcated jsut have the base information).