Figure I should post this here as well.
-
@deadsuperhero @evan So, at risk of splitting the solomonic baby, I will say as someone who's worked on a lot of open-source governance and legal issues that patents and licensing are two totally orthogonal enclosure vectors, and honestly the biggest threat to BS later merging with other efforts isn't BS LLC but A.) a vulture fund buying it to strip mine it after the company dies, or B.) a patent *by a loadbearing service provider in the space* over which BS has no control but can't afford
-
@deadsuperhero @evan to stop using years from now (I'm particularly worried about this in the context of composable moderation, which @mmasnick rightly points out as a key innovation that might find its way onto other protocols over time... by which time patent-holding AI SPs might have a lock on the market). Patent pledges are a historic remedy/downpayment against that vector, which Evan is right to point out is perhaps the most serious here, and Bryan is right to say it's early to make one!
-
@deadsuperhero @evan @mmasnick There's no right answers here, it's all tradeoffs and risks. I personally would welcome and support a patent pledge, and would advise if they want free (not-really-professional) advice on the matter for whatever strange reason, but I also understand if it feels like overkill or an expensive pre-commitment to make at this exact point in the evolution of their company. We shouldn't dismiss this as an academic concern, tho-- it's a real concern in FOSSprotocolherstory
-
@deadsuperhero @evan @mmasnick > I don’t want to think of my 15 years in the space as a waste,
Sidenote, Sean, please don't talk like that, you are a saint and your 15 years have made a measurable, recognized, valuable difference no matter who you beef with "on social media." Even if you some day block me for some stupid shit i post on here, promise me you won't belittle your important work or ragequit. you're prolly just a touch emotionally overinvested
-
-
@deadsuperhero it's a protocol created, implemented and controlled by a single company, which hasn't been through an open standards process.
-
@deadsuperhero thanks for the kind words. I put in the time on ActivityPub because I want us to have a great Social Web. I believe that the Social Web will be healthier and more resilient if it's based on open standards. This how most Internet protocols work.
-
@evan @deadsuperhero an open standards process doesn't necessarily mean we reach a good standard, it just means we reach a standard that satisfies enough people working on it.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@deadsuperhero that message really gets under your skin; I don't know why. You keep saying that it is alienating people; I have not seen that happen. I've been able to make this case to implementers pretty well. I think people find it a lot simpler to have one protocol to implement that comes from an organization they trust.
-
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/
