lexicons: new app.bsky.graph.getRelationships endpoint #2059
Conversation
| "format": "at-uri", | ||
| "description": "if the actor blocks this DID, this is the AT-URI of the block record" | ||
| }, | ||
| "blocks_via_list": { |
There was a problem hiding this comment.
In viewer state it's "blocked" and "blocking". I wouldn't claim it's perfect, but maybe we should be consistent with it?
There was a problem hiding this comment.
mmm, yeah, always get confused by those terms, but consistency is best; updated
| "format": "at-uri", | ||
| "description": "if the actor blocks this DID, because of a mod list, this is the AT-URI of the mod list record" | ||
| }, | ||
| "blocked_by": { |
There was a problem hiding this comment.
Can we switch these fields to camel-case for consistency?
There was a problem hiding this comment.
haha, don't even notice when i'm sssslighering off
|
Updated with camelCase and more consistent naming, and also realized we can put either record type (block record or mod list record) in the at-uri field, so removed the "ViaList" variants. Also set a To capture some earlier discussion: this does make blocks a bit more visible to third parties. This is already public info but there is some friction. This endpoint is intentionally not helpful for bulk-enumeration of unknown relationships, but it does make specific pairs easy to check. This could actually be helpful for some devs, but there might also be abuse cases we aren't thinking of (beyond the existing abuse and drama around blocks being public at all). I'd be ok making this endpoint admin-only for now, but it would make automod less accessible to third parties, so i'd lean towards making it open. |
|
Thinking about it again, let's not tickle the dragon right now, and not make block relationships more accessible like this. This can be an admin-auth'd rought, or actually I don't even need the block info right now for automod, so this could just return follow-graphic info and still be helpful. |
| } | ||
| ] | ||
| }, | ||
| "relationship": { |
There was a problem hiding this comment.
I think we should move this to app.bsky.graph.defs as it's a general description of a relationship & I suspect it may be reused across other lexicons. Thoughts?
There was a problem hiding this comment.
yup, that makes sense!
There was a problem hiding this comment.
pushed a change.
having it be in defs does make the "which of the two actors are we talking about" thing a bit more complex; I tried to clarify that with a description, but i'd be open if you want to include both DIDs in each relationship object (bloats the wire size a bit), or rename the did field to make it clearer.
bnewbold
force-pushed
the
bnewbold/get-relationships
branch
from
5c7c907 to
79e36f9
Compare
This proposes the endpoint schema for a public (not auth'd) endpoint for fetching the public bsky social graph relationships (follows and blocks) between one actor and a list of "other" actors.
The initial motivation is to use this metadata from automod, for example in the context of a reply (wanting to know the relationships with the "root" and "parent" post authors.
If this looks good, would pass off to one of the backend folks to wire up and implement. v2 implementation should be simple, re-using an existing dataplane helper.