Ryan Barrett

you're right! the bridgy work is largely done, in that commit. deploying to production is currently blocked on a [handful of pixelfed bugs that affect both backfeed and publish](https://github.com/pixelfed/pixelfed/issues?q=is%3Aissue+author%3Asnarfed). fortunately...

[interesting news](https://chat.indieweb.org/dev/2020-05-28/1590648527037900): > [dansup] After some thought, I've decided to add Webmention support to Pixelfed, users will be able to opt out) > ... > [snarfed] dansup++ webmention support in...

Sure! I haven't followed its evolution. How do you think we should revise this?

[Looks like at least half of them do.](https://github.com/pixelfed/pixelfed/issues?q=is%3Aissue+author%3Asnarfed)

Hey @dansup any chance you could look at the bugs ^ blocking Bridgy Pixelfed support? I'd love to get this moving again! ...or if you're close to shipping built in...

thanks for filing! specifically, the problem here is publishing to twitter. twitter has a [5MB limit on images](https://developer.twitter.com/en/docs/media/upload-media/uploading-media/media-best-practices#image-specs), so bridgy checks the source image file's `Content-Length` HTTP header before uploading...

@Ryuno-Ki true! sadly no, they don't hit the file system. bridgy streams them in memory from the HTTP response directly to the twitter upload API request.

ugh, i forgot the bigger reason i need `Content-Length`: [twitter requires the file size in bytes before i can start uploading](https://developer.twitter.com/en/docs/media/upload-media/api-reference/post-media-upload-init#parameters). @jgmac1106 any chance you could annotate your `u-photo`s with...

[i asked about this in the Flickr API discussion group.](https://www.flickr.com/groups/api/discuss/72157714359969377/)

no answers in the discussion group. not sure what to do next. 😐