Figure I should post this here as well.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@deadsuperhero if you think there's a better way to talk about other protocols, which will result in more ActivityPub implementations and users, I'm all ears.
-
@redroom7
People are against it for a number of reasons. Some because Bluesky has VC funding, they didn’t consent to non ActivityPub platforms/servers (hint; they did). If you go to that Githhub link in the thread you can see and reads people’s reactions -
@tchambers @mackuba @markdarb @mmasnick @mike @snarfed.org
Would be useful to have standardised "nutrition information" for decentralised servers. Part of the problem with opt-out/opt-in and other choices is that users aren't even aware there's a choice to be conscious of. Standardised labelling gives consumers a consistent set of accessible reminders of ingredients they might want/need to pay attention to. Same principle could apply to social media.
Check the label
How to use nutritional labels on pre-packed foods to find calorie, fat, saturates, sugars and salt content information.
Food Standards Agency (www.food.gov.uk)
-
<keanu>Whoa</keanu>
You're telling me that this entire federation, all the connections between all the worldwide volunteer sysops, all the users wanting something the capitalists cannot ever touch, the whole thing hinges on the spiritual growth of one @evan ???
Just like how you seem to think that the offputting nature of RMS as a person somehow invalidates the FS movement he created and which the OS movement rides on.
They're right, however offputting the messengers may be.
-
@jpaskaruk @evan No, of course not. It’s just that public figures, especially prominent ones at the center of movements, can have knock-on effects in terms of words and behavior, and the optics from that can have very real effects in terms of whether people want to volunteer their time and effort to be a part of something.
Some of the best movements and projects have been undermined by this. It doesn’t invalidate the movement or the wider effort, but fostering goodwill is a huge part of building community. At a time like this, it’s needed more than ever.
-
The Nexus of Privacyreplied to Tim Chambers on last edited by
Here are a few polls from earlier this year. At the time, quite a few people (although certainly not a majority!) wanted their instance to block bridges to Bluesky even if they were opt-in. https://infosec.exchange/@thenexusofprivacy/112157748382633585
And as for Mike's point
To date, the only community that seemed to get upset by bridges was... this one?
I don't think the community was upset by the concept of bridges. The (very predictable) firestorm was over consent and died down once Ryan decided to make it opt-in. And in a situation where one community values consent, and another community is all-public so consent is assumed, it's not surprising that only one community was upset!
-
@tchambers @mackuba @markdarb @mmasnick @mike @hallenbeck @evan @thenexusofprivacy @jaz @chrismessina @bnewbold
Good conversation everyone! Thanks for the support. I'm all for instances and networks making their own decisions on bridge opt-in vs opt-out too.
There's another angle here though: who should make these kinds of decisions on the tools' side, eg for Bridgy Fed itself? And beyond that, if we want to consider defaulting them more toward the opt-out, "big fedi" direction – pardon the metaphor, thanks Evan! – that starts to shift them away from fun useful side projects and more toward core social web infrastructure.
To do that right, they need real structure, organization, and governance. That's at the core of my discomfort so far with considering opt-out. We definitely could put real, grown-up structure in place around Bridgy Fed to turn it into sustainable infrastructure and support that kind of decision. But we (I) haven't yet.
I need to write this up more thoroughly; I'll do that soon. Thanks again for the thoughts so far.
-
@snarfed.org seems to me that as we inch further along the path to a robust decentralised ecosystem, platform developers need to accept that potential users of their systems have varying needs and desires.
Platforms could take on the role of educating new members at onboarding as part of their platform's core new account workflow.
There is no single correct answer, but here's a three-part decision each platform could implement at onboarding to help move the space forward:
1/
-
"You are creating an account on a platform that can connect to thousands of other platforms and networks. Would you like your account to be connected to:
1. The entire Internet
2. This network or protocol
3. As few people as possible"Each platform can come at this howsoever it makes sense, but if the new account chooses (1), immediately opt the account in to any bridges the platform knowns about, or offer them each as an option to opt in to during onboarding.
2/
-
@snarfed.org I understand there are /today/ bumps in the road that don't make this easy, but it feels like this is the end product, so let's accept and take on the fact that as we build platforms and protocols for people, those people will want to express themselves and participate in different ways, and that's a good thing.
None of these options are either/or, everything we're talking about is simply lacking decision support and some protocol or client enhancements.
3/
-
@snarfed.org Let's build a network that accommodates major publishers, popular bloggers, introspective carpenters, people who want to talk about knitting but not Formula 1, the cautiously exploring 19 year old who wants to play in the sandpit but is fearful of being seen by their parents/peers/church, people who want to speak and practice Catalan...
All of these people deserve a social network that meets THEIR needs. Let's centre on the people and go from there.
4/
-
@snarfed.org platforms and client applications have a duty of care to the people they want using their products. This includes people who have a different lived experience than them.
We seem to continually be wrapped up in finding the "right" solution, when I believe the better path is finding the many solutions and presenting them in a clear, unbiased interface that helps people do whatever it is they want to do.
Open or allow-only federation - both options are good options.
5/
-
@snarfed.org opt-in or opt-out bridges; very blocky servers vs open servers, all good options in the right context.
There is no global town square, and if there is, very few people want to be there.
Let's re-centre on providing meaningful, valuable social interactions that may differ from our own desires and experiences.
I want a human-centred world wide web with a focus on safety and personalisation. It's on the protocol, platform and client devs to help us get there.
-
Tim Chambersreplied to The Nexus of Privacy on last edited by
@thenexusofprivacy @hallenbeck @markdarb @mmasnick
Well, simple point is that both web polls, or fediverse polls that are not randomized samples of the whole population have like three or four sources of bias and don't tell us much.
I'd think by now we can look at data: the share of fediverse population on servers that do block BlueSky bridges versus who do not, I'd think would be the best source to figure out the wide scale fediverse view. Not sure anyone. has tried to see that yet.
-
Melvin Carvalhoreplied to Mike Masnick ✅ on last edited by
@mmasnick interesting article. I do believe in a broader social web, with each system having its own trade offs.
Why not join the w3c social web community group, and make your case. It is open to all, and we welcome a diversity of opinion.
-
The Nexus of Privacyreplied to Tim Chambers on last edited by
@tchambers I certainly agree that fediverse polls are far from scientific and have multiple biases ... and, these polls are from months ago, and didn't have a huge number of responses. Still, they're a data point, and consistent with other qualitative data (some people here have a very strong antipathy to Bluesky) ... but yeah, certainly by no means proof of anything.
The share of fediverse population on instances that don't block Bridgy Fed is useful in that it tells us the percentage of people here who could opt in to Bridgy Fed ... but I'm not sure what it tells us beyond that. Did Eugen consult with a wide variety of people on .before deciding whether or not .social and .online should block Bridgy Fed? hahahaha. So at best it tells us what admins have decide to do ... but also, in a lot of cases not blocking it reflects not having thought about it yet (as opposed to making a decision not to block it) and I'm not sure how that could be separated out.
-
@evan @deadsuperhero One alternative.. talk about how the problems with #ActivityPub will be addressed in a reasonable time frame given it’s not actively maintained and the evolution of it is “closed” (tightly controlled by the W3C). I think this would be more effective for attracting developers than FUD and misinformation about other protocols and attacks on those with more inclusive perspectives. That strategy doesn’t help ActivityPub, in either the short or the long term.
-
@steve @deadsuperhero hey, Steve. Thanks for popping into the conversation.
It's simply untrue that ActivityPub is unmaintained. We handle reports of errors with errata and an editor's draft. The CG published reports on profiles for Webfinger and HTTP Signature this year, and we have task forces for forums, E2EE, data portability, trust and safety, and discovery open now.
We also have the FEP system for building new extensions, and a process for incorporating extensions into the main context.
-
Evan Prodromoureplied to Evan Prodromou on last edited by [email protected]
@steve @deadsuperhero finally, the CG is working to create a charter for a new working group to develop a backwards-compatible, 1.1 revision of the spec. We'll have a discussion about it at tomorrow's meeting, which you should definitely attend!
