What is hard to understand about the Feed Our Feeds BS is what Cory Doctorow @pluralistic, who normally is quite outspoken about these tech bro efforts to coopt legitimate social technology, is doing supporting it.
-
Solarbird :flag_cascadia:replied to Mastodon Migration last edited by
@mastodonmigration @joeinwynnewood @pluralistic Stepping in for a second here:
_This is the actual BlueSky theory in action_.
BlueSky is at best semi-decentralised; I do prefer ActivityPub's approach.
But semi- is better than not. And the theory ATProto people are following is that it's more realistic - more _stable_ - to have a smallish number of large-organisation-run Relays that people can choose between than it is to have every instance be a Relay.
If that's your theory, dedicated nonprofits getting Relays up _is_ a way to fight billionaire capture.
Is it going to be effective? I don't know. But it is the theory, being put into practice. If it's going to work at all, this is how.
-
Mastodon Migrationreplied to Solarbird :flag_cascadia: last edited by
@moira @joeinwynnewood @pluralistic
Understand the theory. Don't understand why it falls to an independent publicly funded entity to prove the theory.
We would be at an entirely different point if Bsky had three working relays and a solid story about how all the code was safe in some sort of trusted open source regime. Further, that these Free Our Feeds folks had engineers on board who validated the feasibility of establishing and running the thing.
more...
-
Mastodon Migrationreplied to Mastodon Migration last edited by
@moira @joeinwynnewood @pluralistic
But that's not what is being presented. The technical side of this pitch does not add up. Maybe Bsky can operate with more relays, but it is not at all clear, and it certainly should not be attempted by an outside group until the technology is proven and much more mature.
-
Solarbird :flag_cascadia:replied to Mastodon Migration last edited by
@mastodonmigration @joeinwynnewood @pluralistic Wow hard disagree.
Setting up a nonprofit to be one of the feed providers is _the_ best way to keep it out of billionaire hands, _if_ you're going to work within their theory and their protocol.
The other options are very wealthy individuals (bad), for-profit corporations (bad), or government funding (right now in the US, _also bad_).
BlueSky right now is _pretty likely_ to have interop problems with a second relay. But... (1/2)
-
Solarbird :flag_cascadia:replied to Solarbird :flag_cascadia: last edited by
@mastodonmigration @joeinwynnewood @pluralistic ...having more spec-compliant stacks trying (and often failing) to talk to each other is _literally_ the way that the internet has resolved protocol implementation incompatibilities for decades, from the InterOP days with duelling TCP stacks to SMTP to IMAP to ... well, ActivityPub. To everything not dominated by one (1) vendor.
Now is the _best_ remaining time to be doing this, because the later you go, the more deviations from spec you'll find and the more difficult it'll get - and the harder it'll be to get a less-friendly-talking BlueSky to bother listening to you.
In other words, waiting is _much worse_ if you want a standard to be a _standard_, and not a proprietary API.
(2/2)
-
Mastodon Migrationreplied to Solarbird :flag_cascadia: last edited by
@moira @joeinwynnewood @pluralistic
Hmmm... sorry, but not understanding you. Unless the in house developers can prove multiple relays work in a loaded production environment with their technology, it is very hard to imagine an outside organization doing it.
-
Solarbird :flag_cascadia:replied to Mastodon Migration last edited by
@mastodonmigration @joeinwynnewood @pluralistic The idea that their Relay isn't internally a fleet of coordinated - even mirrored maybe - Relay instances is... untenable. That's just not how server load balancing works. Literally no one would do that at the scale at which they're operating, and more importantly, want to operate, and I'm not even sure anyone even could.
Therefore, we already know it can work _within_ a single stack.
The next step is to build another, separate stack. And if you want that to be independent - _actually_ independent - you want that done by a separate organisation.
Just as was done for every other meaningful internet protocol.
-
Mastodon Migrationreplied to Solarbird :flag_cascadia: last edited by
@moira @joeinwynnewood @pluralistic
Don't think that is how it works or what is meant by another relay, but admittedly not an expert on this stuff. Perhaps check out Chritine's paper on the AT Protocol.
-
Solarbird :flag_cascadia:replied to Mastodon Migration last edited by
@mastodonmigration @joeinwynnewood @pluralistic I'm not saying it's the same thing. But it is the step you take _before_ taking the next step.
There is not one company in the world that is going to go build an entire new separate stack of its own protocol handling backbone solely for compatibility demo. How do I know? _Because I've worked this job_. You go buy _other people's versions_ and test against _them_, because that's the only thing that doesn't completely waste your time!
And right now there _isn't_ another stack, so people are trying to raise money to build one.
(1/2)
-
Solarbird :flag_cascadia:replied to Solarbird :flag_cascadia: last edited by
@mastodonmigration @joeinwynnewood @pluralistic
People _have_ put up mini-second-Relays using the exact BlueSky code base, for experimentation purposes. At a tiny fraction of total traffic, it worked. The only real way to find out if it's going to work at scale, though, is to try it. And it probably won't at first, and then you _fix things_ until it _does_, or you figure out it's not gonna.
Expecting BSky to build a new second Relay stack to "demonstrate" anything before anyone else tries that is just nonsense. They have better things to do.
(2/end)
-
The Nexus of Privacyreplied to Solarbird :flag_cascadia: last edited by
Yeah. People are putting up larger-scale relays as well -- @edavis.dev recently mentioned experimenting with a non-archival relay for < $30/month (not bad at all!). Rudy Fraser has also posted about looking at doing a non-archival Relay for Blacksky. So I agree with your view -- there are llkely to be a few bumps in the road but there don't appear any barriers to solving the technical problem of running an independent whole-network Relay.
What's still an open question is the economic motivations for anybody other than Bluesky to running a whole-network Relay. The Free our Feeds approach of trying to get the community to pay for it as a public good is interesting. From Bluesky's perspective, it's great to have them be an independent organization -- and if the reports they're on track to closing another round of funding are accurate, it's very timely.
Of course Free our Feeds approach of having most of the "custodians" be AI-focused doesn't encourage confidence. Neither does the heavy involvement of Mozilla. So we'll see how it works out in practice.
-
-
@joeinwynnewood @jubei @cellularmoose @mastodonmigration @cwebber
The expensive part is "storing every post ever made on the network and its cryptographic signatures". A selective relay (only collecting posts its users want, as in Mastodon) would cut this by a lot, or it could just keep the last week or so of relayed posts.
But for that to happen someone has to build it. -
@joborg @jubei @cellularmoose @mastodonmigration @cwebber
Re: as in Mastodon
So IOW recreate ActivityPub (AP) in the middle of the rest of the Bluesky stack which seems a bit silly when AP already exists and is quite successfully deployed (as Christine notes someplace in her posts).
-
@joeinwynnewood @jubei @cellularmoose @mastodonmigration @cwebber
If you will, though from a technical perspective ATproto is a better protocol, and more successfully deployed (in terms of user count and resource usage). ATproto already has distributed outboxes (and labellers, blocklists et c. missing here). -
@joeinwynnewood @jubei @cellularmoose @mastodonmigration @cwebber What is needed for a turnkey small server is an inbox implementation (AppView in AT lingo) with a cache.
Implementing this would enforce protocol compliance/interoperability on Bsky and thus restrict their ability to harm their users, as well as enabling independent alternative providers (including "server migration"). -
@joeinwynnewood @jubei @cellularmoose @mastodonmigration @cwebber I'm hopeful for this to happen, since the current Bsky team seems open to this kind of work. Of course, the question is whether that lasts long enough to get that fire escape in place...
-
Mastodon Migrationreplied to Joborg last edited by [email protected]
@joborg @joeinwynnewood @jubei @cellularmoose @cwebber
Don't understand all the technical terms you are spooling out. Experience shows that when someone is saying something is simple to do, but it hasn't been demonstrated yet, then it is good to be wary.
If Bsky really wanted this to happen, they would at least have a multiple relays operational and a convincing story about making the technology public and, lockboxing it. Short of that it is just a 'trust us' play.
more...
-
Mastodon Migrationreplied to Mastodon Migration last edited by [email protected]
@joborg @joeinwynnewood @jubei @cellularmoose @cwebber
Which is kind of crazy because the entire rationale of the foundation is that you can't trust Bsky.
Edit: Let's say that again. The entire basis of Free Our Feeds is that the public needs to invest huge sums of money in a technology because you can't trust the developer of that technology. ️
-
@mastodonmigration @joeinwynnewood @jubei @cellularmoose @cwebber
Not having dug into the details I cannot confidently say that it's easy, but at least AT was planned for multiple implementations, service providers and applications (cf pixelfed et c.).As I understand it Bsky are actively trialling different relays. Their core technology is public and open source (on github) but not adapted to and packaged for small servers yet.
-
@joborg @joeinwynnewood @jubei @cellularmoose @cwebber
Understand this is their pitch, but until there are multiple independent full scale independent nodes, it is still vaporware.