Hacker News new | ask | show | jobs
by angerson 256 days ago
This is a nice write-up. I recently added post-to-bluesky support to my ongoing social-media-scheduler project [1], thinking it would be the simplest of the services to work on, but I ended up getting really confused instead.

DID and handle resolution was the easiest part of ATProto---as the author says, a library can do the job easily. For Ruby it's DIDKit [2]. Where ATProto really threw me was the seeming non-ownership of record types. Bluesky uses "app.bsky.feed.post" for its records, as seen in the article; there seem to be a lot of these record types, but there doesn't seem to be a central index of these like there are for DIDs, or a standard way of documenting them... and as far as I've been able to find, there's no standard method of turning an at:// URI into an http:// URL.

When my app makes a post on behalf of a user, Bluesky only sends an at:// URI back, which I have to convert myself into an http:// URL to Bluesky. I can only do that with string manipulation, and only because I know, externally, what format the URL should be in. There's no canonical resolution.

[1]: https://toucanpost.com [2]: https://github.com/mackuba/didkit
2 comments
Tomuus 255 days ago
Record types are now "on protocol", you resolve them via a similar mechanism as in the article. https://atproto.com/specs/lexicon#lexicon-publication-and-re...
link
danabramov 255 days ago
As an example of that, if you open any `app.bsky.feed.post` in pdsls, the "Info" tab[1] links has a link to the "Lexicon document" for it:

[1]: https://pdsls.dev/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/app....

[2]: https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com....

link
verdverm 255 days ago
> I have to convert myself into an http:// URL to Bluesky

at:// URIs and specific lexicon are not limited to a single app. The NSID (app.bsky.feed.post) has authority based on domain, but Bluesky cannot prevent anyone from reading / writing records of that type.

There are alternative apps that read the same at:// but put them under a different https://...

tl;dr, there is not a 1-1 mapping between at:// and https://, it's 1-N

link