So you should take this with a grain of salt since it has opinion, forward speculation, and is more implementation guidance then protocol but...

You probably don't want to do cross PDS traffic in response to a search.
It has performance and security concerns.
Of course you could hit the endpoints intended for clients, that is the web2 we all know and love but sync is the interesting part of the protocol. The content controllers are all over but your client gets data from your PDS.

When a client does a search for a DID that is not in a PDSs database it may just put that DID in a crawl list. Some background processes that are rate limited can crawl the wavefront without bothering the servers with lots of crawling traffic.

Think about how Google responds when you Google a URL it has never crawled or indexed. It doesn't do a live crawl and index before responding to the search it just added the url to the known or suspended URLs list.

If someone is doing searches for say did:web:victim.example:user:<nonce> they could make up endless random did:webs and submit them to many many PDSs to send a flood of PDS traffic to DDOS the site.

Better to just add a new DID to a rate limited crawl and if the crawl finds a valid DID and it to the index then. If the DID leads to a new PDS then you will want to check the reputation of that PDS before you start syncing with it. There is just a lot to do that's worth doing async and not holding up a search result that could just honestly respond "did:web:whatever was not in the index" is probably not worth the effort.

If everyone here starting to ask for invite code, this channel will be "Bluesky Invite codes", not "Bluesky Dev".

16384 dids in

plc.directory

So... could we implement

• A dedicated server that
  • lets you backup your twitter archive (manually)
  • map twitter people 1:1

"signingKey":"did:key:zDnaei7mXSmviqCmsy2VrczRo1Ehtfx9dst9uA88Hb84uTVLa", "recoveryKey":"did:key:zDnaei7mXSmviqCmsy2VrczRo1Ehtfx9dst9uA88Hb84uTVLa"
Probably a good idea next time to have a different recovery key then the repo key 🙂

Also looks like your DIDs are a little long typical we only use the first 24 b32 (120 bits) char of the hash not the full 256 bit hash but that's not a huge deal.

In the future you probably want to have multiple recovery keys. One for your PDS so you can perform recovery for your users and one that the user stores and can use to migrate away from your PDS at any time of their chosing.
Not a great practice to have users that don't have a recovery key because then they are trapped on your PDS

• reporting is an important part of moderation feedback loop, and is the current mechanism for manually applying labels; this will become more flexible

• labels will federate the same as repo commits/content, and will probably be aggregated in a centralized fashion then passed back to PDS and clients

To try this, sign in to https://bsky.vercel.app and then go to https://bsky.vercel.app/followself to follow yourself, go back to BlueSky and look in your notifications and check your follows and followers list, you'll find your own profile in both lists

Or in python with atprototools installed you can just:
from atprototools import Session
bsky = Session(username, password)
bsky.follow(username)

From what I understand the hostname wouldn't change either

BlueSky separates the AT Proto server (PDS) from your identity which is just a domain name e.g.

and if you do forego collection and instead call this xrpc with a type, you get

1234ApiError {
    error: "InvalidRequest",
    message: "Error: Params must have the property \"collection\"",
},

I'm having a hard time getting images to post and I'm not sure what I'm doing wrong but also I might have the details confused. I don't know if Bluesky has restrictions on image formats. I'm finding it hard to find specifics.

12345678910111213141516171819202122await agent.post({
                        text: 'Post Text',
                        reply: {
                            parent: {
                                uri: notif.uri,
                                cid: notif.cid,
                            },
                            root: {
                              uri: notif.uri,
                              cid: notif.cid,
                            },
                        },
                        embed: {
                            images: [
                                {
                                    image: await agent.uploadBlob(qrCodeBlob, {encoding: "image/svg+xml"}),
                                    alt: "",
                                },
                            ],
                            $type: "app.bsky.embed.images",
                        },
                    });