Bsky raises $15m from Blockchain Capital, the VC's press release hints at what they're interested in:

jonny (good kind)

13M Users and Growing: Our investment in Bluesky's re-imagined social network

Blockchain Capital invests in Bluesky’s Series A - Bluesky is revolutionizing the social media ecosystem by empowering users to curate their own feeds and take control of their data

(www.blockchaincapital.com)

Bluesky [is] designed to foster a new ecosystem of applications. [...] It is interoperable with existing internet protocols and blockchain-based systems, opening the door for a more connected, less siloed social experience. Since its launch in April 2023, over 100 clients have been built on the AT Protocol, and users have created more than 50,000 custom feeds. And the best part of it all? By building on top of the AT protocol, these developers have access to Bluesky’s 13M users worldwide.

The VC firm sees bsky and their ownership of the relay as being a potentially very lucrative chokepoint, where the users of bluesky are the asset to rent to platform developers who want "access" to them. I've written before how atproto's decentralization is effectively meaningless with the relay system, where it's decentralized in the same sense as google alerts is centralized - sure you can host your own PDS, but it's only useful because the main relay crawls it, and then either bsky or someone else who (inevitably) pays for access can send it back to you.

#bsky #bluesky #atproto #ChokepointCapitalism

Marta

@jonny Can you link your previous writing on the relay, please? I really would like to understand that better.

jonny (good kind)

@teclista here's the post i'm referring to: https://neuromatch.social/@jonny/110552684614320107

some more posts on the mirage of decentralization in atproto, i haven't written an "explainer" about how it works, but their docs are increasingly good on that:

to be clear i am not concerned with decentralization for decentralization's sake, as a technological fetish, but the implications on the social, political, and economic structure of the system - specifically its capacity to be turned into an extractive chokepoint by those that control the center (the relay).

Jon P

yeah to the extent that the Relay is a central point it's certainly an opportunity for a chokepoint -- and Bluesky has many natural advantages for being the network-wide Relay. It's still an open question as to how quickly partial-network Relays evolve but even to the extent they do they complement the whole-network Relay.

From the Investor's perspective, who knows ... it could be as simple as they didn't get into Farcaster so want a decentralized social network play and this is close enough. The lead seed/Series A funder for my 1990s VC-funded static analysis defect detection company was interested because Purify (runtime defect detection) had turned down funding from them, so they said "well we'll just find somebody else!" Some of their other investments are really horrible so I am not sure what their due diligence looks like. From Bluesky's perspective it could well be this was the path of least resistance to raising quickly on favorable terms. Hard to see this working out well long-term but we shall see.

@jonny @teclista

jonny (good kind)

@jdp23 I don't see how partial relays would be possible in atproto. say some catastrophic event happens where people were dead set on splitting off from bsky the corporation. assume it's truly the top priority and nothing else goes until it happens. assume further still this is some unimaginable proportion of the userbase acting in concert - hell, say 25% want to go all at once. best case scenario for making an independent relay.

you create a new relay, migrate data to new PDSes, get that new relay to crawl the PDSes, so far so good. Now what tho? everyone on the new relay is invisible to everyone on the old relay and vice versa. you are back to 0 appviews and 0 feed generators because they all are listening to the main relay. every single appview and feed generator now needs to choose to listen to the new relay. but why would they? you're still responsible as an appview or feed generator for the content you distribute, and you don't know who this new relay is. that's assuming there's no ill will in such a massive split.

so you set up a new basic set of appviews and feed generators. do they also listen to the main relay? do you mirror the old relay in the new relay? do you let the old relay crawl the pdses too? if so, what was the point of the split? now you need to redesign all the existing appviews and feed generators in flight to deduplicate records, which is possible since they're content addressed, but i would doubt they're designed to handle multiple relays because none have existed before now.

what about DIDs? most of the existing infrastructure is designed to just use PLC, which is just a lookup table that bsky also owns. shoot. but we're saved by magic here, because remember there is no acrimony in this enormous network redefining split! So say bsky the corporation is kind enough to keep letting people register DIDs with PLC. we didn't quite make the clean break we were after, but hey it's only the fundamental ability to exist on the network that we were unable to leave behind, and we'll always be reliant on bsky's goodwill for that until someone makes a DID method that works and then we redesign all the appviews and feed generators again.

So now after all that... we're still invisible to most people on the main relay?! oh right because bsky the corporation also provides the default feeds, and despite the high numbers claimed in the press releases, alternate feeds are actually only sparsely used and as a rule very simple hashtag/account feeds because doing anything else is ridiculously expensive. Bluesky the appview is provided by bluesky the corporation, and that's what's actually fetching and hydrating the feeds for us anyway, so even if the feed generators swap over, we'd still be invisible to everyone still on bsky the app. More magic! bsky the appview chooses to crawl and hydrate our posts. We're pretty far from our initial intention of a clean break, but what choice do we have? Now we're partially viewable, some of the time, on some non-default feeds, and there's no way at all to tell within the interface which those are. All it took was totally redesigning most of the network and an enormous amount of goodwill.

What about labels? What about all the automated content moderation bsky the appview does like scanning images and etc? Who moderates? How? Who's paying for all this anyway? The new relay is bound to be extremely expensive - either it's too small and you don't have the critical mass to make any of the above happen, or it's very large and you run into exactly the same problems of scale that necessitate bsky the corporation to need seed funding and eventually make a revenue model on. Where on fedi people pay for servers and donate to their instance because it's a visible part of their experience with moderators they know and like, now all that labor is diffused among a bunch of anonymous service providers - this is by design! It was supposed to depersonalize the network and make it so everyone is just an interchangeable part that you can shop around between. What keeps people donating to the new PDSes, the new relay, the new appviews, the new feed generators? How would they even know how to do that?Meanwhile the network is continuing to tack on features with some combination of bsky corporation fiat, behind the scenes server magic, and so on, so the best we can hope for is partial compatibility and an always-inferior experience.

And that's just to get to 2 relays. what about 3? Remember how much people complained about how hard it was to find an instance? That's absolutely nothing to the combinatoric complexity of PDS * relay * feed generator * app view. How on earth will anyone know how to follow and talk to their friends? To see your friend's post, if they are not on the main relay, you need to get just the right combination of parameters. Even in this perfect scenario with unlimited resources, attention, goodwill, and organization, we couldn't even manage to make a clean break and still have to be reliant on bsky for basically the entire stack, at least partially.

So maybe some small, closed group could make subnetworks, and that is lovely! i'm glad that tech is out there. There's no such thing as privacy on those networks unless they redesign indigo, but hey it's a start! But that looks nothing like the interoperable paradise that's on the label.

In reality we don't get perfect conditions though, and so we'll get stuck at step one: new relay, zero appviews, zero feed generators, zero visibility, and zero people. Again I don't think alternate relays are possible with atproto -- if they were, then there would be no reason to invest $13 million dollars in bluesky.

#atproto #bsky #bluesky #fediverse

Jon P

I see it somewhat differently. Many apps don't care about most of the data on the broader Bluesky network, so could have their own partial-network Relays as well as AppView. There's already one AppView that doesn't use the Bluesky Relay at all, jus goes directly to PDSs. Or, you could have AppViews that access both closed-subnetwork Relays and (optionally, if they want to plug into Bluesky's chokepointed world) Bluesky's big relay. A PDS, partial-network Relay, and AppView together (and maybe Labelers and Feed Generators) are an instance-equivalent; federations of instance-equivalents can have Relays as well.

I don't think it's inherently any more complex from a user perspective than the Fediverse's situation, where you have to choose an instance and an app and apps only work with specific instances (although I don't also think it's inherently any less complex either).

So maybe some small, closed group could make subnetworks, and that is lovely!

Just as it's lovely on the ActivityPub Fediverse! But when it comes to the full-network view, ActivityPub is implemented today also has a chokepoint: it favors big instances who are connected broadly (and have the disk space and processing power to maintain a whole-network index). That's one of the reasons Meta looked at the ActivityPub Fediveres and say "yum". Of course ActivityPub doesn't have to be that way, The Website League is taking a different approach ... it'll be intersting to see if it takes less than six years for somebody to try something analogous on AT.

That looks nothing like the interoperable paradise that's on the label.

And it looks nothing like what Bluesky is today, so we'll see if it happens.

(Although, I don't think Bluesky's saying they'll have interoperability, their focus is more in terms of identity: you can use your AT identity (on Bluesky, self-hosted, or eventually maybe hosted by a provider) to access other AT apps. Of course there's no reason in principle you couldn't take that in the Fediverse as well, the current software just hasn't been designed that way.)

@jonny

jonny (good kind)

@jdp23 oh it's definitely true you can make apps on it that have some limited view of the network, that's useful, but that's not what they're promising and not what is being invested in. the critical part is that in that arrangement it becomes almost equivalent to nostr with a bilayer network, app views and pdses, without having any sort of server-to-server protocol: so they could just be mutually unintelligible islands. which is fine, but not what is being promised. and I think when most people think of account portability they think of "if i don't like this, i can take my data and go to something similar in kind" and there just isn't that with respect to the bluesky that people are familiar with now.

i could see the combined pds/relay/appview (which is also what bluesky currently is to 99.9999% of people). it's still substantially different from the AP fedi (which as usual i will remind others who i have not spoken about this with before and might be wandering by, i do not think is close to ideal either) in ways that are good -- i can be on multiple at the same time with the same identity, and also in ways that are bad - there's nothing in-protocol that anyone anywhere else can do to see us. As a pds, i can ask a relay to follow me, but i can't ask a relay to follow someone else. so without being on the main relay all interoperability between appview-like-things is lost in a way that's less recoverable than AP fedi. that is, unless everything is obligately indexed by the main relay as the point of interop, and we're back in chokepoint territory. and the series of mutually non-intelligible apps built on the social graph is exactly the business model that i think will be lucrative and drive them to shore up dependency on the relay to keep revenues coming. we haven't even talked about the way that advertising is going to play out in that kind of system, lest we not forget that privacy is impossible in the system too.

There will probably be some ad-hoc relay-to-relay protocol at some point, and one of the strong points of atproto is the fact that things can be relayed without needing to do auth back to the origin every time, but we're already seeing the limits of that with that lightweight firehose that people are having to rely on: sure we can make it cheap, but you have to throw away all the authentication parts. It's sort of this unhappy middle ground between true p2p and AP federation - AP federation works because it clumps resources and communities together and makes it manageable, but atproto is not really fit to be truly p2p either, unless you throw away most of the federation architecture and just use the pds and lexicon system, which are the most interesting parts to me.

ActivityPub is implemented today also has a chokepoint: it favors big instances who are connected broadly (and have the disk space and processing power to maintain a whole-network index).

I'm working on this and it's actually not that hard to overcome. backfilling and context expansion took like a week of concerted effort, and in the process i saw a bunch of places where efficiency could be improved. you don't need a whole-network index, and that's exactly because it's possible to get your instance to go exploring in a way that the relay will never be able to.

jonny (good kind)

just took a look at about a month of atproto firehose i have just been accumulating, and it looks like it's time for an update to the ol "is it becoming a communication medium yet" and the answer is even more no than before.
1% of accounts receive 72% of interactions (up from 44% last december when the network was a fraction of the size),
1% of posts receive 56% of all interactions, and
almost 90% of posts receive 0 interactions.

the distribution is steep too in the high end of that tail. Scrolling through the default feeds rn on a secondary account following zero people and with zero interactions, posts are averaging in the ~hundreds up to a tens of thousands of interactions. on my actual account where i have interacted with people, i receive the fixed proportion of low-interaction mixins from my network which is like 30-40%. Think about how common seeing a post with hundreds of interactions is tho in the default feeds - 0.01% of posts receive 470 likes, and 0.0001% receive 6300. That's how much the algorithmic amplification makes a monoculture.

I have been taking samples of fedi while developing fetch all replies and backfilling, and the distribution on AP fedi is... not like that... but i haven't taken a systematic sample.

one prior post, i'll find the other later:
https://neuromatch.social/@jonny/111656139481866077

Edit: to be clear, this a month sample of all likes and all accounts that were active in that month. So not all accounts from all time

Jon P

Agreed that account portability doesn't get people what they're hoping for: if you're banned from the Bluesky Relay and AppView, you essentially vanish from Bluesky and any other apps using that Relay. You've still got the data (which is better than being on a fediverse server that just vanishes before you've backed things up), and at some point in the future there might be other ways you can use it (which is approximately the same as having a backup of your fediverse data, there currently isn't any way to import it into another server but their might be).

And agreed that it the instance/federation-like structure I sketched is different from fedi in ways that are good and bad. Also right now everything there is public, and I kind of handwaved around that ... in principle you could do something with network-level firewalls that limit visibility to specific relays / appviews, but nobody's done it yet as far as I know so there may be gotchas.

In general I think of Bluesky and their investors interest in and intended uses for their protocol very much like Meta and Flipboard et al's interest and intended uses for AP. So yeah they're looking at how to exploit it, and the network they construct will be optimized for exploitation. But that's not the only way to use the protocols.

(Also AP has been in a weird situation for a bunch of years, the implementations to date have fixed around a certain way of using AP while more creative possibilities have languished ... that might be changing but then again I'm also hearing a lot of developers very frustrated with the protocol, which I consistently hear is very hard to program against, and ready to look at something different. So, it's hard to know how things will evolve.)

Your work on backfiling and context expansion is great and I hope it lands in Glitch soon (and maybe even Mastodon proper, although I'm not holding my breath) ... but does it address global search and hashtags? In principle a federated search could avoid any central(ish) index but I'm not sure that's feasible from a performance perspective. The fediverse's current solution on that front is activitypub relays, not great; Mastodon's direction is the Fediscovery stuff, which is architecturally somewhat similar to AT Relays, TBD how that works.

@jonny

jonny (good kind)

@jdp23 yeah, activitypub the whole protocol is a pain in the ass to work with. now that i've been doing it hands on with the masto implementation and i've been doing like several years of work writing data modeling tooling, i don't think that AP per se is the thing that can/should be rescued, but i do think that there are transitional paths ahead. a big thing is that just like the tooling for dealing with linked data objects of any kind is absolutely shit and has important impedance mismatches with typical OOP object systems.

like i said lexicons and PDSes as data and schema structures are the most interesting parts to me technically, and while i find the bsky team's code structure ... impenetrable ... other implementations are more readable to me and i can see why it would be a lot of fun to develop for. basically the "people are less personally invested in the infrastructure and don't expect to have any degree of personal control over it and by the way everything is public" situation sounds like a fun playground. lexicons/xrpc seems like something to learn from and iterate on, atm not being a linked system i think gives them a much easier onramp as like familiar json-schema+json-like blobs, and CIDs are a way better system than DNS-backed URIs for object distribution if you can assume resolution, but a lower "ceiling" because they can't compose naturally (and if i dare utter the cursed phrase, are 'closed world').

it's sort of a similar tension to the one that spawned JSON-LD from the XML RDF family, "this is weird and unfamiliar and highly academic and need to get it to where the web developers are at" but then it didn't quite get there and i think ends up being more awkward than a syntax that can serialize down to JSON. one of the ways i feel about lexicons too is that it might be on the other side of the sweet spot, too web dev like, not sprawly and languagelike enough. but that's something where time will definitely tell and i don't make strong predictions.

but i've typed too many letters today about standards and schema systems in particular today so i'm gonna stop and think about other things, we'll pick this up again in the future i am sure (or tomorrow if you have more thoughts i'm just a little lettered out this evening, a pleasure to chat as always)

jonny (good kind)

last thought on this for the night: one of the biggest red flags to me is that the default algorithms are conspicuously closed source. that was certainly a subject of the VC funding negotiations.

"do you have room to use the algorithm as a revenue generator if you need to, yes or no" and the answer is yes.

jonny (good kind)

conspicuously, as in there is no mention of this anywhere, the last trace of it in the code is from a database migration a year ago, and literally every other part of it is open source.

Jon P

yeah great discussion as always. i think we're in agreement about a lot of the underlying stuff, we're just emphasizing different aspects of it. i'm optimistic about fedi as a whole -- gotosocial's encouraging, so is the website league -- but i also think cross-fertilization of ideas and energy from Bluesky and AT is valuable.

Of course they are who they are and that's not gonna change (and that's not even getting to Masnick's "this way we don't have to censor Alex Jones" philosophy) but a lot of people are looking for Twitter alternatives so they're going to do well until they screw up. Right now there's a huge amount of innovation happening on the platform in multiple countries, not just US and Europe, so it's likely to progress a lot faster than AP. And, I'm really impressed with Blacksky's doing; there's a reason it's happening there and not on Fedi.

In the short term, the way I see things breaking down is

AP for networked scoped-visibility communities and federations today. Official AP power structure dominated by Meta, "free fediverses" (opposed to surveillance capitalism) probably deciding they'll need to do their own thing at some point
AT for broad public networks and public communities today (and maybe at some point scoped-visibility). ATmosphere even more dominated by Bluesky, unclear if "free ATmosphere" will emerge.
Bluesky likely to go the exploitative and surveillance capitalism route, timeframe unclear but probably not in the next few months. And even once they do, likely to remain less actively evil and threatening than Meta at least for a while, yes even with a Blockchain VC involved.

@jonny

bryan newbold

@jonny I know you have no reason to trust me, but investors don't care about the relay. if anything they are concerned that it is an ongoing cost sink, not that it is a power/control point that can be leveraged or exploited. the relay is a commodity service. there might be a future where relay operators charge for formal SLAs or guarantee of service, but that would just be cost recovery or razor-thin margins. "rent" requires ability to "exclude" which isn't possible with fully public data

bryan newbold

@jdp23 @jonny lots of good points in this thread!

I don't really understand focus on Relay as chokepoint, maybe a terminology thing. appview (index) is much more resource-intensive and powerful. relay is just a way to shuffle bytes from PDS instances to appviews. original appview consumed from PDS instances directly, and totally possible to do that (others are experimenting).

bryan newbold

@jdp23 @jonny concerns about visibility are real! but really center on the appview: if it is hard to run an index, then being excluded from dominant index is bad. one concept around this is a "shim" appview which merges results from multiple backing indices. if somebody is getting excluded from large index, can run a tiny index with just them, and then shim merges the two.

bryan newbold

@jdp23 @jonny DID centralization: yeah, it is bad for PLC to stay in Bluesky corp long-term. definitely plan to get that out. failure to do so would be a flag.

a way under-discussed thing here is client apps. for non-ActivityPub-brained folks, the app brand is really all they will see. at the end of the day, the app decides which is actually visible, and "defaults" for moderation, etc.

bryan newbold

@jdp23 @jonny in AP, instances come with a default web app interface (usually), so client apps are a bit less central/primary.

but for atproto, client apps are hugely powerful! they can exclude, they can be monetized, they are a brand, they mediate everything. they also have near-zero marginal cost by default. if you want to exploit atproto economically, you make a client app, not infra.

bryan newbold

@jdp23 @jonny I suspect this will also be true for AP ecosystem as it grows out of the Linux-sysadmin-friends-and-family demographic. and could be a similar polarization as "big fedi vs small fedi":

"instance fedi vs app fedi" or something like that. where folks end up not even knowing what instance they are on, b/c client app mediates experience more than instance.

Jon P

Thanks for the perspectives @bnewbold!

The "shim" is an interesting idea, when you say "multiple backing indexes", is that an AppView that merges multiple other AppViews or multiple Relays?

In terms of client apps being the way to monetize in ATproto ... well you've thought about it more than me, but I don't see how that's fundamentally any different than the pattern from Twitter, Reddit, etc. Client apps are completely dependent on Bluesky, so once you decide you want a share of all that juicy monetization going on they're screwed. It's great while the gold rush is going on but it's nothing new.

So one reason for the focus on Relay as a chokepoint is just that the AppView is such an obvious chokepoint that there isnt much to say. Also, Relays and PDSs are described as neutral infrastructure; AppViews aren't; and Relays' original name as the "Big Graph Server" make it seem like they -- not the AppView -- are the primarily index.

And how many of the apps you mentionin your funding annoouncement are built on top of the Bluesky AppView? Not sure about Bluecast, but if I recall correctly, FrontPage is an AppView that uses the Relay, SmokeSignal is an AppView that goes directly to the PDSs, When I was at the FrontPage tech talk they discussed how much easier the Relay makes things for them, and I didn't hear anybody asking them why they didn't use an AppView instead.

@jonny