bryan newbold

dweb, cycling, free software, snow, wiki, hardware, big cities, symbolic systems. I love speculating about found objects.
Working at https://blueskyweb.xyz/ on atproto (a federated social media protocol). Formerly built https://scholar.archive.org; scientific instrumentation for observational cosmology; open hardware
#seattle

Personal Site: https://bnewbold.net
keytrace: did:plc:44ybard66vv44zksje25o7dz

Last Notes

2025-03-20 18:59:12 UTC

- reply

just drove through that area yesterday, it is so great.
also thinking about how it is kind of the northern terminus of "highways/roads mostly along the Pacific coast" all the way from the mexican border (at least)

2024-11-27 00:35:29 UTC

wrote up a reply to @npub1urx…v0z4's "How decentralized is Bluesky really" blog post:
https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t

2024-11-25 04:48:39 UTC

- reply

this was not intention, and my understanding is that new content has been flowing. we had a serious incident on 2024-11-21 (last thursday) which has impacted some posts getting indexed from that day. we then had a clog catching up bridgyfed because of a misconfiguration.
we very much prioritize interoperability with bridgy fed and have been in communication with snarfed throughout.

2024-11-02 21:08:34 UTC

I think what many folks really want from "federation" is a situation where no one party has more than 40% (or 10%, or whatever) of the network.
That is a powerful and special property! Fediverse has it today, and most networks don't.
It is different from adversarial interop though. There are open systems, like email (gmail) and git (github) which have sort of lost this. I still think the interop in those systems is valuable.

2024-11-02 20:50:41 UTC

- reply

yes!
moreover, those 100k followers would probably not even realize you changed service providers. you can use your own domain (which you own) as a handle. the authority for your content is you, not the service provider, so all your old content (in threads, interactions) continue to just work.

2024-11-02 18:53:58 UTC

- reply

it is confusing to read this because we have done basically everything you propose in the AT Protocol, and it has been live in the network for a long time now. ensuring that service migration is easy and seamless is literally one of the reasons we did *not* use ActivityPub.
You can read how easy the process is here:
https://whtwnd.com/bnewbold.net/entries/Migrating%20PDS%20Account%20with%20%60goat%60
On, I would mention, and independently run blogging service built on atproto! which bsky can't exclude/control

2024-10-31 19:30:11 UTC

- reply

We have brought some of our work to the W3C community, including the recent TPAC meeting:
https://social.coop/@bnewbold/113199431948755006
I've had a Bluesky-affiliated W3C account for some time, and just joined the SocialCG just now (I thought I had done this previously, but apparently had only signed up for the mailing list)

2024-10-24 16:40:58 UTC

bluesky got more funding, and is working on several sustainable revenue models: subscriptions, domain registration, and payments.
work continues on atproto: tooling for independent Lexicon development; more docs/specs and testing for interop; more complete and documented SDKs
https://bsky.social/about/blog/10-24-2024-series-a
#bluesky #atproto

2024-10-14 08:03:23 UTC

- reply

to respond to your earlier request to have it be more obvious to opt-in in the bluesky-developed app: I think i'd probably encourage the bridge to just be opt-out on the AT side? we generally want to encourage projects like the bridge to be opt-out; having an opt-in flow in-app sets an implicit norm and expectation

2024-10-14 07:53:20 UTC

- reply

we got put on a number of AP-side instance blocklists before bridgy fed even existed, and the bridge has been controversial on many instances (including mine!). overall, kind of a spicy situation to wade in to aggressively.
we certainly support and encourage bridges, and interop and collaboration generally!

2024-10-14 07:50:33 UTC

- reply

from a policy perspective (not official guidance), I think bsky would probably be fine having a bridge being opt-out vs opt-in, if responsibly done (as bridgy fed has been in general).
fedidb says about 36k AT -> AP accounts. our relay says about 25k AP -> AT accounts.
I'd be curious about total threads federation numbers.

2024-10-14 07:43:19 UTC

- reply

this is a pretty interesting request!
one of the big critiques of bsky/atproto is that it is too centralized / single-org. the bridge(s) being independent is nice in some ways, right?
I haven't done formal estimates, but my understanding is that AP is resource intensive at scale. it would be pretty hard (compute/servers) to do all the inbox/outbox for, say, millions of accounts on AP side.

2024-10-02 17:40:24 UTC

wrote up a proposal for exposing "moderation history" back to individual accounts as part of Ozone, an atproto moderation system.
I think that the Mastodon reporting system already has similar functionality, but not sure about other ActivityPub project. Curious for feedback!
https://github.com/bluesky-social/proposals/tree/main/0005-mod-history
#atproto #bluesky #moderation

2024-09-18 22:03:07 UTC

- reply

even if folks don't trust Jay and the Bluesky board (who are the relevant individuals and stakeholders-holders for the future of the org), we are working in the open and everybody can read and learn from our experiments, successes, and failures. We totally endorse inter-operation efforts like bridgy fed, and collaboration on overlapping needs like identity systems, OAuth, and E2EE.

2024-09-18 21:57:18 UTC

- reply

bummed that you have such a negative public take on atproto and Bluesky and see it as antagonistic and "dangerous".
I have a huge respect for ActivityPub and the folks involved, including you. I think we are all working towards the same goals, there is no final word on protocols/architecture/governance/regulation in this space, and that there is a lot of room for collaboration.

2024-09-11 00:54:53 UTC

really excited about this tutorial we put out last week describing how to build a minimal non-bsky app on atproto: "Statusphere"
https://atproto.com/guides/applications
https://github.com/bluesky-social/statusphere-example-app
there are a lot of questions (and options!) about how cross-app data+interaction will work in atproto, but at a minimum I think the protocol is quite solid for building new apps/modalities, and excited to finally demonstrate it!

2024-08-20 20:29:00 UTC

is adversarial interoperability a goal for the ActivityPub/Mastodon ecosystem?
how does it interact with opt-in culture/expectations?