Still trying to work out why a photo that includes a hashtag (from Instagram) fails to show as a photo on micro.blog, while a photo without any hashtags shows up just fine.
Anyone have a clue?
I stopped sharing photo posts to micro.blog because they were being duplicated. Pretty sure now that's because the RSS contains the image twice, as part of the CDATA and again as an enclosure. Not sure whether to fix in @WithKnown or ask @help at micro.blog to ignore enclosure.
Updated to latest HEAD of WithKnown and hoping that might solve the multiple-photo problem. Better create a multiple photo post on Instagram, then.
Perhaps you’re not worried about moving from Mac to Windows or from Photos to another library manager, but you should be. Apple has already killed iPhoto in favor of Photos for Mac and lost a lot of functionality when they did. Who is to say they won’t do that again? Or discontinue the Mac altogether some day?
3 min read
One of the developers of Sunlit, a photo-sharing app that is part of the Micro.blog ecosystem, contacted me to say that “the images on your site have a MIME type of application/data”. I’d like to say I understood immediately what the problem was and what it meant, but I had to do some learning first. It wasn’t as simple as the extension, the bit after the filename that indicates whether it is a JPEG or PNG kind of image. Rather, it was about what my server tells your browser about the image.
To backtrack, Known stores all files as blobs
that contain the actual file data, the 1s and 0s. Your browser, when it receives a post from my server, can often sniff out what kind of thing (image, audio, text etc) that blob of data represents and do a good job of showing it to you. Normally, you wouldn’t even notice. One clue is that if you right-click on an image, and ask to open it in a new tab, it actually gets downloaded instead, I suppose because the new tab doesn’t know what else to do with it.
Anyway, I confirmed that the source file for most images did not have an extension (which would have told the browser directly how to deal with it). Most, but not all. Files I had uploaded to my site directly did have an extension and the correct MIME type. The “bad” files had come from OwnYourGram or Quill, both of which are part of the joyful #IndieWeb. They use a standard called Micropub to send things to a suitably equipped website.
It seemed unlikely that both Quill and OYG would fail to send the requisite information to identify a photo, so I went digging into the code that Known uses to decide what to do with a post sent by Micropub. I made a bit of progress but although I could see more or less what was happening, I couldn’t see how to make it right.
Fortunately Aaron Parecki, who built Quill and OwnYourGram (and so much else), was around and gave me the clue I needed to investigate: curl -I example.com/file
.
One beautiful feature of Quill is that if it is sending a photo and if the receiving site has a media endpoint for receiving files (which Known does) it uploads the file, shows you a preview and tells you the location of the file. With that, the curl
command shows that the temporary file has the correct description of Content-Type: image/jpeg
. Once Known has processed the whole post from Quill, though, the file that contains the image shows as Content-Type: application/data
.
Somewhere between receiving the temporary file from Quill and storing it permanently, Known fails to give it the proper MIME type.
I wish I knew enough to discover where the problem lies. Most likely Marcus Povey – who keeps the wheels spinning at Known – will be able to do the needful, now that I have submitted an issue. And Sunlit will be able to share my photos far and wide.