4 ms·

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 ser

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 https://toucanpost.com [2]: https://github.com/mackuba/didkit https://github.com/mackuba/didkit

Tomuus 1y 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-resolution https://atproto.com/specs/lexicon#lexicon-publication-and-re...
- danabramov 1y 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.bsky.feed.post/3m2e3z65ark2n#info https://pdsls.dev/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/app.... [2]: https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com.atproto.lexicon.schema/app.bsky.feed.post https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com....
verdverm 1y 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

Tomuus 1y 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-resolution https://atproto.com/specs/lexicon#lexicon-publication-and-re...

danabramov 1y 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.bsky.feed.post/3m2e3z65ark2n#info https://pdsls.dev/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/app.... [2]: https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com.atproto.lexicon.schema/app.bsky.feed.post https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com....

verdverm 1y 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