Blebbit Use Cases

verdverm.com · September 7, 2025, 12:27am

Blebbit will initially resemble Discord, so all the use-cases therein for private data. Long-term the use-cases from giving users and communities the options to craft their own take on the blend of Discord, Reddit, FB Groups, etc…

For me, the ideal permission system for the protocol will be sufficiently rich enough that any app can have access to the same permissions, roles, groups, and spaces capabilities without the need to run their own permission systems and stores. There is also the Dual Write problem that would be ideal to solve at the PDS layer to avoid every app and developer having to, but I’m not sure that’s actually possible? ¯\_(ツ)_/¯

When I went to find a good permission system to use for Blebbit off-protocol, I settled on SpiceDB for a number of reasons. I’m now trying to take out off-protocol work and put it in the PDS as an experiment to inform the discussion.

If you want to dig into the details, checkout the Blebbit @atproto TS fork

verdverm.com · September 7, 2025, 12:30am

I noticed this capability in Discord today, I think it represents a pattern more broadly useful

bmann.ca · September 7, 2025, 1:31am

Thanks for writing this up!

I think Discord server is a special kind of instance that isn’t quite a group. This has exactly one owner.

Then, roles == groups. Permissions system is very extensive.

A channel and a thread both can have permissions, plus a few special things like voice channels and stages and such.

verdverm.com · September 7, 2025, 2:11am

I disagree that roles == groups, they are compositional in the sense that groups are collections of subjects and roles are collections of permissions, much like in oauth, but more extensive. You then bind them them in pairs across a many-to-many relationship. Spaces or folders allow for nesting these things, and where content and rpc gets authorized, and the system walks that tree too for authorization. AppViews can have lexicon for stuff like channels and threads, and define default groups and roles that make sense for their AppView.

In this sense, a “Discord App” server could be a full account or maybe there are multiple Discords under one account using nested spaces. Same for groups or communities. A space could even be a composition of apps. I would imagine though, a common pattern for “Discord Spaces” would be a 1-1 group-role relation just for the simplicity of it all. There are also companies picking Discord over Slack now, and they typically have a much richer or robust group/role setup. That is another pattern I want to support.

I just did a big refactor of my permission system, still need to untangle the nsid stuff a bit and how it can support their dynamic nature. But maybe it is still comprehensible to people without context?

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/schema/_a.zed

main

// not all are used yet
definition anon {}

definition user {}

definition oauth {}

definition apikey {}

definition svcacct {}

definition service {}

definition superuser {}

// custom roles
definition role {
	relation parent: space
	relation member: user | apikey | service | svcacct | space#member | group#member

This file has been truncated. show original

verdverm.com · September 7, 2025, 5:23pm

actually… group ?= role …you can do it both ways with the same permissions schema

or mix and match, going through a permissions consolidation process with a client and the move is from users/groups having permissions to using roles

I think generally, the 99%ers of ATProto will not want to give up features from their existing permission systems

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/demo/seed/basic_group.sh

main

#!/usr/bin/env bash
set -euo pipefail

seed_basic_group () {

  #
  # Jay
  #
  eval ${accounts[jay]}
  group=${acct[gs]}
  space=${acct[sr]}
  subj=$group#member

  mrun "jay adds a standalone group" bind $group parent $space
  for reln in ${lister_role[@]}; do
    mrun "..reln:" bind $space $reln $subj
  done
  for reln in ${iam_lister_role[@]}; do
    mrun "..reln:" bind $space $reln $subj
  done

This file has been truncated. show original

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/demo/seed/basic_group.sh

main

#!/usr/bin/env bash
set -euo pipefail

seed_basic_group () {

  #
  # Jay
  #
  eval ${accounts[jay]}
  group=${acct[gs]}
  space=${acct[sr]}
  subj=$group#member

  mrun "jay adds a standalone group" bind $group parent $space
  for reln in ${lister_role[@]}; do
    mrun "..reln:" bind $space $reln $subj
  done
  for reln in ${iam_lister_role[@]}; do
    mrun "..reln:" bind $space $reln $subj
  done

This file has been truncated. show original

verdverm.com · September 8, 2025, 5:29am

Created a little framework around this schema for easily simulating various use cases

(I’ll add a doc how you can build them too, will also be gather and implementing many myself)

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/demo/cases/_blueprint.sh

main

#!/usr/bin/env bash
set -euo pipefail

CASE_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"
source $CASE_DIR/../_common.sh
source $DEMO_DIR/seed/index.sh

echo "BLUEPRINT: $@"

CASE=${1:-default}
# shift $((OPTIND - 1))

case $CASE in
  default)
    enum_space
    enum_group
  ;;

  jay)
    seed_basic_role

This file has been truncated. show original

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/demo/cases/_run.sh

main

#!/usr/bin/env bash
set -euo pipefail

CASE_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"
source $CASE_DIR/../_common.sh
source $DEMO_DIR/seed/index.sh

NUKE=
SEED=
SUBCASE=
while getopts "x:s:c:" opt; do
  case $opt in
    x)
      NUKE=$OPTARG
      # echo "confirming.nuke.$NUKE"
      ;;
    s)
      SEED=$OPTARG
      # echo "confirming.seed.$SEED"
      ;;

This file has been truncated. show original

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/demo/cases/appview_prefs.sh

main

#!/usr/bin/env bash
set -euo pipefail

CASE_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"
source $CASE_DIR/../_common.sh
source $DEMO_DIR/seed/index.sh

# ensure we have accounts
echo "0. ensuring accounts"
seed_accounts
echo

# create space and assign service
mrun  "1a. create service space"  bind space:jay/bsky parent space:jay/root
mrunn "1b. give app ownership"    bind space:jay/bsky owner  service:bsky_app

# app creates preferences object
mrun  "2a. check app can write"   check space:jay/bsky record_create service:bsky_app
mrunn "2b. create app prefs"      bind  record:jay/bsky/bsky_prefs/self parent space:jay/bsky

This file has been truncated. show original

verdverm.com · September 8, 2025, 7:23am

docs!

github.com/blebbit/atproto

packages/pds/src/authz/spicedb/README.md

main

# SpiceDB integration

Also look at [the proposal notes at the repo root](/proposal.md) (no pun intended)

## at-uri & content addressing

To support spaces, we extend at-uris with a query parameter `at://...?space=<rkey>`.
- the space is the parent, root is the unspecified or implied
- every acct has a `did/root` space, then can nest as many as they like
  - `at://did/com.atproto.space.space/root`
  - `spice://did/space`
- two-way conversion for spicedb allowed chars (not seen in demo)
  - at-uri: `at://did/nsid/rkey?space=<space>`,
  - spicedb: `type:did/space/nsid/rkey`
  - similar content-path specificity [acct->space->collection->record]
- in `demo` we simplify various identifiers for legiblity


## schema

This file has been truncated. show original

verdverm.com · September 9, 2025, 6:31am

working on a slide deck for my stuff, how is this one-pager for “what are spaces?”
(context, someone who already has context of what we are working towards)

boscolo.co · September 9, 2025, 1:42pm

Looks interesting!
Two questions.

Do you have any plans to support OAuth sign in?
How are you planning to support he DM feature? (I’m looking for apps that want to experiment with my AT-SMS project)

verdverm.com · September 9, 2025, 5:26pm

OAuth is already handled by the PDS, I’m not doing anything with that directly. What I do still need to add is support for PDS-PDS proxying, like PDS-Service proxying so OAuth credentials are proxied into a token for the PDS with the spaces.

No plans for DMs in this area. I think there are three private data avenues, they’ll be built in parallel, and users will have choice in which system / experience they want. I’ll be talking about this in the full presentation.

E2EE messaging
E2EE data
Permissioned Spaces (this work)

That being said, I imagine one could use permissioned spaces for DM like content. My plan for Blebbit is to leverage the eventual E2EE DM solution for DMs. Chat room content is a bit different, still figuring it out, tends to be a lot more volume/noise/transient, want a two-way websocket ideally too. But, in theory, you can put anything into a space, including blobs and encrypted data, so lots of possibilities!

boscolo.co · September 9, 2025, 7:14pm

wrt OAuth, I may be asking the wrong question, or presuming something I shouldn’t. When I click the @ ATProtocol in the upper right of the blebbit.app I see the following login prompt.
I assume since it is asking for my password, it is not using OAuth (I expect OAuth to send me to a bsky.social login page?)

verdverm.com · September 9, 2025, 7:24pm

oh, yea, that’s old code from March before I implemented OAuth for Blebbit in Authr

When I have enough of the PDS permissioned spaces implemented, I’m switching Blebbit over at which point it will get the OAuth treatment

verdverm.com · September 11, 2025, 11:23pm

Link to a slide deck (still expect a few more changes)