Closed snarfed closed 10 months ago
Did a little digging into this this morning:
base_id
for Bluesky in Granary in order to have it resolve URLs to AT URIs.web_url_to_at_uri
function we already have, which for this post returns a post like this:
at://joelotter.com/app.bsky.feed.post/3kciw4eeuzc2x
app.bsky.feed.getPostThread
on this returns a 404. Replacing joelotter.com
with the DID makes it workbase_id
is a static method and so presumably doesn't have access to our client...thoughts?
- This is a valid AT URI per the spec! However, it appears the Bluesky API can't actually resolve that handle to a DID. Doing
app.bsky.feed.getPostThread
on this returns a 404. Replacingjoelotter.com
with the DID makes it work
Interesting that getPostThread
chokes on it! Hmm. This kind of surprises me; I've filed https://github.com/bluesky-social/atproto/discussions/1778.
For our purposes, we can resolve handles to DIDs with either com.atproto.identity.resolveHandle
, against PDS or BGS or AppView, or by doing handle resolution ourselves with eg arroba.did.resolve_handle
. I'm not sure if I have a preference between the two yet.
I'm therefore slightly unsure how to resolve this DID given
base_id
is a static method and so presumably doesn't have access to our client...thoughts?
Totally ok to change base_id
to a class method if necessary! Should be backward compatible.
Interesting, thanks! I asked about it in the Bluesky devs matrix chat and got the following info:
Looks like the current implementation looks at the local PDS database so it would only find the thread if it is synced to the PDS.
To decide if a PDS should pull the post from joelotter.com's PDS would be a matter for the local PDSs allow/deny list of PDSs it is willing to resolve content from.
Seems we don't actually use arroba yet in Granary! Am I ok to add it as a dependency - should I have it install from Git or from Pip?
Hah funny, I'm in the Discord but don't really follow the matrix chat, it tended to seem more theoretical and less hands on...which fits the answer here. That answer may technically be true, but doesn't really matter since federation isn't on in prod yet, so there's only one PDS, which has every post and thread. Not to mention the AppView, which is expected to have most/all posts, even after federation, has the same problem. Both are pretty clearly requiring DID-based at://
URIs right now. 🤷
Seems we don't actually use arroba yet in Granary! Am I ok to add it as a dependency - should I have it install from Git or from Pip?
Hmm. On second thought, base_id
currently doesn't make network requests, and I'm a bit reluctant to have it start. I wonder if there's a different place to do this that would be less invasive there?
Could it resolve in the original post discovery? I fear we might still end up doing it in web_url_to_at_url
though which gets called from all over presumably
Looks like it's not actually used anywhere yet. I'll see if I can make the change :)
Hmm yeah. And web_url_to_at_url
probably shouldn't make network requests either.
So this specific issue is unrelated to original post discovery, but in both cases, we primarily care about normalizing URLs for the user's own posts. We already have the user's handle and DID, so how about we start small: in original post discovery and the discover task, we look for the user's handle specifically, and if it's in the URL, convert that to DID. Otherwise, we do nothing.
I'm down to try to do more unified global conversion of bsky.app URL => at://
URIs and handles => DIDs, but I'm not sure we quite have a handle on the best approach yet.
(Also fwiw Bridgy Fed uses web_url_to_at_uri
, https://github.com/snarfed/bridgy-fed/blob/ea08bd91538e26da3b295a10999e7191cfd6ca13/atproto.py#L158 , but that hasn't shipped yet so it doesn't matter.)
Sounds good - should I do that in post_id
do you think?
Or base_id
really I should say
Wait I reread your previous comments, never mind, will need to add a new source method!
Just thinking, is this something where the "right" thing to do is actually to implement UrlCanonicalizer
properly for Bluesky? Then this becomes trivial, probably
Yeah I've been thinking about that! The problem is bsky.app vs at://
. I expect we don't always want Bluesky's UrlCanonicalizer
to convert bsky.app URLs to at://
URIs, but sometimes we do...?
This is one of those things where it's easy to do but hard to do right. I'll put something together now though we may want to revisit this as you say!
Confirmed fixed! Thanks again @JoelOtter!
First Bluesky bug! Congrats and condolences @JoelOtter 😎. Looks like the discover function, ie the "Resend for post" form on the user page, is unhappy. Caught by our crash reporter; I've added you to the Google Cloud project, you should be able to see it at https://console.cloud.google.com/errors/detail/CKDu3sTr_biL4AE;time=P30D?project=brid-gy if you log in with your Google account.
Stack trace:
Full logs from one request: