whyrusleeping: If the

custom handle

Added custom-handle function to the client

1234567891011121314# web : bsky.syui.cf -> login -> profile -> custom-handle
# Note: re-login

# cli : github.com/syui/atr
$ cargo build
$ vim ~/.config/atr/congit.toml
host = "bsky.social"
pass = "xxx"
user = "xxx.bsky.social"
$ ./target/debug/atr h vvv.bsky.social
or
$ ./target/debug/atr h example.com
# Note: change -> config.toml
# user = "example.com"

Worth noting that it is cbor if your op is JSON you will not get the did.

1did:plc:${base32(sha256(cbor(createOperation))).slice(0, 24)}

base32(5 bits per char) * 24 char = 120 bits of security

https://github.com/bluesky-social/did-method-plc/blob/4da6c6d5c3aa4894650fdbddc60d616e7d8d8946/packages/lib/src/operations.ts#L16-L21

To new comers:
This group is for tech discuss, not for invite code

pls don’t ask invite code again🤝

So if you were to run curl -s "https://bsky.social/xrpc/com.atproto.handle.resolve?handle=ngerakines.me" | jq you'd get back

123{
  "did": "did:plc:cbkjy5n7bk3ax2wplmtjofq2"
}

For what it's worth I see both the _atproto.ngerakines.me. IN TXT DNS record and the

id 31451 opcode QUERY rcode NOERROR flags QR RD RA ;QUESTION _atproto.ngerakines.me. IN TXT ;ANSWER _atproto.ngerakines.me. 3600 IN TXT "did=did:plc:cbkjy5n7bk3ax2wplmtjofq2" ;AUTHORITY ;ADDITIONAL

The tricky part there is defining priority order.
We want to be able to verify domain names by DNS.
We want to be able to verify domain names by https.

If a DID Document has many AKAs some using DNS and Others using https fine. As long as the other is silent.

If there is a domain name where the DNS points to one DID and the https points to a different DID. Both DID Documents AKA back to the domain name.
What should be done with that?

Once the list of ways to validate a domain and the priority is decided it should be added to the spec until then it may be premature.

xrpc,
/.well-known/_atproto,
DNS TXT,
_atproto.DNS,
Something else?

Personally I lean towards only the well-known and _atproto.handel DNS TXT
But I get why xrpc is compelling for domains that are running PDSs

With all dew respect to DNSsec I'm leaning towards https having priority over DNS because the CA have historically been less spoofed than DNS but meh 😕. There just needs to be a closed set of domain name verifications and an ordered priority so at:\handel\path URIs resolve unambiguously.

Yeah, personally I think DNS is the way to go, but it does raise the bar to entry. In an ideal world, if someone wanted to have their own domain then they could generate some static files to serve OR have a couple of DNS entries to create and boom.

One thing that threw me off was the use of GET .well-known/did.json in the DID spec, but not the atproto spec.

With HTTPS you can do

1. Server gets reference to ngerakines.me
2. Server makes GET ngerakines.me/.well-known/_atproto
3. Server receives a DID with services block pointing to PDS
   bsky.social
4. Server makes GET https://bsky.social/xrpc/com.atproto.handle.resolve?handle=ngerakines.me

Daniel Holmgren: Do you remember why we used common. Bytes aka z.instanceof(Uint8Array) as the key type in the MST and not z.string()? The paths are all url paths and should be strings.

12345"k": {
        "/": {
          "bytes": "YXBwLmJza3kuZmVlZC5wb3N0LzNqcHp1a2hlZWkyMjI"
        }
},

is a little less readable then

1"k": "app.bsky.feed.post/3jpzukheei222"

when I view the dag-cbor as dag-json

https://github.com/bluesky-social/atproto/blob/9baf9b23d8c06165dd2e91487fed23277bda17d0/packages/repo/src/mst/mst.ts#L50

it's my understanding that the AT protocol is fully open-sourced currently, but Bluesky the application is not yet. it will be eventually.

in this chat we're mostly just discussing Bluesky, the AT protocol, and anything related to them

In reply to

Aaron Goldman

Daniel Holmgren: Do you remember why we used common. Bytes aka z.instanceof(Uint8Array) as the key type in the MST and not z.string()? The paths are all url paths and should be strings.

12345"k": {
        "/": {
          "bytes": "YXBwLmJza3kuZmVlZC5wb3N0LzNqcHp1a2hlZWkyMjI"
        }
},

is a little less readable then

1"k": "app.bsky.feed.post/3jpzukheei222"

when I view the dag-cbor as dag-json

https://github.com/bluesky-social/atproto/blob/9baf9b23d8c06165dd2e91487fed23277bda17d0/packages/repo/src/mst/mst.ts#L50

Resolving at://did is done in two steps.
One retrieve the DID Document for the DID to learn the services.atproto_pds.endpoint where the users repository is stored.
Two call that PDS and ask for the repo. Or more likely the difference between the last time you fetched the repo and now. Think git fetch.

Now you have the repo and the path is just the path at://{did}/{path/to/object}

An at: URI does not resolve if you can't retreve the DID Document, can't retreve the repo, or the path is not in the repo.

@bnewbold I got in, I appreciate the kind message tho, excited to build a client for this 😁

I’ll make sure not to scope creep for the rest of the discussion 😂

YWN get an invite code. Cope. Seethe
Huh ? I’m new to this ?

So, the glib answer is that the did:plc stands for placeholder? When the community settles on DIDs that don't suck this project can move to whatever DID methods become the de facto DID method.

The more serious answer is that the

The two most likely paths forward are either a small consortium of the most trusted players in the community (11 of 16) BFT algorithm for time stamping and a multi-cast tree for distributing the accepted values to all PDSs.

The other option is a large consensus group like all the PDSs with 28 day continuous up time. ⌊2/3⌋ + 1 accepts a value and we don't need a multi-cast tree since basically everyone was in the consensus algorithm anyway. The PDSs not participating in the consensus algorithm just periodically poll any PDS that is.

but like I said probably premature to design it there are not a lot of PDS operators at the moment.

Yes you could use a threshold of friends, or devices.

So the argument is that you need to specify a consensus group for identity document updates. This could be relying on someone else for the timestamps e.g.

did:keri calls them witnesses and the witnesses set is managed in the document itself.

https://identity.foundation/keri/kids/kid0000.html

In reply to

moved to @shreyan:beeper.com (@shreyanjain:matrix.org)
nobody has any real incentive to run a node on a dht

This is not actually a straightforward answer.
There is a server called dSocialCommons that used to be called BlueskyCommunity.
https://discord.gg/JcwwMrDx

It was the server for the community looking into the distributed protocols for Jack to propose one for twitter to move to. When arcalinea was chosen to create and run Bluesky PBLLC and the Public Benefit Limited Liability Corporation was funded it supported the BlueskyCommunity with grants. Once Bluesky PBLLC decided not to continue funding BlueskyCommunity the community was now independent of the PBLLC so the name was misleading.

The PBLLC kept the name "Bluesky" and the community was renamed to "dSocialCommons" and broadened the scope to all Social protocol that operate on top of distributed tech.

Bluesky Dev is intended as a channel for people building ontop of atproto.
dSocialCommons is intended for protocal and philisopical comparisons.

@damon let me know where this answerer is confusing and I will try to clarify.

Was just reading the docs and seen the What is “XRPC,” and why not use ___? section, does this mean there is a publicly available Postman collection maintained by the AtProtocol team?

If so, where can I find that?

No secret I am a fan of Kademlia.
https://youtu.be/NxhZ_c8YX8E

Kademlia seems really cool, I hadn't heard of it before, for some reason

by my count

1234567891011| operation.service    | operation.services.atproto_pds.endpoint | count did |
|----------------------|-----------------------------------------|-----------|
| null                 | https://boobee.blue                     |       163 |
| null                 | https://bsky.social                     |      5330 |
| null                 | https://syui.ai:2583                    |         3 |
| https://boobee.blue  | null                                    |         1 |
| https://bsky.social  | null                                    |      2602 |
| https://bsky.syui.ai | null                                    |         1 |
| https://syui.ai      | null                                    |         1 |
| ignore               | null                                    |         1 |
| localhost:4989       | null                                    |        30 |

So there are a few levels this question can be answered on.

The repos are at their heart a collection of objects and their paths. This could be put in a relational database. We wanted to be able to sign each update to the state of the repo. There is not really a standard way to hash the state of a relational database to a single 256 bit number to sign.

You could do something very brute force like putting all the data in a SQLite file and hashing the bytes to sign but that would have costs linear in the size of the repo and you would need to download the entire repo to validate the signature.

So the next logical step is to put all the objects in a trie. This is much better when we change a single object we now generate only the nodes in the path from the object to the root and resign the root.
Ok now we are able to verify a single object. However the trie depth could get pathological. If my keys are like (b, ab, aab, aaab, aaaab, aaaaab). The standard way to fix the arbitrary depths problem is to hash the keys before putting them in the trie. This solved the depth but hashsets are in arbitrary order. I lose the ability to checkout a range e.g. repo/posts/* or repo/follows/* the keys are in logical collections we would like to keep the order. So we want to use a b-tree set so we don't lose the order. Rebalancing the b-tree would be a big diff.

How do we get the best of the memoryless property of the trie, the shallow depth of the hash set, the ordered range queries of the b-tree? Enter the Merkel Search Tree. It's a b-tree so we get ordered ranges. The pointers are cryptographic hashes it's a Merkel tree and we have something to sign. The balance is determined by the hashes so we have logarithmic depth.

Small proofs on ranges.
Cheap diffs to sync the repos.
Good structural sharing as a persistent data structure.

So long story short. Most relational databases are built on top of b-trees. If you want SQL build it on top of the MST it should work well.