createRecord should return a view of the record

[GreenFootballs]

It would be very useful if the com.atproto.repo.createRecord endpoint returned the actual record in full, instead of just the CID. Both Twitter and Mastodon do this when creating a new post.

[dholms]

Hmm I'm not necessarily opposed but what's the usecase?

You supply the record itself as an input so it seems that that's already available to the client

[GreenFootballs]

Yes, you have the raw data of the record, but having the resulting data structure that's actually stored in the repo with all of its metadata would be useful for rendering posts, extracting stats, saving a user's post history, etc., just to name a few possibilities. Otherwise it requires a second call to the API to get the record you just posted.

[dholms]

The resulting record that is stored in the repo is the exact input that you give you repo.createRecord. The only modification it makes is adding on the $type if that wasn't present to begin with

[GreenFootballs]

But what about uploaded images and other types of embedded content? That's what I meant by metadata, it's created when you create the post, with URLs on whatever server is being used. If you want to reference it later, by rendering and displaying posts for example, you need to make another call to the API to get the data, if all you have is the CID.

[dholms]

ohh so the post view not the record itself

If we did this, it would need to be optional since you're able to create records on the PDS that your PDS does not necessarily understand (and therefore cannot create views for)

I'm inclined to leave as is for now for simplicity's sake

[bnewbold]

com.atproto.repo.createRecord is application-agnostic; it lives under the com.atproto.* namespace. I really don't think that it should return an application-specific view from the app.bsky.* space.

Maybe we could avoid the network round-trip another way, like Cap'n Proto's time-traveling promise pipelining? https://capnproto.org/rpc.html

[myConsciousness]

It would not be necessary for com.atproto.repo.createRecord to return the actual record object it created.

Considering the use case of using this endpoint in our app, before using com.atproto.repo.createRecord we already have the record data to be created in a specific structure. So even if this endpoint returns a record that was created, it is only a duplicate of the data we sent to this endpoint.