@glyph great post! I strongly agree with your framing and "best possible future"

@pluralistic that is still the situation: there is not a serious peer service provider operating those services in the network for the microblogging modality.

there is nothing preventing it: we support adversarial interop in the live network today, but no "adversary" has emerged.

hobbyists have run full-scale components as proofs of concept. there are fully independent apps (like smokesignals and whtwnd), and independent projects which index/store the full network (like clearsky)

@joakimfors @pluralistic yes, there can be many independent relays in play, and all interactions continue to work.

conceptually, relays are many-to-many: users/PDS didn't really "choose" a specific relay; all full-network relays crawl the whole network and are interchangeable. other services can make use of multiple relays for redundancy

@cwebber @stefan
for what it is worth, have always found your writing and critique on all this very insightful and productive!

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.

@pluralistic 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.

@pluralistic there are probably things we can communicate better, and some clarifying demos or signaling we could do. "federation" is a loaded term right now with a bunch of ActivityPub connotation, maybe the type of anti-exclusion / anti-enclosure we have built needs a new name.

Look forward to seeing you at the CoNEXT workshop on decentralization at UCLA in December, maybe we can discuss then.

@pluralistic I think the biggest reason is that it is a bunch of work just to prove a point. folks who love administering Linux systems are already running Mastodon instances; there is some path-history involved.

The main thing we are focused on right now is enabling folks to build entirely *new* applications on the protocol, which is much more fun, and many more folks are doing that. thread here:
https://bsky.app/profile/bnewbold.net/post/3l6pz5fhrv72j

@pluralistic you say that we haven't "added the federation systems that would enable freedom of exit to its service". we have done that. what I think you *really* want is a peer running actual competitive alternatives for each component. That is similar, but different!

If it is possibly, why isn't anybody doing it? That is a great question! we have theories, and have done a lot already to encourage it (open code, open protocol, docs, etc)

@pluralistic 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

@chadkoh @pluralistic oh, no way! very excited Doctorow will be there.

I'm a co-author with Martin and will probably be the person traveling down and presenting in person.

@hallenbeck @evan

other folks have raised similar concerns in the past. you can see an open and and collaborative conversation from October 2023, resulting in license changes in November 2023:
https://github.com/bluesky-social/atproto-website/issues/218

@evan @hallenbeck
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)

@evan @mmasnick I would be more than happy to talk with folks from SWF or W3C if they share this specific concern about Bluesky exploiting patents on social web technology, and what we can do to allay those concerns.

The norm in this space is to participate in a standards body, and it remains our intention to do so.

@evan @mmasnick when you raised patent concerns to me in person on March 2024, I took them very seriously! which is why I reached out and had a direct call with you about your concerns that same month.

"Right now, you're putting everyone in the space at risk" is a strong statement and accusation of wrong doing on our behalf.

@evan @mmasnick Evan, as you and I have discussed directly in the past, all of the atproto specifications and core implementations are under free and open licenses. Specifically, MIT and Apache 2.0 dual-licensing, with Apache 2.0 providing patent protection. Furthermore, Patents have public record, and anybody can confirm we have not filed for any.

Neither you nor I are lawyers, but I don't think there are any grounds to spread fear/uncertainty/doubt about atproto and patents.

@darius cool! I didn't dig in too deeply, so maybe you cover this, but a related helpful feature/tool might be knowing which software (libraries, implementations) would be able to parse data/schemas. getting in to https://caniuse.com/ territory, or things like ACID.

also often helpful if folks (eg, devs) can paste in data (JSON) and see how it validates, using the exact code being used to "observe", without that being captured and included in database.

@jdp23 @jonny multiple AppViews

@jdp23 @jonny even alt bsky apps like greysky and deck.blue, which mostly build on the bluesky appview/API, have their own server infra for extra features. this broad pattern is sometimes called "backend for frontend", and we expect it to be more common, complementing the current pattern where clients directly connect to PDS. the "stausphere" demo app demonstrates it

@jdp23 @jonny we basically see client apps and appviews as entwined (hence the name). a big app would run their own appview. the difference from platforms like reddit or Twitter is that they *can* do this, because all the public data is open, from the PDS instances (if you are building a big appview, you probably just run your own relay as well; and a CDN)