Notices by bryan newbold (bnewbold@social.coop)

@cwebber some other comments from atproto thread are bridged here:

https://social.coop/@bnewbold.net@bsky.brid.gy/113648434828862415

@cwebber thanks for the reply!

really happy for use to have these back-and-forth blog posts as an artifact. it sounds like it took a lot of time on your end, and I know it did on mine as well, but doing it "in the thick of things" made it real and memorable.

I read the whole blog reply, but likely won't read the full summary thread (different media!).

I'm not planning to do a full-length blog reply, but will post a couple quick comments here. and do hope to "be in conversation" going forward.

@cwebber thanks!

I agree don't want to go around forever on atproto / ActivityPub specifically. Hope we (and broader community) can get to some deeper writing on other systems, like Spritely, OCAPs, Willow/Leaf, etc.

@guyjantic @cwebber
I think trying to have a social web without full indices is like having scholarship without research libraries (or WorldCat/OCLC, or Library of Congress). you can do a lot of good work without those things! but the utility of indices for discovery is pretty large.

wrote up a reply to @cwebber's "How decentralized is Bluesky really" blog post:

https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t

@Hyolobrika @nemobis @cwebber in the client app; labeler gets sent as HTTP header on every request

@wordshaper @mcc @cwebber "p2p" is not really a design goal for us.

the architecture of atproto has helped a bit with scaling at times (we have dozens of PDS instances, and can spin them up on any provider), but can also lead to weird/unexpected degradation patterns ("invalid handle" due to BGP glitches, notifications not being sync'd). it made early development very slow, and it takes a bit longer to train new employees.

several of the core team accounts are on indie PDS instances

@nemobis @cwebber I think this conversation really gets at a difference in approach. we (Bluesky) are trying to migrate mass numbers of users off incumbent centralized platforms into alternatives with "credible exit" and interoperation. we want to make that as seamless and low-friction as possible, and asking folks to change expectations and behavior *at the same time* cuts against that.

can see this w/ quote posts, interaction counts, recommendation feeds, etc

@nemobis @cwebber I plan to get in to this more in a longer response to Christine's blog post, but a design goal for atproto is to have "no compromises" compared to a centralized platform. we don't want to try and convince/educate users that they don't "need" consistent and complete views of public conversations (or accurate "counts", or low-latency notifications, etc)

@cwebber @laurenshof I'm sympathetic to Laruens' focus on real issues, but I think the link preview fetching phenomena isn't super baked-in to AP-the-protocol and could be "solved" in isolation.

eg, would be easy to do it the way bsky does it (author populates), though that has it's own issues/controversy.

@cwebber I'm interested to do more big-O comparisons as well.

for a large reply thread, say a thousand actively replying users on hundreds of separate instances, the number of AP messages that need to be rapidly distributed to assemble complete reply-thread view on each instance is pretty huge, no? N^2? and then also fan-out to followers?

each also needs to fetch/render media and social cards (O(instances)). and that doesn't cover *viewers* distinct from participants/followers.

@cwebber I've read the whole blog post now, and it is solid! sheds light, good framing, gets to the good stuff.

thank you / congrats!

planning to reply in longer form soon

@nemobis atproto relays currently mirror only "records", not media blobs, so size isn't too crazy.

we think a degree of duplication and mirroring is good/healthy for the network. similar to having multiple copies of git repo checkouts. but a few dozen full network copies is probably plenty?

resource/climate-wise, what we see in our infra is that "reverse chron" timelines, and to some degree notification tracking, are expensive (much more than relay). ironically "algo feeds" are cheaper?

@nemobis at least for us, now, at current scale, for the bsky app, "reads" are more expensive (in kilowatts and silicon) than "writes". I don't think this would be particularly more efficient if network distributed the load more to many smaller nodes (vs having big API servers).

it is possible to "shard" parts of network for things like search queries. https://yacy.net/ might be relevant. I don't think that helps with efficiency though?

@cwebber @Claire @eramdam
I think a bunch about this post about the history of mp3 piracy and "minimum viable decentralization":
https://web.archive.org/web/20180725200137/https://medium.com/@jbackus/resistant-protocols-how-decentralization-evolves-2f9538832ada

(though it wasn't directly influential on atproto design, and Backus has since pulled the post)

@Claire @drq @cwebber the architecture of atproto kind of presumes that there is value/utility in "full world" indices: ability to search and find strangers with no social-graph-connection across the network.

I don't think all (or even much at all) social web stuff needs to end up in that bucket! but that bucket is going to exist in the world and have an impact. I love the AP social outcomes, but if AP doesn't provide for big-world broadcast, Twitter will continue to have a role in society

@cwebber @Claire @eramdam don't think the goal w/ atproto is to be "more decentralized" in the abstract. we (team) had worked on SSB and dat, which were radically decentralized/p2p but hard to work with and grow. would not supplant "the platforms".

atproto came out of identifying the *minimum* necessary decentralization properties, and ensuring those are strongly locked in. we basically settled on:

@cwebber @Claire @eramdam
unbundling and composition: ability to swap components w/o swapping full stack.

credible exit: ability for new interoperable providers to enter network. public data must be accessible w/o permission, and schemas/APIs declared

control identity: whole network/proto doesn't need to be individualist, but identity is personal

easy to build new apps: don't build for the old modalities, enable new modalities. accomodate opinionated devs.

@cwebber @Claire @eramdam I have a longer post on this, and our progress, on my personal blog:
https://bnewbold.net/2024/atproto_progress/

after the 2016 Trump election, there was a big movement to preserve government data and websites (EDGI: https://envirodatagov.org/).

I wasn't around for that, but I think there was a missed connection between web archive world and volunteer/movement world.

if similar efforts spring up in coming months, would love to help make connections between worlds!