ATProto: implement com.atproto.repo.getRecord, listRecords

[snarfed]

These should be straightforward. We already have com.atproto.sync.getRecord anyway! Thanks for the nudge @bnewbold.

[imax9000]

+1 on com.atproto.repo.getRecord specifically.

This is important for moderation purposes: in the report client only sends at:// URI, not the post itself, and my backend relies on com.atproto.repo.getRecord to fetch the content.

[snarfed]

Understood! Out of curiosity, is your backend a PDS? A mod service? Something else?

[imax9000]

"backend" in this case is an adapter from atproto to a ticketing system. Previously we used a forum channel in a dedicated Discord server, but now I've migrated everything over to an https://www.openproject.org/ instance.

I don't have the code public at the moment, but happy to answer any questions.

---

All in all, after getting a report, it uses getRecord and getActorProfile for fetching extra info that is then used to format the ticket description.

[snarfed]

Fascinating! Got it. (And I assume you mean app.bsky.actor.getProfile?)

In general, I don't plan to implement many PDS-level XRPC methods, whether com.atproto.repo.* or app.bsky.* or any others, because BF isn't a PDS that users log into and use. So for methods like getProfile, you'll probably need to talk to the AppView instead of atproto.brid.gy. getRecord and listRecords do make sense though, I'll happily implement those. (And you can always do getRecord of app.bsky.actor.profile/self instead of getProfile if you really want to talk to BF instead of the AppView.)

[bnewbold]

We should probably decide and document what constitutes a minimum-viable repo-hosting-service in the network, eg "minimal PDS" versus "full-fledged interactive PDS".

Should only need to implement endpoints from com.atproto.*:

• com.atproto.admin.*: don't need to implement any of these specifically, but do need to the functionality of updateSubjectStatus and deleteAccount, aka the ability to takedown or delete accounts
• com.atproto.identity.*: maybe these are a stretch in the context of a bridge, so this isn't a statement about bridgy fed specifically, but overall we consider any PDS that doesn't allow migration for regular user accounts to be violating the spirit/values of the protocol. probably should implement resolveHandle, not sure if it is "MUST" or not
• com.atproto.label.* and com.atproto.moderation.*: not relevant/required
• com.atproto.repo.*: getRecord an listRecords should probably always be implemented (may end up being a formal "MUST"). describeRepo is a little weird and maybe needs iteration, but i'd recommend implementing today. listMissingBlobs also helpful, not sure if "MUST"
• com.atproto.server.*: describeServer probably required
• com.atproto.sync: getRepo, getRepoStatus, subscribeRepos, getRecord, getBlob, listRepos, listBlobs. probably also getLatestCommit, getBlocks.

For now we're being pretty permissive. It is possible in the future the ecosystem will want to apply more pressure for implementations to meet a minimal implementation bar, but that is probably a question for the standards body process or general ecosystem governance.

[qazmlp]

It's just my two cents, but it would definitely be nice for Bridgy Fed to support migration (of followers at least, though converted data exports would be "nice to have" where that's feasible, maybe better as a largely separate service).

Off-migration would give some assurance for people that they wouldn't lose their connections if something goes wrong with the bridge (short of a sudden long outage, at least) and symmetric¹ migration between networks would enable much greater mobility of experience, so to speak.

I'm not sure fully symmetric migration is actually possible, though, due to potential protocol differences… On Bluesky, is it possible to "merge" multiple accounts into one through migration? On ActivityPub, that is the only supported migration option.

Footnotes

1. asymmetric migration between networks is something I suspect many people would have strong misgivings about ↩

[imax9000]

Fascinating! Got it. (And I assume you mean app.bsky.actor.getProfile?)

In general, I don't plan to implement many PDS-level XRPC methods, whether com.atproto.repo.* or app.bsky.* or any others, because BF isn't a PDS that users log into and use. So for methods like getProfile, you'll probably need to talk to the AppView instead of atproto.brid.gy. getRecord and listRecords do make sense though, I'll happily implement those. (And you can always do getRecord of app.bsky.actor.profile/self instead of getProfile if you really want to talk to BF instead of the AppView.)

Yeah, I'm not doing anything odd with the request routing and send them through home PDS, like the rest of the clients do. So app.bsky.actor.getProfile gets handled by the AppView, but repo.getRecord gets sent to atproto.brid.gy which currently errors out.

[snarfed]

It's just my two cents, but it would definitely be nice for Bridgy Fed to support migration

Yes! That's #330, following up there.

[snarfed]

Done: We now support com.atproto.repo.getRecord, com.atproto.repo.listRecords, and most of the other methods that @bnewbold mentioned above. Thanks again Bryan! Here's our complete list:

• com.atproto.repo
  • describeRepo
  • getRecord
  • listRecords
• com.atproto.server
  • describeServer
• com.atproto.sync
  • getBlob
  • getLatestCommit
  • getRecord
  • getRepo
  • getRepoStatus
  • listRepos
  • subscribeRepos

The notable ones we're currently missing are com.atproto.identity.resolveHandle, com.atproto.repo.listMissingBlobs, and com.atproto.sync. Also com.atproto.repo.importRepo, I guess, which is #1137.

(arroba supports more, eg auth/session and writes.)

[imax9000]

Is this already rolled out to prod?

[snarfed]

@imax9000 yes!

[imax9000]

Thanks! Then I need to do some debugging on my side to figure out why reporting fails