After some insightful sharing from Bsky devs in some other threads on here I am definitely reconsidering it....especially around the usefulness of the domain-centric identity model. But I remain concerned about Bsky developing their features slowly in the open. Which leaves it lacking (if you're looking to hit the ground running with a full fledged social network, not repeat the years of growth from early twitter), and also open to weird loopholes like some ppl realized you could use an archive of tweets with some scripts from a dev on github and backdate posts into Bluesky. Meaning you could write wacky tweets like from Sept 11 2001 etc and they're all sitting there on the network like they 'happened' weirdly with comments from 2024. And one of the developers in the replies of one of the jokey posts alarmingly saying we need to fix this ... in March 2024 (not yet fixed, still being exploited).
As Doctorow writes, putting the energy into building up your contact list all over again is not appealing at all and so remain wary of this. Similar reasons not to go all in on Mastodon which wasn't it or any of the other centralized Twitter clones that popped up a year or two ago which have now started to shut down etc.
It is actually fixed. Tweets have been showing up with their "Indexed On" date instead of the actual authoring date. The thing that isn't implemented is showing both dates for tweets with separate dates.
It's more of a temporary workaround iiuc, the real fix needs to happen in the UI. Posts have two timestamps, the "createdAt" timestamp which can be anything the author says it is, and the "indexedAt" timestamp, which is not an intrinsic property of the post but whenever the AppView server first saw it (which is relatively more trustworthy, but could be different across multiple AppView instances).
The proper fix, imho, is to have the UI display the "createdAt" timestamp but warn (perhaps with some kind of alert icon) when there's a significant mismatch between createdAt and indexedAt.
(An even more proper fix might involve a quorum of "witness" servers but that might be an exercise in scope creep)
Everybody's kind of got it. We didn't publish a lot the past couple days because we didn't want to highlight the situation during the election. Our fault for not solving it sooner.
Here's the full deal. Every record self-declares a createdAt which can't be fully trusted. Every appview records indexedAt which is == to "first seen at." We can always expect indexedAt to lag behind a "correct" createdAt, and in ideal conditions that lag is quite small.
The server was previously blending the internal indexedAt with the declared createdAt by returning the min(createdAt, indexedAt). Blending a trusted-but-lagging timestamp with the declared timestamp is a technique that works for sorting under specific conditions; if you're doing reverse-chron ordering you take the min of both, and if you're doing chron ordering you take the max.
We will continue to use the blended min() for ordering within reverse chron feeds, but the problem is that we've historically been sending that down to the client for rendering. We recently changed it to give the actual `indexedAt`, which is part of the full solution. Unfortunately in the weeks preceding that change, a bunch of tweet importers had gotten popular without us realizing it, and our change caused the imports to all show the import time instead of the create time. So, we reverted that for now.
The plan is what retroid describes -- we turn back on that change to the server behavior, and then if `createdAt < indexedAt - 24hr` or so, we indicate in the UI that it's likely an import from an archive. That's the full longterm solution. A quorum witness model is definitely overdoing it for now, but we have discussed creating exports of our index times so that new appviews can take advantage of them when doing backfill.
> and also open to weird loopholes like some ppl realized you could use an archive of tweets with some scripts from a dev on github and backdate posts into Bluesky. Meaning you could write wacky tweets like from Sept 11 2001 etc and they're all sitting there on the network like they 'happened' weirdly with comments from 2024
This sounds like a critical issue that should've been fixed as soon as possible.
This is how the whole rest of the web works, though. I can backdate my self-hosted blog articles to whenever I want. Heck, I can even backdate my git commits to whenever I want.
There is a safety issue here in practice and I don't want to downplay it (it violates user expectations), but I don't think it's "obviously" bad.
I think the violation of user expectations is much more severe on a micro-blogging platform like Twitter or BlueSky than it would be on git commits and even website blog post because of how that information is consumed.
of course. while I do appreciate the advantages it might offer for quick migration/onboarding...(how great to migrate your entire twitter history into place) to get a bunch of ppl onto the network, but it being abused to change history is a no-no. I'm all for open web/indie web/ability to move your data around but let's not pretend ppl were on Blue Sky for a decade. Sigh.
>Right now, there aren’t a lot of other apps in the ATmopshere, but there are experiments happening. There’s a blogging tool called WhiteWind, a Reddit clone called frontpage.fyi, and an events app called Smoke Signal. More will follow, I’m sure.
The unfortunate thing about ATproto is that even tho there are these apps that are built on top of it. None of these app actually talk to each other. Bluesky the app has no idea what you're posting on WhiteWind and vice versa. This is the BIG advantage ActivityPub has over AT. A Mastodon account can follow accounts on any ActivityPub compatible server and they're able to talk to each other. You can follow a peertube channel or some AP enabled wordpress blog and it'll all be visible and intractable inside your Mastodon feed.
At the moment, ATproto to me, seems a lot more like a glorified oAuth system than anything else. It's a lot like using your google account to login on an app and then have your data stored in google drive (your PDS).
That’s not a problem at all. These applications have different concepts and the overlap hasn’t been formally defined yet. Should they choose to do so, they can easily connect up. I think it’s great that different applications can exist on the same base layer and explore concepts independently from each other.
It’s just early days. This is a “hasn’t happened” and not a “can’t happen.”
I myself am thinking about serving my entire website out of my PDS. I’ll be blending several existing Lexicons together and probably making some of my own.
I think these possibilities are some of the strongest reasons to be intrigued by AT Protocol, but I also hear you that it’s more potential than actively realized as of today. It’ll get there!
There's nothing substantively stopping that from happening, it's just that bluesky and the other app devs haven't used each others schemas to trigger it. For instance, if frontpage really wanted to, they could publish stories as bluesky-schema posts. It just doesn't produce a win yet. There's some discussion about introducing some schemas that would make that worth doing.
I think the fact that devs even have to think about using "each others schemas" is a pretty big flaw in the system. It would definitely make ATProto look a lot better if it had a standardized way for all of its app to talk to each other. You don't want devs to have to implement new schemas for each and every new app that pops up on AT just so they can communicate with each other.
Like, it would be pretty dang cool if you could follow a WhiteWind blog from your Bluesky account. Honestly I'm a bit confused as to why this isn't a priority for the Bsky team.
Ed Zitron has an interview with Mike Masnick (Techdirt, board member of Bluesky) on the latest ep of the Better Offline[0] podcast. Pretty interesting, though I wasn't entirely convinced that Bluesky will deliver the solution we need. But it's encouraging to see progress in the various efforts to wrest control of the web from big corporations. I'm a fediverse fan, myself.
> how does bluesky solve the problem of building your castle in another man's kingdom?
Bluesky (the platform) doesn't, and they acknowledge that. It's centrally owned, and is prone to all of the risks that any other centralized platform offers.
> if I do something controversial or using regulatory arbitrage, I'm interested in how AT is useful for managing that risk.
AT is completely decentralized, like email.
If your account is @motohagiography.example.com, other AT instances will make a DNS query to example.com to see if that has an entry that the AT protocol recognizes. If so, it will make a connection to that instance, and gather your content for display.
However, if a particular instance sees their a volume of unwanted accounts from example.com, they could blacklist that domain from interacting with their instance, so, even with this setup, you are at the mercy of the "big players" respecting you — just like if you try to send email to users using Gmail and Google decides you're suspect.
And, if you violate the laws of where you're located, law enforcement will handle that the same as they would if you violating the laws over HTTP or over email.
If you choose to have someone host your own web site, then it's up to them what happens to it. You're using their servers after all. If you have your own host, you get to decide what happens there.
Likewise, a search engine can say "hey, I don't like what's happening on that website, so I won't surface it in results," but they cannot shut your website down.
Now, the only twist here is that currently, atproto is kind of like if there was only one real DNS server, and it was also owned by your search engine. That is, BlueSky the company runs plc.directory. So in the maximal sense, "if you run your own server" is technically "and you only get an IP address, not a domain name," that is, if plc.directory decides to unlist you, then folks can't find your posts. There is an alternative to plc.directory, but basically nobody actually uses it at the moment.
Okay, so on a technical level, that's the rough explanation. On the social level:
> Atproto's model is that speech and reach should be two separate layers, built to work with each other. The “speech” layer should remain permissive, distributing authority and designed to ensure everyone has a voice. The “reach” layer lives on top, built for flexibility and designed to scale.
> The base layer of atproto (personal data repositories and federated networking) creates a common space for speech where everyone is free to participate, analogous to the Web where anyone can put up a website. The indexing services then enable reach by aggregating content from the network, analogous to a search engine.
On the PDSes that Bluesky hosts, they will remove illegal content, but nothing else. That's the "speech" part. However, they do moderate Bluesky itself, and there's a gradient there: they will remove some things, they will also tag some things, allowing users to decide if they want to see it or not.
As far as the "DNS problem," they've stated that they wish to move it into an external foundation, to build additional safeguards there. I personally believe them, because they have promised many things, including things that have reduced their own power and control over the network, many times, and then followed through. You can choose to believe them or not, or wait until it's the case before getting invovled.
Only worrisome situation now is that they had some major funding and new people to the board who might not respect the core values. Bs userbase is expanding fast now days.
I agree that I don’t trust them as much as I trust the team, but they’ve been saying the right things too. Time will tell.
I somehow find myself in virtually the opposite position as many people: I am also very anti blockchain, but I think the investment makes a lot of sense and can see that it might be a great fit. Well just have to see.
As someone who's currently on the brink of signing up to bluesky: what's the recommended way of picking a handle, then? Are there any downsides to going with a normal `@name.bsky.social` thing first and later switching if I feel there is a need? Or should I best use my own domain from the get go?
It's truly up to you. Swapping to your domain won't affect anything, so you can do so whenever you'd like. I was known as steveklabnik.bsky.social for a couple of weeks before I changed it to steveklabnik.com.
After some insightful sharing from Bsky devs in some other threads on here I am definitely reconsidering it....especially around the usefulness of the domain-centric identity model. But I remain concerned about Bsky developing their features slowly in the open. Which leaves it lacking (if you're looking to hit the ground running with a full fledged social network, not repeat the years of growth from early twitter), and also open to weird loopholes like some ppl realized you could use an archive of tweets with some scripts from a dev on github and backdate posts into Bluesky. Meaning you could write wacky tweets like from Sept 11 2001 etc and they're all sitting there on the network like they 'happened' weirdly with comments from 2024. And one of the developers in the replies of one of the jokey posts alarmingly saying we need to fix this ... in March 2024 (not yet fixed, still being exploited).
As Doctorow writes, putting the energy into building up your contact list all over again is not appealing at all and so remain wary of this. Similar reasons not to go all in on Mastodon which wasn't it or any of the other centralized Twitter clones that popped up a year or two ago which have now started to shut down etc.
> not yet fixed, still being exploited
It is actually fixed. Tweets have been showing up with their "Indexed On" date instead of the actual authoring date. The thing that isn't implemented is showing both dates for tweets with separate dates.
'fixed' or being worked on..... Still not cool and just an example of the 'building in public' approach that rubs me the wrong way.
To me it sounds like it's fixed?
It's more of a temporary workaround iiuc, the real fix needs to happen in the UI. Posts have two timestamps, the "createdAt" timestamp which can be anything the author says it is, and the "indexedAt" timestamp, which is not an intrinsic property of the post but whenever the AppView server first saw it (which is relatively more trustworthy, but could be different across multiple AppView instances).
The proper fix, imho, is to have the UI display the "createdAt" timestamp but warn (perhaps with some kind of alert icon) when there's a significant mismatch between createdAt and indexedAt.
(An even more proper fix might involve a quorum of "witness" servers but that might be an exercise in scope creep)
Everybody's kind of got it. We didn't publish a lot the past couple days because we didn't want to highlight the situation during the election. Our fault for not solving it sooner.
Here's the full deal. Every record self-declares a createdAt which can't be fully trusted. Every appview records indexedAt which is == to "first seen at." We can always expect indexedAt to lag behind a "correct" createdAt, and in ideal conditions that lag is quite small.
The server was previously blending the internal indexedAt with the declared createdAt by returning the min(createdAt, indexedAt). Blending a trusted-but-lagging timestamp with the declared timestamp is a technique that works for sorting under specific conditions; if you're doing reverse-chron ordering you take the min of both, and if you're doing chron ordering you take the max.
We will continue to use the blended min() for ordering within reverse chron feeds, but the problem is that we've historically been sending that down to the client for rendering. We recently changed it to give the actual `indexedAt`, which is part of the full solution. Unfortunately in the weeks preceding that change, a bunch of tweet importers had gotten popular without us realizing it, and our change caused the imports to all show the import time instead of the create time. So, we reverted that for now.
The plan is what retroid describes -- we turn back on that change to the server behavior, and then if `createdAt < indexedAt - 24hr` or so, we indicate in the UI that it's likely an import from an archive. That's the full longterm solution. A quorum witness model is definitely overdoing it for now, but we have discussed creating exports of our index times so that new appviews can take advantage of them when doing backfill.
How does this fix the above issue on a decentralized network?
What happens when a new index is created on another server?
> and also open to weird loopholes like some ppl realized you could use an archive of tweets with some scripts from a dev on github and backdate posts into Bluesky. Meaning you could write wacky tweets like from Sept 11 2001 etc and they're all sitting there on the network like they 'happened' weirdly with comments from 2024
This sounds like a critical issue that should've been fixed as soon as possible.
This is how the whole rest of the web works, though. I can backdate my self-hosted blog articles to whenever I want. Heck, I can even backdate my git commits to whenever I want.
There is a safety issue here in practice and I don't want to downplay it (it violates user expectations), but I don't think it's "obviously" bad.
I think the violation of user expectations is much more severe on a micro-blogging platform like Twitter or BlueSky than it would be on git commits and even website blog post because of how that information is consumed.
of course. while I do appreciate the advantages it might offer for quick migration/onboarding...(how great to migrate your entire twitter history into place) to get a bunch of ppl onto the network, but it being abused to change history is a no-no. I'm all for open web/indie web/ability to move your data around but let's not pretend ppl were on Blue Sky for a decade. Sigh.
>Right now, there aren’t a lot of other apps in the ATmopshere, but there are experiments happening. There’s a blogging tool called WhiteWind, a Reddit clone called frontpage.fyi, and an events app called Smoke Signal. More will follow, I’m sure.
The unfortunate thing about ATproto is that even tho there are these apps that are built on top of it. None of these app actually talk to each other. Bluesky the app has no idea what you're posting on WhiteWind and vice versa. This is the BIG advantage ActivityPub has over AT. A Mastodon account can follow accounts on any ActivityPub compatible server and they're able to talk to each other. You can follow a peertube channel or some AP enabled wordpress blog and it'll all be visible and intractable inside your Mastodon feed.
At the moment, ATproto to me, seems a lot more like a glorified oAuth system than anything else. It's a lot like using your google account to login on an app and then have your data stored in google drive (your PDS).
That’s not a problem at all. These applications have different concepts and the overlap hasn’t been formally defined yet. Should they choose to do so, they can easily connect up. I think it’s great that different applications can exist on the same base layer and explore concepts independently from each other.
It’s just early days. This is a “hasn’t happened” and not a “can’t happen.”
I myself am thinking about serving my entire website out of my PDS. I’ll be blending several existing Lexicons together and probably making some of my own.
I think these possibilities are some of the strongest reasons to be intrigued by AT Protocol, but I also hear you that it’s more potential than actively realized as of today. It’ll get there!
There's nothing substantively stopping that from happening, it's just that bluesky and the other app devs haven't used each others schemas to trigger it. For instance, if frontpage really wanted to, they could publish stories as bluesky-schema posts. It just doesn't produce a win yet. There's some discussion about introducing some schemas that would make that worth doing.
I think the fact that devs even have to think about using "each others schemas" is a pretty big flaw in the system. It would definitely make ATProto look a lot better if it had a standardized way for all of its app to talk to each other. You don't want devs to have to implement new schemas for each and every new app that pops up on AT just so they can communicate with each other.
Like, it would be pretty dang cool if you could follow a WhiteWind blog from your Bluesky account. Honestly I'm a bit confused as to why this isn't a priority for the Bsky team.
Ed Zitron has an interview with Mike Masnick (Techdirt, board member of Bluesky) on the latest ep of the Better Offline[0] podcast. Pretty interesting, though I wasn't entirely convinced that Bluesky will deliver the solution we need. But it's encouraging to see progress in the various efforts to wrest control of the web from big corporations. I'm a fediverse fan, myself.
[0] https://www.betteroffline.com
I would seriously consider building my next startup using AT, but how does bluesky solve the problem of building your castle in another man's kingdom?
if I do something controversial or using regulatory arbitrage, I'm interested in how AT is useful for managing that risk.
> how does bluesky solve the problem of building your castle in another man's kingdom?
Bluesky (the platform) doesn't, and they acknowledge that. It's centrally owned, and is prone to all of the risks that any other centralized platform offers.
> if I do something controversial or using regulatory arbitrage, I'm interested in how AT is useful for managing that risk.
AT is completely decentralized, like email.
If your account is @motohagiography.example.com, other AT instances will make a DNS query to example.com to see if that has an entry that the AT protocol recognizes. If so, it will make a connection to that instance, and gather your content for display.
However, if a particular instance sees their a volume of unwanted accounts from example.com, they could blacklist that domain from interacting with their instance, so, even with this setup, you are at the mercy of the "big players" respecting you — just like if you try to send email to users using Gmail and Google decides you're suspect.
And, if you violate the laws of where you're located, law enforcement will handle that the same as they would if you violating the laws over HTTP or over email.
A useful mental model for AT is the web:
* Your PDS is like your own website.
* Bluesky is like a search engine.
* plc.directory is like DNS.
If you choose to have someone host your own web site, then it's up to them what happens to it. You're using their servers after all. If you have your own host, you get to decide what happens there.
Likewise, a search engine can say "hey, I don't like what's happening on that website, so I won't surface it in results," but they cannot shut your website down.
Now, the only twist here is that currently, atproto is kind of like if there was only one real DNS server, and it was also owned by your search engine. That is, BlueSky the company runs plc.directory. So in the maximal sense, "if you run your own server" is technically "and you only get an IP address, not a domain name," that is, if plc.directory decides to unlist you, then folks can't find your posts. There is an alternative to plc.directory, but basically nobody actually uses it at the moment.
Okay, so on a technical level, that's the rough explanation. On the social level:
Here's what they have to say: https://docs.bsky.app/docs/advanced-guides/atproto#speech-re...
> Atproto's model is that speech and reach should be two separate layers, built to work with each other. The “speech” layer should remain permissive, distributing authority and designed to ensure everyone has a voice. The “reach” layer lives on top, built for flexibility and designed to scale.
> The base layer of atproto (personal data repositories and federated networking) creates a common space for speech where everyone is free to participate, analogous to the Web where anyone can put up a website. The indexing services then enable reach by aggregating content from the network, analogous to a search engine.
On the PDSes that Bluesky hosts, they will remove illegal content, but nothing else. That's the "speech" part. However, they do moderate Bluesky itself, and there's a gradient there: they will remove some things, they will also tag some things, allowing users to decide if they want to see it or not.
As far as the "DNS problem," they've stated that they wish to move it into an external foundation, to build additional safeguards there. I personally believe them, because they have promised many things, including things that have reduced their own power and control over the network, many times, and then followed through. You can choose to believe them or not, or wait until it's the case before getting invovled.
> I personally believe them.
Only worrisome situation now is that they had some major funding and new people to the board who might not respect the core values. Bs userbase is expanding fast now days.
I agree that I don’t trust them as much as I trust the team, but they’ve been saying the right things too. Time will tell.
I somehow find myself in virtually the opposite position as many people: I am also very anti blockchain, but I think the investment makes a lot of sense and can see that it might be a great fit. Well just have to see.
As someone who's currently on the brink of signing up to bluesky: what's the recommended way of picking a handle, then? Are there any downsides to going with a normal `@name.bsky.social` thing first and later switching if I feel there is a need? Or should I best use my own domain from the get go?
Nope, you can switch domains at any point. It'll break web links to your profile, but the network won't struggle to keep track of who you are.
The reason for this is that domain names are aliases. Your permanent ID is the DID, which the domain name maps to.
It's truly up to you. Swapping to your domain won't affect anything, so you can do so whenever you'd like. I was known as steveklabnik.bsky.social for a couple of weeks before I changed it to steveklabnik.com.
Are there any examples of apps that bluesky's 13 million users can login to?
The best known ones right now are:
* Hacker News clone: https://frontpage.fyi/
* Events app: https://smokesignal.events/
* Blog platform: https://whtwnd.com/
There's toooons of alternative clients, but that's not the same thing as "independent application."
https://graysky.app/