Well, I really appreciate the kind words. I think the atproto dev community in its entirety is full of good people who care quite a bit, and we all know something like this is a big project that we have to earn, so we're doing everything we can to make it happen. It's hard work but it's rewarding, and it's certainly nice to hear something like this. I'll be sure to pass it along.
Luke's feedback on the permissioned data proposal is pretty interesting. The current proposal has a kind of locational element to permissions, where a record's URI reflects the access control, and I can understand why that would be jarring. I'm talking with the team about whether we think that's something that could change, and what a change like that would cost. We're still in the collecting feedback phase so it's good to hear how it hits people.
Regarding his other concern, I would've loved to make atproto a localfirst protocol -- that's the field the atproto team came from -- but we had to pick & choose where to spend our complexity budget. I wouldn't say it's a nonstarter for the ecosystem; you can use something like iroh in conjuction with atproto to share identities -- dial people at their dids or domain names -- and then commit state to the atproto repo once it's ready to leave your local sync mesh. Maybe that sort of thing makes its way into future versions of the protocol. But, engineering often involves trades, and for the v1 that was one of the trades we had to make.
> Bluesky recently acquired the rights to the trademark for “ATPROTOCOL” and its variants—including “AT Protocol” and “atproto”—from another company that was threatening to take legal action preventing the company and others from using the term. Now that Bluesky owns it, the atproto community’s continued use of the mark can be protected.
The policy around usage is shared in the rest of the post but the goal is to make this very simple for everyone
I’d also call out that activitypub has the same threat model in the form of ICANN, as it’s also heavily dependent on DNS for identity. I believe these are reasonable trades to make; realistically the alternative is to use a blockchain, which few people are keen to do.
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.
Relays are actually quite cheap now! They used to be a bit more expensive when they archived all the traffic, but in sync 1.1 that was dropped and they can be run on $20/mo VMs pretty trivially now
The public side is extremely important for agents though. Agents need up to date public information to do their job. Every other service is going closed. Public information and activity should be a commons.
Yeah I’ve met the Radicle people a couple times. I’ve never given it a thorough review but, for their goals, their designs have always seemed strong, and they’re pleasant people to chat with.
The main difference was atproto wanted to tackle scale, so we went with a servers & aggregation model. Radicle is going for device-to-device networking as a primary goal.
Yeah the problems they seemed to have were over collaborative data structures with permissions. You’re right about how atproto solves that, which means you’re using CRDTs if you need to collaborate. If that’s a fit mismatch, I’d tell people to just appoint api servers which wrap a repo and provide the needed semantics.