Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I've wondered for awhile why someone hasn't started the Blogger.com of ActivityPub/Mastodon: 1 "instance" per person, no weird complicated group dynamics, the service handles all the technical details, the user draws from the same cohort as the people who signed up for Blogger blogs in the early aughts.

    If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage; like, I can see how Mastodon keeps chugging along no matter what companies get sold to who, but I don't see how ATProto survives the death of Bsky.

  • So every user would have to individually block all the nazi and child porn instances?
  • The same reason that they don't do that for Email. It's a lot more complicated for little obvious gain
  • I don’t know what you mean by “instances” here. Leaflet (https://leaflet.pub) is one of those “blogger on atproto” things — is that what you mean?
  • The RSS comparison is misleading.

    Atproto apps are not like an RSS reader that runs on the users' computers and connects directly to the sources of content.

    Atproto apps are servers that control, filter and shape the content they serve to readers.

    Atproto apps can censor, shadowban, show ads, algorithmize the feed into anything it wants. The user is powerless and the creator is a victim that can't do anything besides crying.

    The fact that any person can host their data anywhere is completely meaningless since they have no way of distributing that data.

  • That’s not really true. For one, you can have different AppViews which don’t do that. The feeds can be algorithmic however you the user want — multiple apps means you aren’t tied to what one central creator desires for those algorithms.
  • That’s the whole point of “apps”. Apps are opinionated points of view / prisms over the network. Of course they’re able to apply their own moderation decisions. That’s how the whole mainstream web works in general — you can’t even get an unmoderated app into App Stores.

    The difference is that it’s competitive. New apps can rise up that provide alternative lenses over the network. In the crudest case, literally showing everything. Which is what you wanted. Maybe that won’t get into an App Store but it definitely works if there’s demand for that.

  • An important distinction is that blogs have their own websites and they're not required to publish full articles in their RSS feed.

    Bluesky doesn't normally work that way - everything in the PDS gets replicated. They are also encouraging people to put put full blog posts in the PDS for easy replication. So, anyone who wants to index it gets a copy and you have no control over what they do.

    You don't have to do it that way, though. You can publish your blog on your own website and just publish links to it on Bluesky.

  • Honestly that’s just as much because atproto is a raw data protocol. Putting an http frontend on an atproto account is something we encourage and a lot of folks do. I do that on pfrazee.com for instance, and my leaflet blogposts (which are canonically on atproto) render on my blog.
  • > So, anyone who wants to index it gets a copy and you have no control over what they do.

    How does this differ from scrapers hitting the blog directly?

  • This blog does a great job of explaining the architecture. In practice though I’d thought the “problem” was that Bluesky (the corporation) runs the main app and hosts almost all of the user data.

    So at the protocol level it’s decentralised, but in practice the system is still very centralised (in terms of who controls it).

    Not saying this is necessarily Bluesky’s fault, but it’s how things have played out so far right?

  • There are other apps, other user data hosting (including personal hosting), and other backend services.

    It is decentralised in both theory and practice.

    The only thing you could potentially say is that because Blue sky run the biggest parts, it's not decentralised at the community or mind share level, but that's changing.

  • Does really do a great job? It just says there are no “instances”, it doesn’t explain how the architecture circumvents all the troubles that it leads to such as auth, sync, discovery, etc.
  • The "problem" is that people are looking for problems. This "problem" isn't specific to Bluesky, ATProto, or anything else. Look at any organization: profit, non-profit, group of volunteers, etc. and you'll always find someone that folks have a problem with.

    I'm not an investor and have no conflict of interest with Bluesky beyond being one of the earliest of users. I also understand the protocol, the company, the website within my own limitations.

    The site (and app) works just fine. Folks are really focused on finding problems rather than coming up with bigger and better solutions.

    Note: the majority of folks don't want an ad-hoc p2p solution like lemmy or mastodon. they want their content in one place, and they want to be able to hold that entity accountable. Because of this, p2p social networking will never take off. I've seen more drama surrounding both Lemmy and Mastodon than I have ever seen with twitter, reddit, facebook, etc. combined.

    That's my 2 cents. Also, apparently my spouse feels the same way. So do my friends.

  • The OP's article and replies in the comments here seem like someone who's comparing an idealised view of what Bluesky could be versus a cynical view of what Mastodon currently is. This troubles me because it overlooks the massive problems with Bluesky as it currently exists. It is hyper-centralised, much more so than Mastodon ever was. Virtually all users have their data stored by Bluesky PBC, aggregated by Bluesky PBC, access it through a website and app made by Bluesky PBC, and most crucially, are subject to the moderation decisions of Bluesky PBC at every turn. And I don't think it's a stretch to call Bluesky an “instance” here.

    Now, sure, you can use a different instance for most of these services. And that instance can interoperate with Bluesky. But that's the case for Mastodon as well, and the real difference is the Fediverse has had to live with the painful compromises that come with the anarchy of the real world. I think Bluesky will discover its own version of defederation soon enough. I don't think “ah, but you technically theoretically can still interact with people even if you can't see them on your instance” is worth all that much.

  • Not much different from threads then.
  • Google Reader feels like an ominous pick for an analogy. Sure, RSS survived the Google Reader shutdown, but not all the communities that used RSS (many that still don't know what RSS is) survived.

    It feels almost "Freudian" to claim a thing is decentralized and then by analogy keep pointing to a massive (social) centralization of a decentralized ecosystem as a good thing. But especially one that we already know the ending for. Google Reader united a lot of RSS houses, value added a social graph and social commentary between them, and then at the whims of executives Google Reader fell and nearly killed RSS, but certainly destroyed an impressive social graph.

    As an analogy that doesn't give me a lot of confidence in ATProto.

  • In exchange we have many excellent RSS Reader. Just as recently someone talked about NetNewsWire.
  • Well, the whole point of atproto is that the social graph also lives in the “blogs/RSS” part. The apps just index it.

    So in this analogy, anyone would be able to bring Google Reader back to life or compete while using that same graph.

    That’s actually how http://leaflet.pub works now if you’re curious.

  • Ominous, but accurate. Imagine RSS but you couldn't use a desktop or mobile RSS reader, but only Google Reader or a comparably scaled clone.
  • ATproto sacrifices true decentralization for consistency, Mastodon and AP does the opposite, sacrifices true consistency for more accessible decentralization.

    At least that's how I understand it, because running an AP node is much more accessible to regular selfhosters than running one of those content relays in AT.

    So all you'll ever "decentralize" in AT is your own data, it's more about owning your data rather than collectively owning a part of the network.

    And we've been over this many times before on HN.

  • Mastodon also has content relays!

    But really, I actually would argue the opposite: ATproto is (or at least, wants to be) more decentralized.

    In the ActivityPub world, identity, application, and hosting are intrinsically linked. If I want to use Lemmy, I can either register a second, permanently separate ActivityPub account on that Lemmy instance, or ONLY use Lemmy to the extent my Mastodon instance knows how to send messages that Lemmy understands. EVERY new ActivityPub app is a new set of interoperability concerns, because each app owns its own identity and hosting. There's no way for my self-hosted Mastodon instance to provide an identity to a Lemmy server and then for that Lemmy server to tell that instance to host content on my behalf.

    That's the bare minimum you'd need to match ATProto, at least in the version being told to me by the ATProto people. No idea if any of it applies to actually-existing ATProto, in the same way that actually-existing ActivityPub can't interop the way ActivityPub supporters claim it can.

  • I think that’s a part of it but doesn’t state it fully.

    AT doesn’t just give consistency, but a shared data model across apps. So apps can reference and render content from other apps. It’s really kind of like a web of typed JSON. Different apps are lenses through which you can see the same network. Anyone can build new experiences on top of old data. There’s nothing remotely equivalent in AP.

    AP couples data to apps. In AT, it’s more like there’s one global database with entire world’s data that every app can query.

    I don’t understand why the discussion always bumps into Relays. Running a Relay if you want to is cheap-ish ($30/mo) these days. There’s multiple existing ones (Bluesky or community) you can use for free. And many apps don’t use one at all and rely on community indexes like Constellation (https://constellation.microcosm.blue/). Some don’t even run their own server or database.

  • I'm not sure there is such a thing as "true" decentralization :) In my mind it's more of a buffet of tradeoffs rather than a single sliding scale.

    FWIW, in the AP world there are several individuals and small teams running relays/mirrors/caches/AppViews and so on -- but you're right that this could get more expensive as things grow.

  • This is an interesting take because AtProto feels both more accessible AND more decentralized to me (at least with my current mental model).

    With ActivityPub, because running an instance requires hosting the data, the application, and dealing with all the subsequent scaling challenges, you kinda have to choose between being taking on active ops responsibilities or tying yourself to someone else's instance (which will probably be one of the bigger, more centralized ones).

    If you decide you don't like an instance you picked and decide to move (unless things have changed) you're kinda stuck needing to start fresh.

    With AtProto, it's trivial to jump ship to a different application platform and continue using your same identity. Exporting your data from a platform and self-hosting is a bit of a UX challenge, but at least it's possible.

    As an example, I recently started using Tangled for the first time and was able to login using my existing bsky-backed domain (h14h.com). No need to create a new account or pick a new username -- it was as if I were already there. Then getting set up w/ self-hosting my git repos on a VPS was an afternoon of work at most, and it's just some backend service chugging away that I almost never have to think about.

    The worst that will ever happen is I see a banner message in tangled.org saying something like "your repo is out of date and may be compatible with the latest version of Tangled", which I can solve by simply rebuilding & redeploying a docker image w/ the latest versions.

    Granted, AtProto is definitely harder to wrap your head around architecturally. But actually interfacing it with a user is much simpler, IMO.

    by h14h
  • I appreciate how this explains the difference between the two.

    But I also found it a little frustrating, because it answered one part of the question but failed to answer the question so what does ATProto do to solve the problems that instances solve?

    For example, when this article dismisses defederation as merely a mysterious reason you might not see posts from your friends, it fails to answer "so how does atproto solve the problems that defederation solves?". Because the default reasonable answer to assume, given this framing, is "it doesn't".

  • > it fails to answer "so how does atproto solve the problems that defederation solves?".

    The better way to ask this is, how does ActivityPub solve the problems that defederation causes? It's essentially the thing Microsoft does with email. Discard messages from all but the largest providers, defederate by default, forcing users to use Microsoft or another major incumbent if they want their messages to be delivered. Then new instances can't have their messages delivered, therefore can't get users. Which is obviously a perverse incentive for the major incumbents to not federate with new instances.

    It's an architectural choice that has the long-term effect of cementing an oligopoly.

    Meanwhile the claim is that it's necessary to prevent spam, but there are other providers that don't do this, e.g. in general you can deliver to Gmail as long as you have DKIM and reverse DNS etc. configured correctly, and those providers don't have any more of a spam problem than the ones who block innocent small servers by default.

    Moreover, there is an obvious way to do this without giving the major instances a perverse incentive. You do the filtering on the client so that the filter list(s) you use are provided by something in the nature of uBlock rather than something in the nature of Microsoft, since the former doesn't operate any instances and therefore isn't trying to pressure everyone to use theirs.

  • It doesn't solve those problems, except in an alternative universe where there are a very large number of appviews capable of consuming the entire firehose and you can freely choose between them and cheaply run your own. ATProto is like RSS in a universe where you can only read RSS through Google Reader (or a clone of Google Reader running on the same scale).
  • If you’re asking about moderation, it works similarly as you’d expect it to work in a everything-RSS world.

    At the hosting level, the hosting you use will likely ban you for clearly illegal stuff. Same as blogspot dot com or Cloudflare could ban you for certain things.

    At the application level, application admins/mods would moderate as any app does. This is similar to running any web service today with user generated content. It’s up to app developers to choose. Apps can also provide primitives for userland moderation, like Reddit does, or even ability to plug your own extra moderation services (which Bluesky allows). But again, this is largely how it works on any app with user-generated content.

    There’s no “defederation” because there’s no analog of “community instances” that may fight with each other. There’s hosting, there’s apps, and there’s app-level moderation that works according to each app’s developer’s choices.

    Does this help clarify it?

  • If it quacks like a duck... An account has a single Personal Data Server (PDS), right? The DID links to a PDS which is the canonical data feed for a user, and where a user's writes go. Data can be replicated but the PDS is treated as canonical. That's much closer to client/server architecture than distributed architecture. There's no P2P database. There's no writes into a DHT or peers. You write to your PDS, then those writes are optionally mirrored. Also discovery happens via DNS, so you don't even ask peers for data. You connect to a relay not as a peer but as a client asking a server for a copy of data that's canonically hosted by the PDS. I don't think it's a stretch to call the PDS an instance and the relay a mirror.