aidan

former girlboss in chief

one quarter of @staff! i make the website look good and/or bad depending on your personal taste


here's my website
www.aidangrealish.com/

staff
@staff

Happy new year! This week’s patch notes are a bit short since we were out for a full week and are currently onboarding @kaara, so most changes are Behind The Scenes to make its job as moderator easier! That said, we’ve got a couple treats in here.

bugs to watch out for

There’s currently a known bug where pinned tags on private pages are visible to people who don’t follow the page (but only the fact that they’re pinned, not any of the posts in the pinned tags). This was an unexpected oversight; until tag pinning was introduced, all information associated with a page itself was world-visible. We’re working on fixing this right now, and we’ll let you know when it’s fixed.

patch notes

  • You can now set up muffled tags to automatically collapse any posts with given tags!
  • Cohost Plus! members can now enable .beat timestamps!
    • 12% of cohost Plus! subscribers have enabled this feature!
    • in other news, 12% of our paying customers are known sickos. (yes…ha ha ha…yes!)
    • jae is proud to count themself among this 12%.

  • We’re currently testing changes to how we serve thumbnails in posts
    • Currently, we serve the full-resolution version of any attachment at all times. These images are frequently very large, so we have seen increased bandwidth costs (as well as high data costs for users on mobile plans) as a result.
    • We’re testing serving lower-resolution versions of attachments in a post to save bandwidth. These lower-resolution versions are only shown in the post’s attachment grid and are scaled to be within the maximum size they would ever be displayed at. We still serve full resolution attachments in the lightbox and plan to continue doing so indefinitely.
  • Fixed a bug where very very long words in a post could cause site slowdowns when rendering
    • This was caused by a ReDoS vulnerable regexp in a library we depend on for autolinking. We fixed it on our end and are trying to get a change pushed upstream so it’s not a problem for anyone else.
  • Fixed some issues related to the dreaded Tag Slug

That’s all for this week!

coming up on cohost

We’re working on more behind-the-scenes stuff, so next week’s patch notes will likely also be kind of light. Here’s what’s coming up:

  • jae: make the moderation UI better
  • colin: fixing the private page pinned tags bug, then dusting off some old developer productivity work that we had to revert because it broke the site
  • aidan: onboarding kara! and also finally getting back to UX improvemence :D
  • kara: getting onboarded, writing too many docs as i get situated
  • jess: add private (just for you!) notes to any page on the website

thanks for using cohost! :eggbug: :host-love:


You must log in to comment.

in reply to @staff's post:

We’re testing serving lower-resolution versions of attachments in a post to save bandwidth

I'm curious, what are the specific plans for this? Does this exempt images under a particular size or filesize? The reason I'm wondering is, pixel art and low-resolution game screenshots, like I post on @compactdiscinteractive, is often heavily optimized and fairly small in size, and would also look worse when downscaled than certain other image types.

seconding this question! the notes mention image thumbnails being "scaled to be within the maximum size they would ever be displayed at", but i'd love to hear more specifics on it. i already post all my pixel art at the exact width (or widths for multiple images) that they're displayed at on desktop so as to avoid the site scaling them up or down at all, and i assume stuff like that, where the images match the display width perfectly, will continue to work the way it already does, but confirmation that this'll be the case would be appreciated.

i just went and checked your page for some examples. every single post i could find, the image was already narrower than the size we wanted to scale it to, so nothing happened. but also, in all those cases, my browser had to do some slight upscaling since the image was narrower than the width the browser wanted to display it at.

for additional context:

  • single image rows are scaled to 675px max
  • two image rows are scaled to 338px max
  • three image rows are scaled to 225px max

like i said, this is currently a test so we might make some additional changes here based on user feedback.

is the width screen-size dependant? i noticed months ago (and wrote a report about it, which got a response!) that for me, image width on the main page is 648px, but on users' pages, it's 649px. i've been sizing my images to match post width on the main page, at least for my computer screen's 1920x1080 resolution

yeah it's fully screen size dependent. the theoretical maximum is 675px but if your screen isn't wide enough to display everything it gets narrowed. consider as well that the majority of mobile phones aren't anywhere near 675px wide, and that any high-DPI displays will also impact displayed resolution

it's been the case since day 1, and since your images are all narrower than 675px they aren't affected by any scaling changes anyway. if you weren't having trouble previously, then you should still be fine now.

these are also just general facts about images on computers. i don't think there is a different platform that would guarantee same resolution display for an image on all screens because that isn't really possible.

i'm aware nothing has changed, i mean that i'm disappointed i've been aiming for pixel-perfect displaying of my art when it's getting upscaled for people with larger displays than mine, and presumably downscaled on smaller displays. there's no optimal width to target, so my art will just look however it ends up looking.

i feel bad that this + other comment threads about the mention of image scaling for thumbnails is making you have to clarify a bunch of stuff. i don't mean to take up staff's energy with concerns outside the scope of cohost's design

makes sense. fwiw we are likely going to add a way to mark a specific image as pixel art so that it gets scaled and displayed using nearest-neighbor and adjacent algorithms

i've been aiming for pixel-perfect displaying of my art when it's getting upscaled for people with larger displays than mine

jae did say this in another post, if it helps:

we don't have it gated on file size b/c it's difficult for us to pre-determine if it's needed in those cases, but at the moment gifs are exempted due to a bug and images are never upscaled. [emphasis mine]

and at least if I'm understanding this correctly, images won't be upscaled after the change either?

hmm. Shouldn't this be solvable with CSS? You wouldn't be able to match the post width but you could make sure your image is displayed with no scaling, it could either be inset in the post or cropped by the post width? Is this an interesting solution to you?

Awesome!

I should also say this explicitly, even though I implied it above by mentioning “abuse”, if you’ve got a good reason for changing image previews that changed the square so be it, thems the breaks when one is relying on undocumented quirks of site layout.

we don't have it gated on file size b/c it's difficult for us to pre-determine if it's needed in those cases, but at the moment gifs are exempted due to a bug and images are never upscaled. since we're only scaling down in thumbnail contexts, it shouldn't ever be noticeable; the actual size your browser renders at is in almost all cases smaller than what we're scaling down to

yep! 675px is the theoretical maximum width that an image can ever be displayed at in post view, although there's only a handful of screen resolutions that'll get you there