Scott
banner
scott.nstar.social
Scott
@scott.nstar.social
Co-founder @ nstar.social – A decentralized, local-first social network on the @ATProtocol keeping users in control of their data. Private beta soon!

A decentralized social internet restores user agency over billionaire self-serving walled gardens.
You’re not alone. Nothing is ever free. Feels like a trojan horse. There’s always a price to be paid. Investors always seek a return. Big social platforms concentrated wealth & undermined democracies around the world. Our data in #ATproto is publicly available for “free”. Is this the investment? 🤔
November 15, 2025 at 3:57 PM
Fair enough. Hopefully some use-cases can materialize that can shed more light on these approaches.
November 13, 2025 at 7:58 PM
Ok. What might the ability to swap out a Bluesky-compliant AppView through the "atproto-proxy" setting look like in Option 2?

To be honest, its pretty elegant/clever for user choice to swap to a different AppView, like Blacksky, through a simple client app setting. No changes to the client app.
November 13, 2025 at 7:47 PM
Trying to understand where this leads. Are you planning to deprecate Option 1 or 2 in favor of just one? Or, will both options continue to exist but one might be more geared toward removing the specialization Bluesky has baked into the PDS? Does a PDS become nothing more than a Solid alternative?
November 13, 2025 at 7:21 PM
Extending the lexicon to a set of additional standards might be something worth considering. The pds could then negotiate additional optional behavior with any appviews/servers based on lexicon definition that is not hardcoded. Standards are what will ensure Atproto stays decentralized & survives.
November 13, 2025 at 6:33 PM
Isn't this the whole point of the lexicons for data, queries and procedures...to provide a contract for portability and method abstraction/definition?
November 13, 2025 at 5:55 PM
This isn't an either/or equation & that there is an architectural solution that can be achieved to offer both options. Decentralized architectures & abstraction are hard but not impossible. Let's not throw out a core value ATproto provides w/ data portability. Why is this even a discussion?
November 13, 2025 at 5:49 PM
Agreed. Option 1 is far more powerful IMO and the cornerstone that makes ATProto compelling as a decentralized protocol for data autonomy.
November 13, 2025 at 5:44 AM
Option 1 lends better to decentralization.

Option 2 centralizes and forces lock-in to an app provider.

Keep both. Flexibility offers innovation.

Otherwise, my vote is for Option 1.
November 13, 2025 at 5:36 AM
“and not in a way benefits the masses.”
November 8, 2025 at 9:30 PM
There’s a reason these platforms remain “free.” These actors are concentrating extreme wealth to reshape society…and not in a way that does not benefit the masses.
November 8, 2025 at 9:29 PM
The monetization & political exploit of our social interactions is a major cause for the erosion of democracies around the world. People need to be more concerned how these platforms continue to manipulate society & generate extreme wealth to our collective detriment…
November 8, 2025 at 9:26 PM
Mundus Sine Caesaribus
October 18, 2025 at 1:02 AM
My experience is the PLC requires an “atproto_pds” service. And things get wonky when the “alsoKnownAs” doesn’t have an “at:” handle.
October 13, 2025 at 7:28 PM
It’s unrealistic to believe a single PDS would store the entire data for a user (aka DID). Limits are one reason; there are many others. We can’t predict all the future innovative solutions on the ATProtocol that may require a newer PDS or a specialized PDS.
October 13, 2025 at 7:22 PM
Very good question. Rejecting non-Bluesky schemas would contradict the current ATProtocol architecture which limits a single user DID to one PDS. I’ve raised this artificial and unnecessary limitation as a concern. One DID to one PDS is contradictory to achieving full decentralization. It’s silly.
October 13, 2025 at 7:10 PM
Do you know why a configurable client is an issue for Apple and Google? I’ll dig into their guidelines but by chance do you know the general vicinity to look?
October 10, 2025 at 1:55 AM
Correct. You set the atproto-proxy to an Bsky-compliant AppView Api / Lexicon did:web. I performed this POC a few weeks ago successfully when Zeppelin was still available. Demonstrates the power of the decentralized architecture.
October 10, 2025 at 1:50 AM
Btw…our upcoming NorthStar Social app under development has an option to configure the AppView of choice. We tested it with Zeppelin when it was still functioning. Works great!
October 9, 2025 at 5:50 PM
There needs to be a registry for these various ATProtocol host-able components (pds, relay, appview, etc) that providers can opt-in and client applications can subscribe for programmatic discovery to offer options for end-users.
October 9, 2025 at 5:47 PM