ATProto/api: createRecord should return the URL to the post on success

[codemasher]

Is your feature request related to a problem? Please describe.

Currently the com.atproto.repo.createRecord endpoint returns all sorts of information on success, except for the full URL to the post that was just created.

atproto/lexicons/com/atproto/repo/createRecord.json

Lines 45 to 63 in 8a4d06c

	"output": {
	"encoding": "application/json",
	"schema": {
	"type": "object",
	"required": ["uri", "cid"],
	"properties": {
	"uri": { "type": "string", "format": "at-uri" },
	"cid": { "type": "string", "format": "cid" },
	"commit": {
	"type": "ref",
	"ref": "com.atproto.repo.defs#commitMeta"
	},
	"validationStatus": {
	"type": "string",
	"knownValues": ["valid", "unknown"]
	}
	}
	}
	},

Describe the solution you'd like

It would be great if the full post URL could be added to the output.

Describe alternatives you've considered

The current solution for me is an ugly workaround that includes pulling the handle from the token information and cutting off the last part of the URI that's contained in the response object, which looks something like this:

https://<instance host>/profile/<handle from token>/post/<post id part from URI>

I guess it's easier for the instance server to do this for me instead.

[blowdart]

The atproto bit is just record storage, it has no concept of what a web based uri to view the record might be. That's down to the application that created the record, for example Bluesky records would have a URL that acts as a UI over a view of the record, the WhiteWind blog engine would have its own URL scheme for its own view, over its own records, and so on.

When a record is created, the only thing the underlying API knows about is the uri and cid for the record that has just been created. It knows nothing of the app that created it, or the views and http uris that app may expost to view the record.

To further illustrate that your own building of a URI assumes post records, it wouldn't work for likes for example (although admittedly I do the same thing), but it wouldn't work for a list record, or a feed record.

[codemasher]

So this is more of an issue for your web front end then? Then again, I'd assume if you define an url property here, it would be up to said API endpoints to return the value suitable for however the instance is implemented and depending on the type of record - in case of the current Bluesky API as I described above.

[blowdart]

The way Bluesky approaches it (and I'm sure someone from the team will correct me here if I'm over simplifying it, or I'm utterly wrong).

AtProto Record <- View over atproto record(s) <- UI App.

You don't look at the records directly in the app or web site, you're looking at a view (which usually combines a bunch of things to make a useful thing to look at, so it would up to the UI app to generate a web URI, assuming it is an actual web app.

Let's take a post as an example. You never see a "raw" post in the app. You see a PostView. There's not even a getPost api, the closest is getPosts. Typically what you're seeing is a thread when you think you're viewing a post, via getPostThread.

A view doesn't have a concept of a web URI either, it's still ATUri and Cids. It's up to the viewing app to generate a web URI if one makes sense for its use case, and it is very app dependent.

The assumption of a pattern of https://bsky.app/profile//post// isn't even a written down spec, although the team have stated it's very unlikely to change because it'd break too many things.

But yes, it would be up to something at the Bluesky layer to expose an API to provide you a web uri for a view over AT-Uri if they wanted to. They just haven't :)

[codemasher]

Thank you for the explanation!

The assumption of a pattern of https://bsky.app/profile//post// isn't even a written down spec, although the team have stated it's very unlikely to change because it'd break too many things.

This is what I mean - the instance - however it is implemented - can and should return a value that's suited for however its web view is implemented - given it's applicable for the record. The pattern in my example is just derived from the current bluesky implementation and is certainly not meant to be concrete.

[blowdart]

And you're sort of proving your point why create record can't return a web uri, only an at uri, as the atproto layer has no idea of what app is creating the record, nor how that app refers to the record, be it with a web uri, or something else entirely. You'd have to have a create record at the bluesky layer for that to make any sense architecturally.