You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
"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.
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.)
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"
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.
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 symmetric1 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
asymmetric migration between networks is something I suspect many people would have strong misgivings about âĐ
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.
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.)
Activity
imax9000 commentedon Jun 17, 2024
+1 on
com.atproto.repo.getRecordspecifically.This is important for moderation purposes: in the report client only sends
at://URI, not the post itself, and my backend relies oncom.atproto.repo.getRecordto fetch the content.snarfed commentedon Jun 17, 2024
Understood! Out of curiosity, is your backend a PDS? A mod service? Something else?
imax9000 commentedon Jun 17, 2024
"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
getRecordandgetActorProfilefor fetching extra info that is then used to format the ticket description.snarfed commentedon Jun 17, 2024
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.*orapp.bsky.*or any others, because BF isn't a PDS that users log into and use. So for methods likegetProfile, you'll probably need to talk to the AppView instead of atproto.brid.gy.getRecordandlistRecordsdo make sense though, I'll happily implement those. (And you can always dogetRecordofapp.bsky.actor.profile/selfinstead ofgetProfileif you really want to talk to BF instead of the AppView.)bnewbold commentedon Jun 17, 2024
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 ofupdateSubjectStatusanddeleteAccount, aka the ability to takedown or delete accountscom.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 implementresolveHandle, not sure if it is "MUST" or notcom.atproto.label.*andcom.atproto.moderation.*: not relevant/requiredcom.atproto.repo.*:getRecordanlistRecordsshould probably always be implemented (may end up being a formal "MUST").describeRepois a little weird and maybe needs iteration, but i'd recommend implementing today.listMissingBlobsalso helpful, not sure if "MUST"com.atproto.server.*:describeServerprobably requiredcom.atproto.sync:getRepo,getRepoStatus,subscribeRepos,getRecord,getBlob,listRepos,listBlobs. probably alsogetLatestCommit,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 commentedon Jun 18, 2024
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 symmetric1 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
asymmetric migration between networks is something I suspect many people would have strong misgivings about âĐ
imax9000 commentedon Jun 18, 2024
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.getProfilegets handled by the AppView, butrepo.getRecordgets sent to atproto.brid.gy which currently errors out.snarfed commentedon Jun 18, 2024
Yes! That's #330, following up there.
xrpc_repo: stop requiring auth for read methods
xrpc_repo.getRecord: encoded returned records as ATProto-flavored DAGâĶ
xrpc_repo.listRecords: encoded returned records as ATProto-flavored DâĶ
xrpc_sync: implement `getRepoStatus`
storage: add load_repos method
xrpc_sync: implement listRepos
xrpc_repo: optimize listRecords on DatastoreStorage
snarfed commentedon Jun 24, 2024
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.repodescribeRepogetRecordlistRecordscom.atproto.serverdescribeServercom.atproto.syncgetBlobgetLatestCommitgetRecordgetRepogetRepoStatuslistRepossubscribeReposThe notable ones we're currently missing are
com.atproto.identity.resolveHandle,com.atproto.repo.listMissingBlobs, andcom.atproto.sync. Alsocom.atproto.repo.importRepo, I guess, which is #1137.(arroba supports more, eg auth/session and writes.)
xrpc_sync: implement getBlocks
imax9000 commentedon Jul 13, 2024
Is this already rolled out to prod?
snarfed commentedon Jul 13, 2024
@imax9000 yes!
imax9000 commentedon Jul 14, 2024
Thanks! Then I need to do some debugging on my side to figure out why reporting fails