Bsky raises $15m from Blockchain Capital, the VC's press release hints at what they're interested in:
-
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.
-
@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)replied to jonny (good kind) last edited by
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)replied to jonny (good kind) last edited by
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.
-
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.
-
bryan newboldreplied to jonny (good kind) last edited by
@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
-
@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).
-
@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.
-
-
