Modeling communities on permissioned data

Working Groups WG Private Data
1

Discussion space for the questions I brought up in this leaflet: Modeling communities on permissioned data - Daniel's Leaflets

Please let me know your thoughts/suggestions or if there are previous discussions around this that I might have mised

6 Likes
2

Hey Daniel! Sashank from Habitat here. We’ve slightly pivoted since we talked at AtmosphereConf away from the local-first stuff to focusing on data ownership for organizations (more detailed blog). Basically, we’re thinking that members of an organization (like a company or university) will get an identity on a PDS (or maybe an “organization data server”) managed by the organization. That way, the organization admin can apply policies on data access to approved apps and between org members. We’ve been playing around with our own implementation of spaces based on the existing proposal to prototype this.

This model actually answers both of the questions you posed in the blog post for our use case. Regarding scopes, admins grant approved apps access to all the spaces on behalf of the entire org. The app just needs to declare space types that they’re interested in. (side note: this also makes syncing easier for apps since they can use the admin granted credential to access all member spaces). Regarding who runs the arbiter, the org data server comes to the rescue again as the definitive source of truth for space membership policies.

We’ve been discussing with the Roomy folks on interoperable membership policies. Habitat intends to have fine grained permission models to support the wide variety of permissioned data use cases. However, we intend to track this state as records themselves (maybe within the spaces they control permissions for) so that they are migratable. Enforcing the semantics of the permission state will be the responsibility of the space host. The hope is that standardized lexicons will emerge around permission models that all space hosts can implement. We’re working on a proposal for one such permission model lexicon.

We’re excited to see the progress on spaces and can’t wait for it to be set in stone! Also very interested in continuing discussions so that our approach slots nicely into the atproto ecosystem.

4 Likes
3

A quick thought, no need to shy away from a managed account interface on the PDS! Tranquil does this today. I can see that being a useful primitive for lots of purposes, so setting that as an expectation for PDS implementations might not be so bad.

4 Likes
4

Thanks for sharing @dholms.xyz! These are really good questions.

A conditional, cross modality scope?

This is tricky. Just kind of thinking out-loud, I see two aspects to it:

  1. The scope request that the app makes
  2. The consent screen that the PDS shows

I think it’s interesting that, while we do want a standard, it’s possible to change the consent screen, and have the PDS give somewhat more or less permission than exactly what was asked for, without changing the scope request itself.

I’m just thinking that does give us a little bit of freedom to experiment with dynamic consent screens. :thinking:

Picture an “authoirty-picker”, kinda like the iOS photo-picker, where the user explicitly picks which communities an app sees across modalities.

I kind of like this idea. It feels similar to me picking which GitHub repos I’m granting access to when I connect my GitHub account to a cloud provider.

I think it would be great if the scope request could have semi-flexible “hints” that the consent screen could read from to determine which spaces to show by default.

I’m not sure how sophisticated the scope hints would need to be to capture this particular use-case. Just brainstorming possible scopes:

  • community:did:plc:abc1234: Request access to all spaces of particular community
  • type:app.bsky.group: Request access to all spaces of a particular type in any community.
  • community:*: Request access to everything - all spaces of all communities
  • type:* This would also be access to everything.
  • type:app.bsky.group community:*: Request access to all communities that have an app.bsky.group space???

I don’t think that’s quite right because scopes should be additive, where having multiple scopes in this case actually hints at a lessening the access.

Just own up to the limitation. And say that if you want notifications to surface in the Bluesky app, then they need to be published in the Bluesky space. This doesn’t necessarily mean publishing the thing itself in the Bluesky space. Rather you could publish a pointer/envelope to the thing in the Bluesky space.

That definitely could work. And it’s similar to what I was imagining for cases where you want data in permissioned spaces announced on the firehose.

But I do feel like giving the user more control over what they grant an app access to is probably something we are going to need at some point anyway, so I lean towards the more sophisticated consent screen.

:thinking: That does lead me to another thought, though.

Adding Apps As Members of Spaces

An interesting thought is that if the community wanted to, they could add the Bluesky app as a member of the space.

Whether this is appropriate is obviously going to depend a lot on the nature / social norms of the community, but it would give the Bluesky app full access to the space without requiring consent from the members individually.

Who runs an arbiter & who hosts a community?

I do think that having the apps run the arbiter is pretty reasonable.

How do users manage the complexity of the communities they own getting scattered across a bunch of different apps?

I think the good news here is that the community’s handle / DID resolves to the arbiter so it’s not like you can “lose” it. I think there are a couple possible scenarios for managing your community:

  1. You can manage the community in multiple different apps because those apps support the standardized management XRPC API.
  2. The app you are in doesn’t support the management API for your arbiter, so it has to redirect you to an app that does.

In scenario 2, maybe the arbiter itself has a generic UI that can be redirected to, or maybe there’s a “managing app” endpoint standard so that apps know where to send you to manage a community, and it could usually send you to the app that created the community in the first place.

Scenario 1 is ideal, if it’s possible to standardize on, but I think that could be difficult.

This is related to being able to migrate between arbiters, which I agree is crucial.

I drafted some lexicons that were meant to be the standardized API for scenario 1:

In summary:

  • Have all arbiters provide the same ( base ) XRPC API.
  • Standardize on a minimal concept of members and spaces.
  • Allow spaces and membership to carry custom metadata
  • Apps and arbiter migrations will be able to read all the data.
  • Understanding the metadata lexicons is optional, but necessary to make informed modifications.

I think even if this doesn’t pan out, just having to go to the app that you created a community in to manage it wouldn’t be horrible. I would really love to have communities be meaningfully interoperable between apps, but I think that may have to be worked out similar to lexicons.

Starting out communities may not interoperate across apps for a bit, until we find the lexicons that we start the converge on.

Also, I do feel like it feels right that the app that I created my community with is the one that hosts it.

I’ll be very interested to see that! I need some more references to see if this rough shape I have for these lexicons is going to support the different use-cases people have.

We are also working on getting a working arbiter implementation up as soon as possible ( hopefully this week ), which I think is important to discovering whether the API makes sense in real use.

We realized that the challenge of community management doesn’t only apply to private data, but public data too. And our latest arbiter design can apply policies over any XRPC API, so we’re hoping to be able to trial some of this for public community / org accounts, while having it aligned with the permissioned protocol’s requirements.

Don’t stress, it’ll be messy

Just to remind myself & you all: this whole layer is much more forgiving than the protocol underneath it. That’s actually why we’re intentionally trying to keep the protocol layer so simple (just a member list).

:100:

I really appreciate how simple the underlying protocol has been kept. I think, as tricky as it is to have to figure stuff out, someone has to do it, and the base protocol being simple empowers the community to figure that out in parallel with each-other, just like lexicons!

3 Likes
5

Thanks for the quick responses yall!

Oh that must’ve slipped by me! And congrats on going full time!!

I think in cases like you describe, having the organization run the space host & manage membership policies absolutely makes sense. Do you also expect the organization to run all participating member PDSes? Or will it be flexible/compatible with non-org PDSes.

Excited to hear more as plans come together.

Yes absolutely! We’re working on PDS account interfaces right now actually. Still, there’s a certain amount of genericity to the account interface that I think keep it from being a good community management interface.

That’s actually a really good analogy. I hadn’t thought of it.

This is also a great point. I think this + the pointer records give enough optionality that I feel comfortable saying the by-authority & by-type axes suffice for now & we can avoid doing anything too tricky with scopes.

I think this is the direction I’m leaning as well. And I agree that tying it to the app makes sense for user intuition: “I made this community in this app, so I go to that app to manage it (unless, of course, I go through the process of migrating it somewhere else)”.

I’m also happy that this means we might not have to ship a controlled account system in the PDS :slight_smile:

A couple thoughts:

  • This makes the XRPC API for the arbiter pretty damn powerful. Like maybe more powerful than is currently captured by the service proxying consent item on the OAuth page… I wonder if we need the ability to mark certain XRPC methods as “sensitive” or soemthing.
  • You’re right that the actual location of these all is discoverable at the protocol layer. That alone makes me quite a bit more comfy. But say you’re using a “community management app” to manage your communities through standard XRPC methods across many different arbiters. How does it even know which spaces you “own” or are an admin of? I guess it can enumerate all spaces you’re “in” from the PDS. And then reach out to each space to determine it is arbiter-compatible & if you have any role there :thinking:
3 Likes
6

Really exciting to see these questions getting fleshed out more and appreciate everyone’s insights here!

re who runs an arbiter, my intuition is that the trust implications have more in common with the PDS than an app, but i guess if the PDS can direct any other app wanting to do community management operations to the arbiter as the ‘managing app’, that feels functionally equivalent - the flow of having to redirect to the app you made the community on also makes sense to me as a default.

just some questions i have arguing the case for tying the arbiter to the PDS: how common would it be that you want an arbiter and not a repo-shaped shared data store? you have a community DID, you have a central source of truth for space membership and roles etc state, you have policies that authorise community access, why wouldn’t you want the capacity for that community to act as an atproto account and store as much of that as possible and other arbitrary data in a portable interoperable format established in the protocol? tying these to the PDS is maybe appealing in that it kind of symbolises the ‘permanence’/credible exit guarantees we ultimately want for communities

that all said, agreed with embracing the mess and accepting that maybe a lot of these community management questions are just necessarily out of scope for the current project of implementing permissioned spaces, and we will just need to test things out and converge more organically!

2 Likes
7

I think from the perspective of purely “what do I want”, yeah, I almost always want an ATProto repo along with my community if that’s possible.

But then we have to handle write authorization, which is way harder to figure out and probably out-of-scope for the PDS.

But it is super useful and related, so that’s why we’re combining an ATProto repo with the arbiter in our specific implementation in our latest prototype. But that’s not something I necessarily expect the standard arbiter API to support. At least not as a first pass.

I definitely think we’re going to have to do lots of experimenting to get it all figured out.

But so far I haven’t found any pressure in any of these plans or thought experiments to change the perm data proposal, so I’m super excited that it feels like it might not be too far from the standard that we need for the PDS layer.

8

Okay yeah that’s a great point. And I expect a lot of users communities will want to have a repo under the community DID as well. So in that sense, an arbiter will probably also need to serve as (or be deployed alongside) a repo host. A say “repo host” because PDS also implies that it’s an OAuth authorization server & has all the other facilities of a user-facing PDS.

To reframe the question away from network roles: Should a user conceptualize community DIDs that they control as being part of

  1. their account host (PDS)
  2. an application they use
  3. an independent service
9

I need to catch up on how permission groups works. I wonder if a dangerous sounding message would be enough in the consent screen or not. :thinking: It does seem like it’d be handy to have a way to highlight a permission as sensitive.

That’s an excellent question that has come up a couple times in our discussions and is somewhat tricky: someone can give you access to something, but how do you know they gave you access.

Some things we’ve thought about:

  • You could have a collection in a permissioned space that only you have access to, to act as a personal list of all the communities that you have explicitly joined.
  • If someone wants to add someone else to a community, we almost need a way to DM and say “I added you as a member to so-and-so community”, but that has a potential spam problem, so maybe just sending invite links out of band is best for a start. After accepting an invite, it adds a new record to your personal list of joined communities.
  • Alternatively, if the membership / control you are granted to the community is public, then it could be put in the public repo and discovered through the firehose.

I think if a personal list of joined communities uses a common lexicon, then it should be a decent way for apps to discover which community’s you’re in.

10

I feel like this is very related to the question that we have with your PDS account: should a user conceptualize their Atmosphere account that they control as being a part of the application they created it in, or a separate service?

The community rightly put a lot of pressure on not calling Atmosphere accounts “Bluesky accounts” because it’s not tied to an app. But naturally they may associate their account, to the app they signed up with: their “Tangled account”, or their “Roomy account”.\

Maybe communities are similar.

At the same time, we have an extra option here: associating the community to your PDS.

:thinking: Thinking about that it occurred to me that it would be possible for the PDS to host the DID of the community, while delegating the space host / arbiter service endpoint to remote servers.

That would feel very nice in that the user automatically has the rotation key for communities that they create. But apps could ask the PDS to create a new DID with particular service endpoints![1]

That doesn’t exactly answer the question, though it would definitely lean towards having the user associate the community with their PDS. Then the applications / independent arbiter services become to the community what a PDS is to an Amosphere account.

It’s a little brain twisty no matter how you slice it, but that feels kind of close to right to me.

PS: sorry I’m so verbose. It’s how I think through problems. :smiley:

  1. This is somewhat related: “I think there should be a PDS API for updating service endpoints.”. ↩︎