Should an agent XRPC call be able to getRecord for an account on another PDS host?

[whatjakecodes]

Context

I have two Blue Sky accounts, let's say Account1 and Account2, to which I am creating custom lexicon records. The records link to each other (for an atproto guild/invite-to-group system).

For Account2, which owns a record with an at-uri field pointing to a record on Account1, the oauth client (via @atproto/oauth-client-node) agent.com.atproto.repo.getRecord call to fetch Account1's record fails. If I create an agent from Account1's oauth session, and call getRecord with the exact same repo/collection/rkey, the call succeeds.

I found the main difference in the XRPC calls is the hostname.
Account2's agent XRPC calls dapperling: https://dapperling.us-west.host.bsky.network/xrpc/com.atproto.repo.getRecord?[...]
Account1's agent XRPC calls button: https://button.us-west.host.bsky.network/xrpc/com.atproto.repo.getRecord?[...]

So it seems Account1 and its data is on button, while Account2 is on dapperling.

It looks like the two accounts are using two different BlueSky PDS hosts, button and dapperling. I want a way to get records from Account1's PDS when my client is logged in as Account2 on another PDS.

Main questions

1. Is this working as intended?
2. Is the system trying to prevent Account2 from fetching data owned by Account1, or data on another PDS?
3. Should I not be relying on fetching data via agent.com.atproto.repo.getRecord when I need data from different accounts?

Here is some sample code illustrating the issue:

// create agent using Account2
await locals.client.authorize("account2.Handle", {scope: 'atproto transition:generic'});

// ... 
// oauth callback creates agent
const { session } = await locals.client.callback(params);
const agent = await getAgent(cookies, session, locals.client);

// ...
// fetch record owned by account1:
const requestQuery = {
	repo: "did:plc:account1DID",
	collection: "custom.record.guild",
	rkey: "rkey123abc"
};

await agent.com.atproto.repo.getRecord(requestQuery);

// above call fails with 400 when logged in as Account2. Succeeds if logged in as Account1.
// XRPCError: Could not locate record: at://did:plc:account1DID/custom.record.guild/rkey123abc

[yamarten]

I'm sorry if you expect Bluesky members to answer the design idea, but I'll write it as a reference opinion.

1. Maybe. At least it's not a bug.
   • By the way, only bsky records exceptionally falls back to their appview. Backport: fallback to getRecord on appview, misc fixes #1210
2. Because getRecord is an open API, the only thing that technically prevents it is the effort of ID resolution.
3. I've never seen Bluesky blame it, but if your service seems to overload PDS, you should cache it in appview.
   • There are already several services that get records directly from other PDS.

[whatjakecodes]

So IIUC, seems like the agent.com.atproto.repo is currently bound to the PDS of the session user's repo, which probably makes sense with repo sitting there in the object name.

Also, from your PR link, I suppose if I had requested a bluesky resource, like a post or profile (instead of my custom resource), the PDS fallback to the bsky appview agent likely would've found that record on the other PDS.

I think I'll lookup Account1's PDS via their DID and then try making an XRPC call (without the oauth agent) for now. In the future I probably will have the firehose syncing things to my appview cache more properly.

[yamarten]

Yes, it's the correct understanding.

Unfortunately, I'm not familiar with SDK, but agent.withProxy may be useful. For example, for me, the following query was only successful when atproto-proxy: did:plc:fzkpgpjj7nki7r5rhtmgzrez#atproto_pds header was attached.

https://lionsmane.us-east.host.bsky.network/xrpc/com.atproto.repo.getRecord?repo=did:plc:fzkpgpjj7nki7r5rhtmgzrez&collection=com.whtwnd.blog.entry&rkey=3kppjro6k6z27

Probably agent.withProxy('atproto_pds', 'did:plc:fzkp...').com... is equivalent to this in the SDK, but I haven't actually tried it.

Note: Since listRecords does not support atproto-proxy, this method can only be used with getRecord. I have not checked third-party PDS implementations or other atproto APIs.