> "Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.
relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.
no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.
> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.
But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.
To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)
>To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil.
I think people aren't paying enough attention this part right here: I think the architecture of atproto creates a different set of incentives. People running communities are more likely to face community pressure to ban users, or de-federate with other communities they don't like, and your open/decentralized network fractures apart, creating little silos.
People running infrastructure connecting them to a global network/resource are less likely to feel those pressures. No one asks an email provider to ban another webmail host. The architecture colors the perception.
The biggest problem Bluesky has had is that by virtue of being the only effective relay at launch, people viewed it more like the former and less like the latter. But I think if we start to see more places like Blacksky and Eurosky get mindshare, we can shift it back.
ATproto federates in a very different way than Mastodon. There is no concept of "instances" on ATproto.
Your account is hosted on a PDS and you sign into the app with your PDS sign-in and records go to your PDS, but everything on the app is from what's called an "AppView" which provides a centralized view of all data in all PDSes so it feels just like you're using a regular centralized app. But there can be multiple AppViews and AppViews can be self-hosted.
So unlike with Mastodon, it doesn't matter what PDS "instance" you're on because the app layer is completely separate from it.
Regardless of name and precise technical details, there are central service components that can ban you. If a proper ecosystem of those ever springs up then the equivalent of fediblock (ie guilt by association) oriented at individual accounts or PDS is the next logical step. At present (last I checked) there's only (approximately) one primary provider plus blacksky making the situation even worse.
This isn't some wild hypothetical - we also see guilt by association in the matrix ecosystem.
Don’t they already have extensive block lists that you can “subscribe” to? I think some official blue sky account was added to some and they got super mad?
That's an additional (but closely related) issue. AFAIK those lists work at the user level to filter what you see, so while they aren't a network breaking "guilt by association" practice they're a form of centralized, lazy, delegated moderation that has outsized impacts on any borderline cases or false positives.
Besides those appview block lists, relays also block stuff. I know relays block stuff because bluesky isn't being sued for distributing child pornography, as it would be if it didn't block stuff.
Most bans today are at the "appview" level: the big indexed view of all the data, that combines the firehoses ("relays") marks accounts as banned & doesn't show their stuff. But the relay and the PDS still work.
Agreed that there aren't many public appviews for Bluesky posting right now, really just the two. Tangled itself though is an appview, of a different sort: one not for posting but for git issues/pr's/rtc. This appview isnt gated on Bluesky or Blacksky's permission. And folks could pretty comfortably host Tangled aplview themselves, subscribing their Tangled instance to any of the dozens of firehose/relay instances, getting all pre-filtered Tangled activity. And that really is quite decentralized a model that is imminently doable. Regarding the technical properly, the concern here about banning feels premature & naive: it assumes Tangled depends on these appviews at all, and it doesn't.
I will note that Phil's constellation project just tackles the key reverse indexing that comprises much of the appview work: taking all the firehose records, and connecting all the threads and likes together. Constellation runs ok as a public service on an rpi. There's a lot of challenges to making new appviews, but it is astounding and comforting seeing the core indexing for a sizable multi-media social network running on an rpi. What seems like a dire situation may actually be opportunity, if folks actually tried.
Whatever problems we want to foresee dooming us, whatever slopes we want to hypothesize sliding down, what we have here sounds way way better than anything else available to me today. Personally I'm much more bright blue sky sunnier about the prospects rather than your dark raincloud doom fall scare-away. The risk imo is immensely more weighted in not trying more than trying.
I'm not saying people shouldn't build things, merely disputing the idea that the logical equivalent of instances (and the ills they lead to) don't exist on ATProto. Guilt by association currently exists as a fairly common practice on all the community protocols I've made use of - including federated, p2p, and whatever else - so I see no reason to expect it won't also infect ATProto.
The key difference is that ATProto currently only has a small handful of instances, ie it remains largely centralized. Certainly it's a blessing that the operators appear to have generally acted with benevolence to date but that's not really relevant to the point I'm making.
Yeah that's why Tangled didn't go with ActivityPub (Mastodon protocol) and went with ATproto instead, which is specifically built to solve that problem, so individual servers are all aggregated by centralized AppViews (that anyone can host) that give a singular unified "view" of the network that is just as cohesive as a centralized network feels.
ATProto simply ignores the need for decentralizing incentives on a human/community level. What we get is a sort of a "top-down" federation rather than a grass-roots one. Whoever invests in the infra ends up running a domain.
I mean, practically no one is aware of any other ATPROTO provider other than Bluesky whereas the issue with AP is merely the lack of better implementations, so mastodon.social got the most attention and the hype died off with niche success.
There’s no such thing as “running a domain” or “atproto provider” in atproto. You’re approaching it with a Mastodon/AP mindset and it doesn’t match that.
In atproto, there’s two axes.
One is hosting. Bluesky offers hosting but some people host on their own (it’s just a Docker container with sqlite), some on Cloudflare, some on community-hosted nodes like https://npmx.dev and https://selfhosted.social. From app perspective it looks exactly the same way (unlike in Mastodon where “hosting” = “choosing a community”) and you can switch hosting anytime.
Another axis is apps. Apps aggregate from data from all hosts. Bluesky is an app, Tangled is an app, Leaflet is an app, Wisp is an app, Semble is an app, and so on. Those can all aggregate over the same data (which enables cross-app interop) but they don’t have to (eg Bluesky doesn’t overlap with Tangled much except that Tangled can reuse Bluesky avatar on login). Generally you don’t have people running copies of the same app (as in Mastodon) which is why there aren’t many “blueskyes”. But when someone has an incentive, they can. (Eg Blacksky is a complete fork including server and DB, allowing their own moderation decisions over same data.) Similarly you can build your own app on top of distributed Tangled data.
Hope that helps clarify why “atproto provider” as a concept doesn’t make sense. You have hosting, which is as distributed as you want, and you have apps, which anyone can make.
So does Bluesky app have control over what data it aggregates and can decide (without checking with a user) not to aggregate data from a host? I am trying to understand what are the implications for a user, and a bad scenario where one would disagree with an action of the app.
And if the answer is "yes" then at least when someone "makes their own app" can they easily use "Bluesky hosts list" + add special extra hosts (or remove specific hosts) so that the app relies on the platform, with the exception the disagreement point?
An app can choose to ignore/ban some users (or even entire hosting servers if they’re specifically created for network abuse). This is similar to how any web app may choose to ignore POST requests from spammers.
And yes, someone can decide to aggregate data themselves and provide an alternative app over same data with different moderation policies. In fact that’s already the case (Blacksky runs their own application server that mostly piggybacks on Bluesky moderation decisions but overrides some of them. There are also clients that ignore moderation altogether and show you the raw data from hosting.)
No because apps are decoupled many-to-many with hosting.
Every app can display public data from every other app because the source of truth is outside both apps (in hosting).
App owner can’t do bad things to your account other than banning you in their particular app. Other apps (even for same data) independently choose whether to show your data. So app owners are only in control over how your data is presented in their apps, not over your actual data.
Whereas in AP, each app’s moderators literally control your entire identity.
Not really. From my understanding, in AP, your account belongs to an instance and your data is then synced to other servers. If the instance goes down, your account is gone.
In ATP, your data is stored in the "Atmosphere", hosted on decentralized "Personal Data Servers" (PDS). The app then simply parses and filters that data. They can apply moderation actions by choosing not to display or read certain posts, but your data still exists and another app could choose to display it. Similarly, if the app goes down, your data is still perfectly intact in the Atmosphere.
It might then seem like the PDS is equivalent to an AP instance, but as mentioned, they are decentralized. Identity is verified through signatures, so if your PDS goes down, you can migrate to a new one as long as you have your signing keys. Therefore, the account belongs to you and not any specific server.
You're interpreting my post with the assumption that I don't know what I'm talking about. You don't need to explain the protocol to me.
Domain here referred to the area of influence or control, like what the provider of a relay effectively has. The fact that other groups can run any element of the infra themselves doesn't change the fact that the drift towards centralization is much greater with ATP than with AP.
ATP has its own uses (quick aggregation) but it doesn't even attempt to solve fundamental issues of current ecosystem of social networking,. AP, on the other hand, offers the foundation for further development in the right direction.
A new hosting provider can preemptively request known relays to crawl it. Or relays (or apps) can lazily discover it when the user hosted there tries to log in for the first time, or their data is linked to by a known user. It’s similar to the relationships between websites and search engines.
Hosting providers don’t need to discover other hosting providers. Data only flows between hosting and apps; not between hosting and hosting or apps and apps.
You completely missed the point.
The point isn't that you should find a company that you trust and think is ethical. The point is to shift the power dynamics so you don't have to trust anyone.
That's what building on ATproto does. Tangled is also fully open source and anyone can host their own knot and AppView.
I don't have a vote on whether ATProto is a good foundation to build such a thing, it seems to me rather that git has quite a bit of relevant machinery inside already, and maybe it might be extended a little, if only by convention.
but your overall point is extremely valid. lurching from garden to garden is just stupid for something so critical and core to the way software is developed. there should be a meaningful core standard for the data (the commits, PRs, workflows, etc). If people want to innovate and change on top of that great.
that's how GitHub started, but they flattered and turned the screws and convinced everyone that using them was the only viable workflow. for that matter can't we revisit the notion of a 'forge', that's really some product marketers version of how things should work and be bundled and charged for, not anything fundamental.
> Look how well that has turned out even though Bluesky is open source.
??? Bluesky can make decisions, mistakes, or moderation choices you disagree with and you can just go to https://blacksky.community, a completely independent AppView with different moderation that was up for the entirety of a 24hr outage Bluesky recently had.
Swapping one broken chair for another broken chair won’t cut it.
Development and steering is subsidised by VCs funding Bluesky at this point. (especially a crypto VC)
Have you ever asked whats in it for them?
What plans are they going to put into the protocol?
I can see the AT Protocol shoving crypto payments or whatever in their insatiable quest for growth and ROI, because when the funding money runs out when BS miss their growth targets, this is what happens.
And for Tangled’s monetisation path, it is questionable.
Do you know how many other INFINITELY LESS EXPENSIVE forms of marketing there are? Of course it's marketing, Ryan Dahl even said openly "I can justify spending money on it because it does get Deno's name out there" on Twitter.
But yeah sure this is just an evil plot to get you to use a free MIT licensed runtime or a cloud hosting provider.
Yes. Ryan Dahl has openly said this. It isn't a "gotcha" nor is it something they're hiding.
Tweet from Ryan Dahl:
> I can justify spending money on it because it does get Deno's name out there - blog posts posted to http://deno.com, etc - but without support it's pretty likely our legal bills will dwarf whatever that marketing is worth
The gotcha is them forcing the communities hand here without working with said community. It's despicable business practice and them admitting that it's mainly for show is even worse.
We gave Claude LSD, so it can browse websites and interact with them, similar to OpenAI Operator, but returning structured data from the website.
This uses the MCP (Model Context Protocol) to give Claude access to the LSD API, making it so someone can write and run an LSD SQL query without knowing anything about the language.
??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.
relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.
no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.
> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.
But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.
To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)