I get questions sometimes about the .car files.
If I respond with this python script is it more clear what a car file is?

12345678910111213141516171819202122232425262728293031# pip install multiformats
# pip install cbor2
import multiformats
import cbor2
import sys

# # usage
# > cat something.car | python3 car_view.py

# CAR file format
# | length | Header |
# | length | CID | block |
# ...
# | length | CID | block |

car_bytes =  sys.stdin.buffer.read() # read the car file from stdin
length, _, rest = multiformats.varint.decode_raw(car_bytes) # file starts with the header length varint
head = cbor2.loads(rest[:length])  # read the header CBOR object {'roots': [CID], 'version': 1}
rest = rest[length:]  # move up the pointer
print(head)

while rest:
    # | length | CID | block |
    length, _, rest = multiformats.varint.decode_raw(rest) # read the block length varint
    cid_and_block = rest[:length]
    cid = multiformats.CID.decode(cid_and_block[:36])  # CID first 36 bytes
    block = cid_and_block[36:] # block rest bytes
    obj = cbor2.loads(block) if cid.codec.name == "dag-cbor" else block
    rest = rest[length:]  # move up the pointer
    print(cid.encode(base="base16"), obj) 

Hi! I bring awesome news 🙃 Python SDK has been updated! Added update_params to keep the cursor of firehose up to date, export and import of session string to deal with rate limit v3, ability to pass base_uri to firehose client, and updated lexicon!

• Release notes: https://github.com/MarshalX/atproto/releases/tag/v0.0.28
• Example of session export and import: https://atproto.blue/en/latest/xrpc_clients/client.html#atproto.xrpc_client.client.client.Client.export_session_string
• Example of how to use update_params: https://github.com/MarshalX/bluesky-feed-generator/commit/3aa6428f77769bf83e036d5e43f48a0e4a5a107a

1234567891011  PDS                                did count   delta count    sum bytes     first                      last
| https://bsky.social              | 1,093,014 |   1,219,035 |  840,591,800 | 2022-11-17T00:35:16.391Z | 2023-09-19T05:22:38.013Z |
| https://uwu                      |    11,714 |      11,714 |   86,648,128 | 2023-05-30T06:32:05.019Z | 2023-06-30T18:52:10.965Z |
| https://stems.social             |     5,044 |       5,897 |    4,048,359 | 2023-04-16T09:28:40.041Z | 2023-07-05T17:31:28.795Z |
| https://boobee.blue              |     1,645 |       3,073 |    2,177,336 | 2023-03-12T15:11:56.675Z | 2023-09-19T04:55:53.900Z |
| localhost:4989                   |        95 |          95 |       47,786 | 2023-02-21T19:31:07.150Z | 2023-09-10T01:56:38.643Z |
| https://atproto.forza7.org       |        53 |          63 |       43,612 | 2023-04-13T14:10:14.176Z | 2023-09-11T11:09:06.646Z |
| https://bluesky.nokotaro.com     |        54 |          58 |       40,637 | 2023-05-27T01:42:52.573Z | 2023-08-23T13:24:34.095Z |
| http://localhost:2583            |        40 |          40 |       26,727 | 2023-04-13T23:57:47.589Z | 2023-05-22T14:26:37.835Z |
| https://bsky.syui.ai             |        24 |          27 |       18,208 | 2023-03-25T01:49:54.257Z | 2023-08-09T17:10:21.538Z |
| https://redocean.one             |        22 |          23 |       15,785 | 2023-06-14T04:59:26.525Z | 2023-08-31T03:39:17.387Z |

How the federation vs centralization is going.

and if successful, would the output JSON look something like this?

12345678{
    "$type": "blob",
    "ref": {
        "$link": "bafkreibabalobzn6cd366ukcsjycp4yymjymgfxcv6xczmlgpemzkz3cfa"
    },
    "mimeType": "image/png",
    "size": 760898
}

I will say the fact that 1,817,104 did:plcs have

12"rotationKeys": ["did:key:zQ3shhCGUqDKjStzuDxPkTxN6ujddP4RkEKJJouJGRRkaLGbg",
  "did:key:zQ3shpKnbdPx3g3CmPf5cRVTPe1HtSwVn5ish3wSnDPQCbLJK"],

1,817,104 DIDs with the same secret keys feels weird to me.

Looks like the current implementation looks at the local PDS database so it would only find the thread if it is synced to the PDS.

https://github.com/bluesky-social/atproto/blob/bb039d8e4ce5b7f70c4f3e86d1327e210ef24dc3/packages/pds/src/api/app/bsky/feed/getPostThread.ts#L125

To decide if a PDS should pull the post from joelotter.com's PDS would be a matter for the local PDSs allow/deny list of PDSs it is willing to resolve content from.

Depends how far you zoom in.

Both are identifying blocks by their Sha256 and controllers by Ed25519 signatures.
So both are Authenticated Data protocols.

Nostr events stand on their own. One object one signature.

AtProto is organized as repos. Each comment adds/removes objects from the repo that is a (path, value) store like a git repo.

Nostr allows multiple relay servers to store and forward the events. This means that you have eventually consistently depending on whether that relay has that event.

Bluesky has the PDS(personal data server) that has the full repo and is the authoritative source of "latest" so a strict consistent update is possible even across objects in the repo.

Nostr is more about simple and do what you want. This gives them robustness.
AtProto is more about correct atomic updates. This requires a source of truth to be highly available.

Would you kindly expand a bit on what it means to be ‘more about correct atomic update’? Are we talking atomic-clock kind of correctness, or is this more about the atomicity (self-contained, composable etc.) of each update? 

With AtProto it may be worth breaking down the protocol into pieces to talk about it.

1. Finding the PDS that is the current host of a at://DID/path URL. This is analogous to a DNS request. Pull the DID out of the URL and resolve it. If it is a did:plc then talk to the PLC directory. If it is a did:web do a http request to resolve the document. Most of the time this DID to PDS mapping will be chached.

2. Finding the current head of the repo. Only the PDS can give you this 32 bytes. It is the fact that the PDS can give you an authoritative latest for the head that gives you the ACID possibilities. If you don't care about those ACID properties you could ask anyone with a copy of the repo to give you the latest they happen to have.

3. Get the repo from anyone who has a copy and validate that it hashes the head commit. The repo can be stored and served long after the controller and their PDS is gone.
The PDS also serves as a repo durability of last resort. If no one else has the content you can always go back to the PDS. For unpopular content the PDS can handle the few requests and for popular content it will be in caches around the Internet.

1 is not really federated as you need either the PLC directory or the DNS,CA system for did:web
2 is not federated as you are pulling the single 32 bytes of the Head from a specific PDS.
3 is perfectly decentralizable as the content delivery heavy lifting is just hash address content. As long as you are willing to accept bounded stillness you can get content from anyone and validate it with hashes and signatures.

Hi! Not sure how to import from "

1import { DidResolver, HandleResolver } from "@atproto/identity";

seems to throw (tested on node & bun, using vite)

12345678910111213141516171819202122232425[→ delayed_stream.js:15:5]
Uncaught TypeError: util2.inherits is not a function
    stream 1.0.0/node_modules/delayed-stream/lib/delayed_stream.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:2487
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    stream 1.0.8/node_modules/combined-stream/lib/combined_stream.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:2566
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    data 4.0.0/node_modules/form-data/lib/form_data.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:11549
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/lib/defaults/env/FormData.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:11860
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/lib/defaults/index.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:11954
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/lib/core/transformData.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:11978
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/lib/core/dispatchRequest.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:12000
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/lib/core/Axios.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:12179
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/lib/axios.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:12396
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    axios 0.27.2/node_modules/axios/index.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:12429
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:198
    node_modules atproto/identity/dist/index.js@http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:21242
    __require http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:3
    <anonymous> http://localhost:5173/node_modules/.vite/deps/@atproto_identity.js?v=bafe161c:28360

Not sure if that is me doing a wrong import, or if a known issue, or if I should post here or open an issue on github?
Cheers in advance!

he unironically said in a federated chat room

It was a trade-off between transferability and transferability.

If people would manage their own keys we'll then you would not need window key rotation would just be first come first serve. We added the window for two cases. Firstly if your key is stolen and they rotate to their keys you want to be able to recover. Second is if you trust your PDS to update your DID Document for you and they try to take your repo. In either case you don't want the rotation to be final you want to be able to override it.

So why not allow priority key override forever and never have a key rotation be final? This would prevent transferability of the repo. Many, probably most, users will let PDS generate the repo for them only after having a repo for awhile will it be valuable enough to be worth managing their own keys. At that point they should be able to take control of their repo in a way that the PDS that created it can't revert months or years later. When you take control of your repo it should be yours and the transfer should be final.

The thought process was that in a distributed system there isn't really a time when events happen there is only the time when events are witnessed. If I link to your post, say a like or comment, then your post happened before my comment. If your PDS is tracking when it first sees commit from foreign ropos it can use the Merkel DAG to find some event it witnessed at at a time to bookend the event.

To "know" the time of a commit C find to witnessed events A, and B where A < C < B.
'A < B' here meaning that there is a path in the Merkel DAG from B to A.

Why do you need to learn the AT architecture?
https://atproto.com/guides/data-repos
It is more detailed than any video I know of.
That said.

Joe Beda has a talk I liked
https://youtu.be/9tZrxSyRPH0

This is a good place to discuss the protocol limits vs the PDS made by Bluesky PBC.

The protocol has the repo controller sign the repo commits.
The controller needs not run a server and the PDS need not ever touch a controller's keys. Unlike TLS where the server must have authority over the content it serves the PDS servers authenticated data without the need for any cryptographic material.

That said the current implementation stores "your" keys on the PDS and the PDS signs the repo. The users don't update their repos they request that the PDS update the repo for them in the PDS politely acquiesces. If you wanted to not be at the mercy of your PDS you would have to store key material.

Hi all. What would be the correct way to update a profile in my PDS server? Previously, handles were appearing as "Invalid Handle" but this problem was due my DNS settings, more

{
"did": "did:plc:my-did-here",
"handle": "handle.invalid",
"displayName": "Roberto",
"followsCount": 0,
"followersCount": 0,
"postsCount": 3,
"indexedAt": "2023-12-02T11:23:22.915Z",
"viewer": {
"muted": false,
"blockedBy": false
},
"labels": []
}

I assume my server has this in its DB. But how do I update it? If possible. Thanks.