There was a time not long ago when smart people would write blog posts about the topics of the day, other smart people would reply, and a big bustling conversation would ensue. It was aggregated in places like Techmeme and Technorati.
It's nice to see a little bit of that is still alive.
Bryan touches on an important axes in the question of how to structure decentralized networks in describing sharded search as "too risky to build on today."
Designs that a team thinks will be able to scale are going to be different from the ones built in a fully satisfying decentralized way. It's the prototyping and experimental networks that can help pave the way for more decentralized systems to get built with the intention of scale.
We couldn't pin this project on federated queries / decentralized indexes reaching scale & reliability, but that's what I'd encourage people to research. If somebody can make a breakthrough on it, they'd be able to introduce it as a variant AppView model on top of atproto.
I'm surprised so much has been written on this topic. I'm probably naive in thinking this is overcomplicating things. If you don't control the url to your content, you control nothing.
> If you don't control the url to your content, you control nothing.
I think you're right in general, strictly and technically speaking. But with that mindset, we basically cannot have any control on the internet unless you own your own IPs and a ASN, but even that is "leased" or ultimately controlled by someone else, it can always be taken away from you, one way or another.
So instead the discussion becomes about "degrees of control" if you will. Using Facebook to host whatever would be on the lower scale of "control", having your own website at some hosted service with possible exit would give you a bit more control and having your own domain pointing to a home server would give you even more control, and so on. Same goes for what "decentralized" really means, it's more of a range than a boolean of "yes/no decentralized".
Rather than this black and white view of "You control nothing unless you control the URI", (ATProto at least) people are trying to figure out a balance between "You control everything" and "It's a huge hassle to manage everything yourself".
I tend to agree with this, thats why theres canonical URIs for atproto posts that are agnostic to the hosting provider. The format is at://DID/collection/recordKey.
These are used throughout the system, for example if you look at the output of a feed generator, its just a list of these URIs
By this metric, you probably never have any control. Even the domain name you're using is not "yours"; you only rent it for a while and you may lose it.
Controlling the URL makes a lot of sense if you're publishing HTML that a browser can directly render but ATProto/Bluesky doesn't really work that way. The underlying data is CBOR/JSON that needs to be interpreted by an AppView and client. So you need to control the URL of your data and also control the AppView and client.
Right. There's probably an alternate reality where it's easy for anyone to own a domain and configure CNAME's for services they use like https://bluesky.yourname.com.
Wkat does URL ownership have to do with control over content? DNS & HTTP hosting are just another services. Maybe a bit less vulnerable themselves, than some social media website. But still, even facebook does routing errors & internet archive gets hacked.
What are the odds, the Direct Messaging solution, could be inspired / replicate the Matrix protocol? I love how the system works, despite many shortcomings (mostly on the front-end), especially the bridges to other services functionality.
Is there a chance the direct messaging task could enjoy some cooperation with the Matrix protocol / Element people?
I have little-to-no knowledge about the politics, goals & inner-working of both groups.
It's possible, and we've talked about it, but it would take a good amount of work (as would any 'correct' solution), so we have punted on properly solving DMs for a bit. I know Matthew has been very interested in working with us to figure something out here
On the Matrix side, we’d definitely like to help make this happen. Decentralised e2ee is Hard, and after a lot of iteration we’ve got Matrix into a good place these days (plus there’s a new wave of React Native Matrix dev happening atm). Plus we’re not shy about doing stuff like switching IDs on Matrix to DIDs, or even supporting ATProto as a federation mechanism and client/server API if that’s what it takes. https://bsky.app/profile/patak.dev/post/3lbbxbekjw22q gives more context.
What would suck is if bluesky ended up with an entirely incompatible (but functionally identical) thing, so that all the existing Matrix clients, bridges, servers etc couldn’t be leveraged.
I think that the clear preference people have for Bluesky over the Fediverse shows that maybe it's as decentralised as people as willing to accept.
Fedi is an amazing piece of software but so too people were/are bouncing off of it. I'm not one that shared the same frustration but it was very clearly a problem for many people.
Bluesky doesn't have that issue and has been easy for people to migrate to. At the end of the day, we can't let good be the enemy of perfect.
Bluesky has telephone verification. That is often an disqualifier and common for tech affine people. Not that many other networks did not make the same mistake.
I am not sure if Bluesky can have long term success to be honest.
Where did you see this? I've used the platform for 1.5 years or something, + created a new bot account just yesterday, and haven't been asked for a phone number for either accounts.
Bluesky has been popular for like a month. I think it would be very weird to evaluate "clear preference" for Bluesky vs. Mastodon based on the fact one is kinda trendy to post about today.
In a lot of ways Mastodon has reached normal daily productivity while Bluesky is on the peak of inflated expectations. A lot of problems Mastodon has or has dealt with are problems Bluesky hasn't meaningfully had to deal with yet.
My justification for stating that is that we're seeing people come back to Bluesky whereas people would try to create an account on a Mastodon service, their first post would be confusion and terror, and they'd leave after a few days of trying.
There are daily users of Mastodon (myself being one), it's just that the range of people is much smaller than Bluesky and Twitter due to the comparatively higher barrier of entry.
I don't know who these "people" are you are referring to, and these days the barrier to entry is quite low. I've helped people join a Mastodon instance and set up their profile and follow a few people in a matter of minutes. Whether they have any interest in continuing after that point is entirely up to them and their particular interests.
We haven't even begun to see the total possible size of ActivityPub-based social networking. The social web is in its infancy. Let's revisit this conversation in 10-20 years.
I mean I registered in 2018 and then apart from some initial experimentation mostly abandoned Mastodon until like 2021. There are people "coming back" to Mastodon all the time, and I’m sure plenty of people (myself included) signed up on Bluesky, went "meh", and then uninstalled the app because their phone didn't have enough free space for OS updates.
Anecdotes are sort of interesting but not necessarily representative. Numbers are also garbage, mostly because bots are a lot of the numbers.
Things need time, and as Bryan pointed out, the goals are pretty different. Maybe both are destined to win in their specific niches of global vs. nonglobal interaction. Maybe Bluesky kills Twitter (which is mostly global chat) and Mastodon kills Facebook (which is mostly friends chat).
> The bar we are shooting for is to convince people that atproto is legitimate and useful even if Bluesky and the team adopt the worst of intentions.
Oof, that's a high bar. The protocol itself may still be technically useful, sure, but Bluesky could tomorrow block access to its PDS and relays, disallow migrations, stop digesting data from other PDSes or even completely drop atproto - and the vast majority of now locked-in users wouldn't notice.
Honestly i wish people would give up on the whole decentralized/federated thing. There are so many variants of the notion, and most implentations implement something that meets some technical definition of decentralized but not a useful one from a social perspective (especially at scale)
You want people to give up trying to make something better because you don't think they've succeeded yet?
Multiple projects that are fairly distributed have achieved a pretty high level of success, and I don't think there's any reason to think we can't do even better in the future.
BitTorrent, Git, XMPP, Matrix, Mastodon, BlueSky - all different levels of distributed and different amounts of popular, but I'd argue they're all at least moderately if not wildly successful, and all are it least partially distributed.
Honestly i wish people would give up on the whole performance/scalability thing. There are so many variants of the notion, and most implentations implement something that meets some technical definition of fast/scalable but not a useful one from a social perspective
There was a time not long ago when smart people would write blog posts about the topics of the day, other smart people would reply, and a big bustling conversation would ensue. It was aggregated in places like Techmeme and Technorati.
It's nice to see a little bit of that is still alive.
Bryan touches on an important axes in the question of how to structure decentralized networks in describing sharded search as "too risky to build on today."
Designs that a team thinks will be able to scale are going to be different from the ones built in a fully satisfying decentralized way. It's the prototyping and experimental networks that can help pave the way for more decentralized systems to get built with the intention of scale.
We couldn't pin this project on federated queries / decentralized indexes reaching scale & reliability, but that's what I'd encourage people to research. If somebody can make a breakthrough on it, they'd be able to introduce it as a variant AppView model on top of atproto.
I'm surprised so much has been written on this topic. I'm probably naive in thinking this is overcomplicating things. If you don't control the url to your content, you control nothing.
> If you don't control the url to your content, you control nothing.
I think you're right in general, strictly and technically speaking. But with that mindset, we basically cannot have any control on the internet unless you own your own IPs and a ASN, but even that is "leased" or ultimately controlled by someone else, it can always be taken away from you, one way or another.
So instead the discussion becomes about "degrees of control" if you will. Using Facebook to host whatever would be on the lower scale of "control", having your own website at some hosted service with possible exit would give you a bit more control and having your own domain pointing to a home server would give you even more control, and so on. Same goes for what "decentralized" really means, it's more of a range than a boolean of "yes/no decentralized".
Rather than this black and white view of "You control nothing unless you control the URI", (ATProto at least) people are trying to figure out a balance between "You control everything" and "It's a huge hassle to manage everything yourself".
I tend to agree with this, thats why theres canonical URIs for atproto posts that are agnostic to the hosting provider. The format is at://DID/collection/recordKey.
These are used throughout the system, for example if you look at the output of a feed generator, its just a list of these URIs
In some ways that's worse because it means you can be blocked at the DID layer.
By this metric, you probably never have any control. Even the domain name you're using is not "yours"; you only rent it for a while and you may lose it.
Controlling the URL makes a lot of sense if you're publishing HTML that a browser can directly render but ATProto/Bluesky doesn't really work that way. The underlying data is CBOR/JSON that needs to be interpreted by an AppView and client. So you need to control the URL of your data and also control the AppView and client.
Right. There's probably an alternate reality where it's easy for anyone to own a domain and configure CNAME's for services they use like https://bluesky.yourname.com.
Wkat does URL ownership have to do with control over content? DNS & HTTP hosting are just another services. Maybe a bit less vulnerable themselves, than some social media website. But still, even facebook does routing errors & internet archive gets hacked.
What are the odds, the Direct Messaging solution, could be inspired / replicate the Matrix protocol? I love how the system works, despite many shortcomings (mostly on the front-end), especially the bridges to other services functionality.
Is there a chance the direct messaging task could enjoy some cooperation with the Matrix protocol / Element people?
I have little-to-no knowledge about the politics, goals & inner-working of both groups.
It's possible, and we've talked about it, but it would take a good amount of work (as would any 'correct' solution), so we have punted on properly solving DMs for a bit. I know Matthew has been very interested in working with us to figure something out here
On the Matrix side, we’d definitely like to help make this happen. Decentralised e2ee is Hard, and after a lot of iteration we’ve got Matrix into a good place these days (plus there’s a new wave of React Native Matrix dev happening atm). Plus we’re not shy about doing stuff like switching IDs on Matrix to DIDs, or even supporting ATProto as a federation mechanism and client/server API if that’s what it takes. https://bsky.app/profile/patak.dev/post/3lbbxbekjw22q gives more context.
What would suck is if bluesky ended up with an entirely incompatible (but functionally identical) thing, so that all the existing Matrix clients, bridges, servers etc couldn’t be leveraged.
I think that the clear preference people have for Bluesky over the Fediverse shows that maybe it's as decentralised as people as willing to accept.
Fedi is an amazing piece of software but so too people were/are bouncing off of it. I'm not one that shared the same frustration but it was very clearly a problem for many people.
Bluesky doesn't have that issue and has been easy for people to migrate to. At the end of the day, we can't let good be the enemy of perfect.
Bluesky has telephone verification. That is often an disqualifier and common for tech affine people. Not that many other networks did not make the same mistake.
I am not sure if Bluesky can have long term success to be honest.
Telephone verification doesn’t tend to be a major factor in whether software products are successful.
> Bluesky has telephone verification.
Where did you see this? I've used the platform for 1.5 years or something, + created a new bot account just yesterday, and haven't been asked for a phone number for either accounts.
I made a Bluesky account without a phone number. Not sure what you're talking about.
Bluesky has been popular for like a month. I think it would be very weird to evaluate "clear preference" for Bluesky vs. Mastodon based on the fact one is kinda trendy to post about today.
In a lot of ways Mastodon has reached normal daily productivity while Bluesky is on the peak of inflated expectations. A lot of problems Mastodon has or has dealt with are problems Bluesky hasn't meaningfully had to deal with yet.
My justification for stating that is that we're seeing people come back to Bluesky whereas people would try to create an account on a Mastodon service, their first post would be confusion and terror, and they'd leave after a few days of trying.
There are daily users of Mastodon (myself being one), it's just that the range of people is much smaller than Bluesky and Twitter due to the comparatively higher barrier of entry.
I don't know who these "people" are you are referring to, and these days the barrier to entry is quite low. I've helped people join a Mastodon instance and set up their profile and follow a few people in a matter of minutes. Whether they have any interest in continuing after that point is entirely up to them and their particular interests.
We haven't even begun to see the total possible size of ActivityPub-based social networking. The social web is in its infancy. Let's revisit this conversation in 10-20 years.
> I've helped people join a Mastodon instance and set up their profile and follow a few people in a matter of minutes.
That you had to do this is the issue that I'm talking about.
And here I thought the point of "social" media is to be, y'know, social and all.
Absolutely is but if onboarding requires help from a human then there is work to be done.
I mean I registered in 2018 and then apart from some initial experimentation mostly abandoned Mastodon until like 2021. There are people "coming back" to Mastodon all the time, and I’m sure plenty of people (myself included) signed up on Bluesky, went "meh", and then uninstalled the app because their phone didn't have enough free space for OS updates.
Anecdotes are sort of interesting but not necessarily representative. Numbers are also garbage, mostly because bots are a lot of the numbers.
Things need time, and as Bryan pointed out, the goals are pretty different. Maybe both are destined to win in their specific niches of global vs. nonglobal interaction. Maybe Bluesky kills Twitter (which is mostly global chat) and Mastodon kills Facebook (which is mostly friends chat).
> The bar we are shooting for is to convince people that atproto is legitimate and useful even if Bluesky and the team adopt the worst of intentions.
Oof, that's a high bar. The protocol itself may still be technically useful, sure, but Bluesky could tomorrow block access to its PDS and relays, disallow migrations, stop digesting data from other PDSes or even completely drop atproto - and the vast majority of now locked-in users wouldn't notice.
Honestly i wish people would give up on the whole decentralized/federated thing. There are so many variants of the notion, and most implentations implement something that meets some technical definition of decentralized but not a useful one from a social perspective (especially at scale)
You want people to give up trying to make something better because you don't think they've succeeded yet?
Multiple projects that are fairly distributed have achieved a pretty high level of success, and I don't think there's any reason to think we can't do even better in the future.
BitTorrent, Git, XMPP, Matrix, Mastodon, BlueSky - all different levels of distributed and different amounts of popular, but I'd argue they're all at least moderately if not wildly successful, and all are it least partially distributed.
Honestly i wish people would give up on the whole performance/scalability thing. There are so many variants of the notion, and most implentations implement something that meets some technical definition of fast/scalable but not a useful one from a social perspective