111–120 of 157 posts
Earlier quoted context omitted.
They use AT command set, not protocol.
... which is a protocol, thus pre-existing colloquial use of "AT protocol" that makes this trademark questionable.
Earlier quoted context omitted.
I think you will find that a lot of people find that to be a feature of the federated networks. It's how society works outside of social networks. You aren't likely to see football fans of different teams sharing pubs here in Europe. You wouldn't see judgemental people be allowed in accepting roleplaying communities and so on. Why would a network of community controlled servers be any different than this? IRC was lik…
Email and Usenet are both decentralized systems that in theory aren't affected by instance admin bitchfights anywhere near to the level of drama in the fediverse. Yes: many providers didn't mirror the binary groups due to piracy, and in email, deliverability is a constant issue thanks to spammers. But the fediverse? Can't count how many times I've seen instance admins hold their users hostage in bitchfights over the…
Email is probably the closest to anarchy. If you could get people to use it for group communications, every user could decide who they include in their "reply all", which would probably lead to absolute chaos.
Earlier quoted context omitted.
Sure you can host your PDS, but if you want to deploy your own instance like you would do with Mastodon, you need to deploy a Relay and an AppView as well. And the way the network works, you need beefy servers for that. On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine ( https://ab…
The idea of an 'instance' is not really clear. If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve. If you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up…
Note those are not heavy requirements in any atproto-specific sense.
Running an atproto relay (at the current scale) is $30/month. If you're running a popular app, this is probably comparable with some of your SaaS subscriptions. Or you could use a community-run one or pool resources with other apps. Also, many atproto apps don't use a relay at all, and rely on a community cache like https://constellation.microcosm.blue/ instead.
Running an AppView is only as expensive as running any backend. "AppViews are expensive" is a myth extrapolated from "Running a copy of a Bluesky AppView is expensive", which is true because a Bluesky AppView is a backend server that's supposed to store and serve millions of posts. It would be expensive with any technology! Atproto isn't adding an extra tax here. Running a centralized service at the same scale would be equally expensive, and a Mastodon instance at that scale would simply not run.
If your AppView only serves your app's users (and has nothing to do with Bluesky), the cost is cheap or nonexistent. It's just a normal backend that listens to a websocket stream and writes some stuff to a database.
Cool people use ActivityPub. Single vendor owned & controlled standards always turn out badly, just a question when.
>Cool people use ActivityPub. ActivityPub solves a completely different (arguably, smaller) set of problems. This is like saying "Cool people use email instead of web". I have a few diagrams here that may help see just how different they are: https://overreacted.io/there-are-no-instances-in-atproto/#so... >Single vendor owned & controlled standards always turn out badly, just a question when. Yeah, which is why atpro…
Cool people use ActivityPub. Single vendor owned & controlled standards always turn out badly, just a question when.
Earlier quoted context omitted.
The idea of an 'instance' is not really clear. If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve. If you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up…
>If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve. Note those are not heavy requirements in any atproto-specific sense. Running an atproto relay (at the current scale) is $30/month. If you're running a popular app, this is probably comparable with some…
Earlier quoted context omitted.
> I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration. This is exactly where I’ve landed re: ATProto. If you actually want to self-host everything you lose one of the biggest draws of it, the migratable IDs. I was looking into it to build an alternative to Threads/IG/TikTok for one of my hobby co…
I don't know what you mean by this. You absolutely can self-host all your data on your own. And if you also don't want to rely on PLC for identity, you make a `did:web` identity, and then you're completely decoupled from Bluesky-operated infra.
If I host AT Proto infra for my community and want to give people . accounts, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID. did:web does not provide the same UX as did:plc
From the post I was responding to:
> Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?
>
> Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)
Earlier quoted context omitted.
That is not the point. The point is that without talking with Bluesky, you cannot start your own ATProto product or you'll get throttled from the network.
Tons of people have started products without issue. But if you flood a popular relay with data that exceeds its rate limit then getting throttled is to be expected. This doesn’t prevent your participation in the protocol or network. There are other relays and indexes out there that may have different rate limits. That’s just how these things work. The data from W is still there on their PDS, still public, still crawl…
Earlier quoted context omitted.
I don't know what you mean by this. You absolutely can self-host all your data on your own. And if you also don't want to rely on PLC for identity, you make a `did:web` identity, and then you're completely decoupled from Bluesky-operated infra.
Dan my concern is explicitly that did:web is not the same experience for users as a did:plc. If I host AT Proto infra for my community and want to give people . accounts, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID. did:web does not provide the same UX as did:plc From t…
I was replying to this:
>not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.
I'm saying I don't know what this means. You can fully self-host with `did:web`. Yes, it's unfortunate that you've already made an account by the time you've realized that. I think that's still different from "not being able to self host".
Unless I'm just parsing what you wrote incorrectly, which is quite possible!
Chiming in to say as the CEO of Blacksky that not only do we have an independent AT Protocol implementation in Rust ( https://github.com/blacksky-algorithms/rsky ) Not only do we run a fully independent stack ( https://docs.blacksky.community/readme/list-of-our-services ) Not only are we getting paid by other orgs to stand up independent app view servers. We also received a license from Bluesky for the atproto tradem…
But the argument that established, profitable organizations in the atproto space have no qualms with this move is not as reassuring as you might think.