Bsky raises $15m from Blockchain Capital, the VC's press release hints at what they're interested in:
-
@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.
-
@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.
-
@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.
-
@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.
-
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.
-
@jdp23 @jonny we basically see client apps and appviews as entwined (hence the name). a big app would run their own appview. the difference from platforms like reddit or Twitter is that they *can* do this, because all the public data is open, from the PDS instances (if you are building a big appview, you probably just run your own relay as well; and a CDN)
-
@jdp23 @jonny even alt bsky apps like greysky and deck.blue, which mostly build on the bluesky appview/API, have their own server infra for extra features. this broad pattern is sometimes called "backend for frontend", and we expect it to be more common, complementing the current pattern where clients directly connect to PDS. the "stausphere" demo app demonstrates it
-
I realize that's how you collectively see things ... you and I are quite possibly the only two people in fedi who believe that multiple Relays are likely (and even I am skeptical about how likely multiple full-network Relays are unless Bluesky PBC goes overboard trying to monetize or restrict your Relay). And I get it that Relays are optional but the paper says things like "Consuming the firehose is an easier way of building an index over the whole network, compared to directly subscribing to the source PDSes" and "Any developers wanting to create a new social mode on top of atproto can define a new lexicon with new record types, and these records can be stored in existing repositories and aggregated in the firehose without requiring any. changes to the Relay."
So time will tell, but as long as there aren't independent full-network Relays my guess is that people will continue to think of it as a chokepoint.
-
-
