Anyone tracking knows that lately there is more movement on private/permissioned data. Several early proposals have been shared and Bluesky (dholms) is currently authoring the Permissioned Data Diary leading up to their draft proposal. This private/permissioned data extension requires changes to the protocol and is what I’m really getting at.
Earlier, under the second diary post on Bluesky, I had some back and forth with Daniel which left me with the feeling that they will be the ones deciding the answer to the title while we can provide some input. Since, I this question has been lurking in my mind, until Ted’s query.
I’m bringing the question here because the private/permissioned data conversations are much more durable and we get into more specifics.
What are your thoughts?
Personally, I think this goes beyond the topic de jour, and as far back as @ngerakines.me saying Lexicon v2 should be decided by the Atmosphere, not Bluesky.
Well, I think that is also my #1. My #2 would probably be moderation tooling/economics/governance, and my #3 would be DID/directory governance and the swiss nonprof.
I definitely sympathize with how, uh, centralized it feels for the protocol’s only well-capitalized platform to be designing and deciding v2 of the entire protocol, but what alternative is there, until there are additional comparably capitalized and subsidizing platforms threatening to fork/walk?
My humble suggestion for the various builders held back by not having one or more kinds of private/permissioned data is actually to keep that app-specific data OFF-protocol and NON-portable until all these governance questions are settled. I think apps should just act like platforms if they want anything not already provided by the protocol as-prototyped, i.e., if you want permissioned data… only offer it to users on your own PDSs, call everyone else a “trial user” and start building user-power that way. Otherwise, what leverage do you have? The ambiguity between apps on the bsky platform and distinct platforms sharing a protocol is what trips up all discussions of power and governance IMHO.
Doing permissioned data off protocol is off topic here (for this thread, imo)
This change is coming to the protocol, that’s what I’d like to focus the conversation on. Or rather the meta conversation about who decides those changes. There will be new protocol primitives and atproto.com lexicon. If one does permissioned data by another means, it will make the app look like it’s not sticking to the ethos or protocol.
What leverage do we have? The pen, which is why I started this thread.
meh, i think something is very wrong with the tribalist framing if people are being shamed for doing what’s in the interest of their users, or using “with us or against us” purity tests to out-group protocol contributors for working on a “candidate branch” of the protocol. without partying-in-prod (and dogfooding how it runs on your own PDSs, own appview, maybe even own relay/jetstream/cross-lexicon-tooling/etc), how can you argue that your alternate-future for the protocol “actually works”? Doing it off-protocol but in ways you think some subset of the protocol might be interested in interoperating with or supporting portability for isn’t seceding from the protocol… it’s just creating an alternate (multi-party) platform.
hard fork is the nuclear option, sure, but friendly forks (and happy users) are also just a traditional form of “in the wild” leverage in FOSS governance, where there is little formal option or obligation to take any input from anyone…
Sorry for how long this is, “If I’d have had more time I’d have written a shorter letter.” Skip to the last paragraph for the tl;dr.
Interesting question…
Obviously Bluesky has incredible weight. Their ATProto PDS is often called “the reference implementation” of an ATProto PDS. If they implement something and specify it, I think 90% or more of developers are going to treat that as “ATProto”.
Also, it seems like we don’t have any evidence that Bluesky is just going to hand over stewardship to the community?
As a builder I find that understandable to a certain extent. Too many cooks in the kitchen gets hard to deal with, and there’s a fear of design by committee. But what they have created is a protocol with a growing community of builders that are depending on it so it’s much more than just their thing now, and it is important to all of us that it satisfies our needs.
Also, there’s no formal “Atmosphere” really, right? The Atmosphere is a community, but we don’t have any formal means of managing a specification yet. We don’t have an equivalent organization that is trying to take the reigns from Bluesky PBC. To a certain extent, if we did, it wouldn’t be The Atmosphere, it would be another organization.
The Atmosphere is the ecosystem of people and tools using ATProto in my current perspective, and as such it’s not a standards body, or a group that would ratify a specification. That would fall to an organization that is merely a part of the Atmosphere.
From that perspective, Bluesky PBC is a part of the Atmosphere, too, and is currently positioned as the one that the rest of the Atmosphere is going to look to for guidance on how to implement ATProto.
Sorry, I’m kind of rambling, trying to get my thoughts out.
I guess, in summary, I think that the question boils down to the community of builders and who they are going to trust and follow.
What would happen if Bluesky PBC makes protocol changes that we, the builders, don’t feel like is good enough? We’re either going to generally let go of our concerns and build on what they have given us, or we’re going to continue building our own different things.
If we build our own different things, then there are variable levels of how much we might collaborate and start building on the same things as each-other. The more we can consolidate on shared solutions the better, but we still have to actually manage to do that.
We have to build collective trust and real solutions if we are going to guide ATProto. Right now Bluesky holds the bulk of that I think.
Maybe it’s useful to share my history with ATProto and my current plan.
I’ve been working on Roomy for a year now and for most of the time the perspective was that ATProto couldn’t do the bulk of what we needed, most obviously private data. That put us solidly on the “Off-Protocol” wagon, and ATProto was going to be primarily a login, integration, and backup solution.
Over the course of the year, with several experiments and rewrites under our belt, along with a shift away from a more p2p focus, we’re realizing that we’re agreeing with many of ATProto’s design decisions. We can actually align with it on almost everything other than private data.
We’re considering writing a custom PDS now and making Roomy spaces letgitimate ATProto repos with a custom system for implementing permissions on top so that we can have group repositories.
I’m becoming more interested in being ATProto native as we quite systematically have started aligning with the protocol, not because we had to or planned to, but because we proved to ourselves that it was a good idea.
That said, I don’t know where private data will end up, and we still have our own priorities for how it should work that may or may not line up with the rest of the builders / the protocol, so we’ll try building it ourselves, but in a way that lines up with what already exists in ATProto as much as possible.
I’m not sure if other people will like the way we’ve done it and maybe use it themselves. We’re not sure exactly what it will look like yet, because we have to test it out to see.
If the ATProto privacy spec that comes out of Bluesky doesn’t work for us, then we won’t use it for what it doesn’t work for. We’ll just say that hosting Roomy requires hosting our custom server and it can’t just use your PDS for everything, just like it already is today.
Honestly having XRPC and ATProto OAuth is maybe more important than anything else because it allows different ATProto apps to inter-operate with Roomy regardless of whether or not you have to talk to our custom appliction application server since the official PDS API isn’t sufficient.
Exactly!
I think largely we have to just keep building what we need. Sharing & talking about it with each-other, and trying to find common ground as much as we can. If we come up with an alternative private data specification on top of ATProto that we use and implement in our custom PDS implementations, then that will be how the Atmosphere decides what ATProto 2 or 3 looks like. But we’ve got to try stuff to figure it out. Start serving actual needs. Quite similar to what Bluesky did honestly.
I believe I am the only one who has actually done this so far. (Anyone know of other implementations that are largely in line with Bryan’s (bnewbold) vision?
Part of my gripe is that what I see starting to form in the data diaries is using an old permission paradigm when a newer, more efficient, what users understand from the major apps we use today… system (zanzibar/rebac vs acl/rbac) that can also represent the older systems better. This older style will not enable me to build the applications I want, or force me to do off protocol stuff, which I’m not keen to do when we could have it on protocol, as I have in my POC that modifies the official PDS.
I don’t think anyone around ATProto has designed or built a permission system before. This is why I looked to the experts rather than coming up with something on my own.
So, mostly, “the community” of people building on atproto are going to build things and then figure out what to adopt and use and interop.
The power imbalance is that the Bluesky team has funding and dedicated resources who are paid to work on protocol, as well as a large network where they can apply changes.
There are the bits at the IETF, so over time the standards work will shift in a slower, more measured process there. Reading this previous post Web Standards and the Fall of the House of Iamus (Alex Russell) – standardization comes after usage. Running code and rough consensus is the input into the standards process.
Dave Nash, Evelyn for NorthSky, Blacksky, Arushi is going to ship something with Habitat, Blaine’s work at New Public.
Lots of people are going to ship stuff that meets their needs. If you want more people using your version, you’ll want to make examples, do office hours, have some code templates, etc – just like any other code adoption.
My POC has protocol changes, so it’s not something one can just ship and ask people to try out so easily. The intention was to prototype, find rough edges, and collaborate with the people making protocol changes.
The background story… I was avidly working on this, was personally attacked by someone who I understand to be in a leadership role within the atmo (not bsky), lost motivation, and am now trying to evaluate whether it is worth picking that work back up.
How does realpolitik play into these efforts around permissioned data and protocol changes?
Is it something that you can somehow make work just for your app, even if people login with their own PDSes?
It does seem like at this point options are either try to talk Blusky into doing what we want, or prove that what we want works by making an app that people will use with it.
Very valid point, and yes, I do have a couple of apps that are not quite POC, and would be limited in demonstration because the majority of accounts (PDSes) would not support it (can use proxy and group accounts). I’m trying to gauge whether it’s worth the effort if Bluesky is going to do something else. Maintaining credible exit is important to me, one reason why I moved to the on-protocol approach after implementing a first pass off-protocol. It’s also simpler on-protocol.
I mean … I haven’t had the motivation to wrangle regular meetings and such in part because everyone is pretty far from consensus or desire to work together on a common approach or codebase.
I see a lot of people learning by doing - what works for their needs, trying to build something, learning what works and what doesn’t and what the challenges are.
To your point: “this needs protocol changes” - my one ah ha from Montreal is that maybe additional service endpoints in DID docs is a way to do incremental roll out.
So: yes outreach to come to consensus and have others adopt a solution is something that can’t be skipped. Does that answer realpolitik?
The other OTHER thing that I had personally wanted to do was/is to raise grant funding across multiple orgs so that at least the power imbalance of paid work vs unpaid work on protocol pieces could be improved.
+1, huge fan of that approach. Evelyn and Nick have both proposed this for two different kinds of permissioned data. Personally I think the DID system is “beneath” the protocol and that makes it a natural extension point for opt-in extensions (and, thus, a natural mechanism for platform-building, allowing smooth interop and portability between, e.g., all the Northsky-style PDSs)
Oof, i’m really sorry to hear that, I hope I didn’t come across as too hostile earlier. “Leadership roles” and community soft power are probably an anti-pattern, particularly if it’s IETF rules (running code first, rough consensus second) people are trying to organize around.
rest assured it is not about you, we have different perspectives and opinions, but how you say it is much better than the unnamed incident (because I don’t want to call that person out)
We definitely have that evidence. Bluesky and others in the community have been actively working on moving the protocolinto the IETF over the last year or more. It’s a slow, long term process, but it bends toward real standardization, in a real standards body.
Yeah, it seems like the IETF stuff is more for long term stewardship and not short-term development & experimentation, though?
From what I’ve seen / heard it seems like they are mostly on the side of, “we’ll make the protocol changes and get feedback from the community”, and then those changes that they’ve already deployed are what is possibly candidate for the IETF.
I could definitely be wrong about that.
It seems like the risk @verdverm.com is feeling is that we don’t get the proper input early on in the process, so that what ends up candidate for community stewardship in the first place will be incomplete.
“Pave the cowpaths” is definitely a good, useful way to make standards! Standards bodies are generally bureaucratic and slow (ish), by design, so people often experiment and cook outside them, where they can move faster, and then the standards body incorporates wherever those people land.
However, the point of any standards body worth its salt is a well-defined process for what can get standardized, and how, and from whom, and that generally includes anyone in the community who joins and follows a few rules. Not a single company or org, even if they may have created the standard originally.
Exactly!
