Consider raising the size limit of blobs

[davidcelis]

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

When I was first working on my code that cross-posts to Bluesky from my website, I was surprised to discover an undocumented blob size limit of 976.56 kilobytes. This is… quite small 😅 Compare this with Mastodon which, as of v4.2.0, allows images that are up to 16 megabytes in size and approximately 7680x4320 in resolution.

Describe the solution you'd like

I'd really like Bluesky to be able to accept larger images.

Describe alternatives you've considered

The only alternative is heavy compression or size reduction for basically any photo taken with a camera or phone made in the last decade. I currently do this, but it seems reasonable for a modern social network to be able to accept photos taken with modern cameras without needing too much processing.

Additional context

I'm not necessarily suggesting that Bluesky raise their limit to something like 16 MB (Mastodon only recently raised theirs to this from 8MB earlier this year), but a limit that's under 1 MB feels artificially small to me 😅

[bnewbold]

It's true that our documentation for the app.bsky API schemas is not yet as good as we'd like, but this limit (one million bytes) is in the schema here:
https://github.com/bluesky-social/atproto/blob/main/lexicons/app/bsky/embed/images.json#L24

Technically, part of the Lexicon app schema "social contract" is that values like this can not be changed in-place. Either a new record version would be needed, or in this specific case a new version of the image embed (the post record embed field is an "open union" and new embed types can be added in a backwards-compatible way). Otherwise alternative clients and software might be running with the old schema, and clients would see inconsistent behavior throughout the ecosystem (eg, some hosts allowing larger images, some not). We are still in a maturity window where we might consider a small breaking change like this though.

I'm not sure what the latest product thinking on this limit is, but I remember that we came up with this number originally after some discussion, it was not a totally arbitrary number. cc: @pfrazee

[davidcelis]

Ahh I had no idea that the schema would be where I'd find that, but it makes sense. Thank you, and thanks for considering the request!

[pfrazee]

We were aiming for a size that would propagate efficiently through the network and not lead to bad load times

[ulrischa]

Kind of frustrating is the difference in using the api vs the website. On bsky.app I can post much large images

[bnewbold]

I believe what is happening there is that the web app (javascript) is resizing the image before uploading.

[TahomaSoft]

What are the current image formats acceptable? I'm not able to find that in the Lexicon.

JPG I know are allowed; other image formats I am not sure about (do they need to be converted to JPG).
GIF support is coming, but not yet available? And videos are currently not allowed, but also in the works.

Is this correct?

Thanks,

Erik

[bnewbold]

Lexicons allow constraints on the MIME type of uploaded content. In the case of embedded images in the bsky.app lexicons, the constraint is image/*, which means that the file must have a MIME type starting with image/. MIME type detection is a bit subtle and fuzzy, meaning this isn't a perfect filter in all cases, and we don't actually allow every possible image type. In practice, I believe we allow JPEG, PNG, WEBP, and GIF. The files are stored as-is in the PDS, but usually resized and stored in a CDN for display in apps, and they may all get converted to JPEG as part of that process.

[TahomaSoft]

Very helpful, thank you!

[net-tech]

Sorry, but have there been any changes as to the status of raising the limit from 1 MB?

[bnewbold]

Not yet, sorry. It is something we have been tracking and discussing internally. Both in terms of a specific limit we think the bsky app should support (uploading and displaying), and about potentially making the Lexicon system more flexible about blob sizes. Some things, like the 300 char bsky post length limit, we consider opinionated constraints that define the medium. Some things, like image upload size, are just choosing a cost/performance balance at a point in time, that will inevitably evolve in the future; the Lexicon system would ideally be flexible to that evolution.

We are working on adding video support, and there is a decent chance we'll make a change to image limits at the same time we roll out video support (not a promise though).