Can a did own a did with their primary did?

Discussion
1

did 1 can read and write to(/with?) did 2.

did 2 can only read did 1 (no write).

is this possible?

1 Like
2

read or write what, DID Docs or records?

PLC doesnt’use the controller prop and it should for heirarchical relationships (as opposed to bidirectional alsoKnownAs)

3

thanks for sharing this!!

here is where i am coming from:

if a user logs into linkname with their .bsky.social PDS, I want to issue a .self.surf PDS in the background which the logged in .bsky.social PDS owns. I want to do this in order to display the username as a clean /username without any .bsky.social/.self.surf extension.

re: w3c did-controller, as far as I understand, did:plc currently does not support this usecase since the rotationKeys and signingKey are the controller rather than the W3C controller property - but, I could build a solution where the controller is listed as did1 in did2 document?

did2 essentially is just cosmetic and only serves as its dedicated linkcollection tool

note: not sure if i really want to build this out, im exploring possibilities at this stage

4

on another note: im also exploring solutions to solve for multi-user did access-control

eg. team of 5 people, 2 are admins and can do everything incl. delete the PDS, 2 are editors who can only read-write to the PDS but dont have ability to delete the PDS itself. the last user can only write to the PDS not delete records

1 Like
5

You’re running a centralized app front end, it’s fine for you to set routes as you like / let the user pick, I don’t think spawning multiple accounts is the way to go.

1 Like
6

centralized app front end

yep i could probably do it in a hacky way quickly, but i would also love to find a solution that is more trustless and potentially useful for others :slight_smile:

I saw this recording today which suggested 2-out-of-3 signatures to allow for company and group accounts https://atmo.rsvp/p/atmosphereconf.org/e/gDP6A8N

I am not 100% in love with the ux as coordinating is painful and can still be compromised via opsec

maybe someone has other ideas to solving this!

7

Yes. Wait for someone else to solve it.

But mostly users won’t care, especially if your use case is to be the winning link in bio.

I think it is quite easy to build link in bio in the atmosphere, so the best thing you can do is innovate with onboarding people that don’t have atproto accounts.

1 Like
8

I care. I dont want to lock users in, I want to offer the possibility for users to switch to any linkinbio tool built on atproto.

the best thing you can do is innovate with onboarding people that don’t have atproto accounts

I think I have done this mostly by making onboarding a blank slate and abstracting away all of bsky auth etc.

I do understand that not using oauth is less secure, but oauth is a terrible ux for people not knwoing anything about bsky/atproto.

Im looking into using OTP as hypercerts did so that people dont have to enter their pw :slight_smile:

1 Like