Where are at:// URIs with handles supported?

[snarfed]

Hi all! https://atproto.com/specs/at-uri-scheme says that DIDs and handles are both allowed in at:// URIs for specifying the repo, along with all the appropriate caveats that DIDs are more long-lived and stable. OK.

However, at:// URIs with handles aren't well supported in the app.bsky XRPC API. Eg app.bsky.feed.getPostThread currently 404s handle-based URIs, and getLikes returns 200 with an empty array for likes, while the same requests for the equivalent DID-based URIs return the expected results.

Is that expected? If so, is there anywhere we can document it? I didn't see anything on https://atproto.com/specs/at-uri-scheme .

Thanks in advance!

[bnewbold]

It is mentioned vaguely in the "guidelines" section: https://atproto.com/specs/at-uri-scheme#usage-and-implementation-guidelines

When referencing records, especially from other repositories, best practice is to use a DID in the authority part, not a handle. For application display, a handle can be used as a more human-readable alternative. In HTML, it is permissible to display the handle version of an AT-URI and link (href) to the DID version.

and

In Lexicons (APIs, records, and other contexts), sometimes a specific variant of an AT URI is required, beyond the general purpose at-uri string format. For example, references to records from inside records usually require a DID in the authority section, and the URI must include the collection and rkey path segments. URIs not meeting these criteria will fail to validate.

There is definitely some ambiguity and tension around this topic. Some in the team would support fully dropping handles-in-URIs, some thing the flexibility is worthwhile. At a minimum it is helpful to use handles in URIs for examples, docs, and debugging, and it would be weird to have a separate URI just for those use cases.

Your question specifically is about AT URIs when included as query params to XRPC endpoints though. IMHO we should probably accept both handle and DID URIs in that situation.

[snarfed]

Interesting! Thanks for the background.

Your question specifically is about AT URIs when included as query params to XRPC endpoints though. IMHO we should probably accept both handle and DID URIs in that situation.

That would be nice!

[snarfed]

I hit an example of this just now that the PDS could probably handle better. When I createRecord a reply post with handle-based AT URIs (and valid corresponding CIDs) in reply.root and reply.parent, the post gets created, but it's rendered as a reply to "Deleted post." Example: https://bsky.app/profile/snarfed.bsky.social/post/3kkcufgnsj42k

I then replaced the handles in those root and parent uris with their corresponding DIDs, called createRecord again, and it threaded correctly to the parent: https://bsky.app/profile/snarfed.bsky.social/post/3kkcuietrt42r

Requiring DIDs in AT URIs in record references is totally ok, as discussed above, but @bnewbold should the PDS then return a 400 or corresponding XRPC error when it gets a handle-based AT URI ref? Happy to file an issue if you want.

[bnewbold]

The philosophical issue here is that the PDS should not need to be aware about app.bsky.feed.post, other than verifying the Lexicon schema, when processing that record. Any additional filtering or processing we do in our implementation is kind of off-spec.

I could see us getting stricter in the spec about requiring at-uri in records to be fully-resolved (to DID, no handles), or adding an additional string format for things like at-uri-did-record (which would also enforced that the URI include an NSID and Record Key, aka resolve to a full record, which AT-URI is flexible to).

From a pragmatic standpoint: probably doing this off-spec to prevent broken records would be a reasonable thing to do! Even if other implementations didn't do it, we are large enough to catch broken code/clients faster. We could also be enforcing no future createdAt, and that the root reference in replies is a real post, and all kinds of other stuff.

[snarfed]

Good point that this is app-specific! If only the AppView (and relay etc) were in-process and could surface errors like this synchronously to clients! Separating concerns and services and making more parts of processing async are nice in a bunch of ways, and clearly net wins, but losing the ability to catch and report errors like these in band is an unfortunate tradeoff. https://fed.brid.gy/docs#error-handling