* 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."
The reason for this is that domain names are aliases. Your permanent ID is the DID, which the domain name maps to.
At least, that's what people have been saying, the docs don't seem to mention that (anymore?) so maybe the placeholders weren't really placeholders after all. The npm package still mention placeholders (https://www.npmjs.com/package/@atproto/plc?activeTab=readme) but the up to date Github uses "Public Ledger of Credentials" as a backronym (https://github.com/did-method-plc/did-method-plc).
Based on the docs it seems like a web DID is technically just as valid a permanent DID as a placeholder DID, though that depends on the server implementation of course.
if I do something controversial or using regulatory arbitrage, I'm interested in how AT is useful for managing that risk.
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.
* 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.
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 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 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.
This sounds like a critical issue that should've been fixed as soon as possible.
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.
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.
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)
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.
What happens when a new index is created on another server?
Being inconvenienced by having to build up the contact list and therefore staying locked in with X seems to meet to fundamentally misunderstand, well, everything. All of the motivations for moving which are centered on seizing the benefits of federation for social media and preventing companies from locking in, to me those are at a different order of magnitude in terms of their importance.
It's like not accepting the cure to your cancer because it comes in a green pill and green isn't your favorite color.
All of that said I do accept and embrace the criticisms especially of blue sky because it does seem to have weird loopholes, seems to have a preference for centralization built into the protocol which kind of misses the point, and generally is contributing to the squandering of what could have been a grand fediverse moment, all due to some idiosyncratic squabbles over things like how to handle usernames.
Good things sometimes come to an end, but they're still worth doing while they're still good. Twitter had a good run before it went bad. The BlueSky party is just getting started. Sure, many things aren't done yet, but we don't know how it's going to turn out.
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).
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.
It's entirely up to WhiteWind whether they use bluesky's follow schemas or not. There's no blocker on that. The only question they have to ask is whether that's how they want it to work.
Another option that's available for them/others is to read from the bluesky follows to provide suggestions, but then use another schema for subscriptions.
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!
Genuine question, considering you can already do what you're talking about with ActivityPub what makes you stick around on ATproto/Bsky?
I believe the architectural model of ActivityPub is bad. I think the architectural model of atproto is good. Everything is downstream of that.
I don’t have time to elaborate at this exact moment, but figured I’d at least give you a preliminary answer.
ActivityPub is a W3C standard which uses standard, “boring”, sometimes “complex” (JSON-LD) technologies.
The fact the AT protocol does things smarter doesn’t mean it should, or will, be used on the WWW. There’s a reason why we still use e-mail and JSON for interoperability, instead of smarter technology.
We should favor standards IMHO, even if they’re imperfect.
Anyway, I’m really curious about your analysis in your future comments!
Being fit for purpose is more important than being "standard", if a standard doesn't do what it needs to do, that it's standard is irrelevant. Bluesky/atproto uses a ton of standard approaches where appropriate, and innovates where appropriate.
Standards are borne out of usage, and a need to interoperate. Being blessed by a standards body doesn't inherently mean something is good. I can represent some data in JSON, or in HTML, but because both are standards doesn't mean that they're equally good. Standardization is a means to an end, not an inherent good in and of itself. People need to try new things in order to eventually produce new standards.
I successfully changed my handle to @tony.apms.com.au / at://tony.apms.com.au [2]
[1] https://blueskyweb.zendesk.com/hc/en-us/articles/19001802873...
[2] https://atproto-browser.vercel.app/at/did:plc:aey2msnboqkmg3...