tangled.org / core
Monorepo for Tangled tangled.org
fork atom

proposal: remove sh.tangled.*.member lexicons #335

open opened by boltless.me edited

Registered users should be saved locally inside knot/spindle instead of broadcasting to entire network. Just like how PDS handles registration.

The user might try to use a wrong Knot/Spindle, but it's on them trying to use unauthorized service.

Scenario:#

  1. User register to knot/spindle. They should provide web interface or xrpc api for this. All users will auto-registered to knot1/spindle1 on login.
  2. User create a repo and input knot host url (AppView can provide easier UI like typeahead)
  3. AppView assumes they are registered to that knot and try xrpc call to knot. If forbidden, notify that on UI.

If AppView needs the registration state, it can fetch that from {knot,spindle}/xrpc/com.atproto.sync.listRepos.

Implementation plan:#

  • switch from jetstream to tap in knot/spindle for better backfilling
  • remove the sh.tangled.*.member lexicons

Benefits:#

  • less jetstream events knot/spindle should listen to
  • single source of truth for registered users
  • aligns with atproto
boltless.me (author) edited

We are going to separate the repository as a standalone DID, so I'm leaving this comment in that context. I think this still applies to current architecture, but be aware when reading.

Both Knot and Spindle needs to check if repository is registered to it, not users. Currently 'member' concept serves two jobs:

  1. ACL for repo creation from Knot
  2. manage list of usable knots in repo creation page

It doesn't even block actions like git push. If someone is a collaborator they should be able to git-push to Knot or trigger a pipeline. The repository is registered to these services, not collaborators nor the repo owner. Conceptually ACL logic should start from registered list of repositories.

Authorizing repository creation#

Now we don't need the concept of members at all. Knot might have a blocklist or allowlist to deal with malicious actors, but by spec, we don't need the concept of members.

More convenient repository creation UI#

For 2nd use-case, we can instead have some interactive UI to find the Knot, showing recently used servers on top with first one selected by default. Same UI can be used to Spindle too (currently we just provide raw hostname input for spindles).

Hiding Knots from knot-select UI#

Some Knots might be only for specific user, in that case, the knot can notify that from sh.tangled.knot.describeKnot endpoint like PDS specifies things like phoneVerificationRequired from com.atproto.server.describeServer endpoint.

boltless.me (author)

member lexicons also doesn't make sense considering how tightly it is related to the services. We don't need to decentralize the allowlist. It can conceptually exist, but doesn't need to be decentralized. Admin should configure the service from admin panel, not from third-party app (tangled appview).

sign up or login to add to the discussion
Labels

None yet.

area
appview
knot
spindle
assignee
boltless.me
Participants 1
AT URI
at://did:plc:xasnlahkri4ewmbuzly2rlc5/sh.tangled.repo.issue/3maae23igov22