This sounds like a bug with the Markdown parser. That's non-standard behavior for the markup language.

That said, I know this isn't Flickr Support, but Flickr typically recommends using the share URL for linking to photos, not the URL you see in your browser's omnibar. You can find it in the Share dialog, by clicking the Share icon next to the Fave star. In this case, the share URL would be https://flic.kr/p/2jnwDc .

That should actually solve the problem until the bug is fixed.

I'd be wary of that, even though I want it as well. APNG is only supported by Gecko and Webkit browsers, like Firefox and Safari respectively. Anyone running Chrome, Opera, Edge, or IE sadly wouldn't see any sort of animation.

I'll agree with this, but please include an option to disable the animations, if possible. Not everyone is on a powerful device, and a lot of animated icons will really push low-end mobile phones and tablets.

I want to see this as well, but please, don't allow people to micromanage the formatting of their own stories like SoFurry. The ePub files that SoFurry makes from those stories are barely readable at best, and unusable at worse. It's made even worse when you can't override the font-size and font-family chosen by the author...

As I recall, the Kindle is the only device line that can do this, and epub isn't supported on the platform. Only Mobi files, and Amazon's proprietary format.

IP bans are more destructive than helpful. IPv4 addresses are limited, and most ISPs cycle people through the limited addresses they have regularly. Because of that, someone could easily wind up with an IP address that was banned previously, and without any warning.

Well, opt-in/opt-out depends on the browser, as it's set on the browser side. No need for FN to do anything in that regard.

Honestly, I would suggest the more common (and widely accepted) Share Icon: https://en.wikipedia.org/wiki/Share_icon

The share icon is used on many sites as a way to denote sharing with other users.

I may not work for the site, but as someone who's administered communities in the past, I can honestly say that this isn't exactly trivial. In fact, it's nearly impossible. from a development and user experience standpoint.

1) If you block people from seeing your profile, comments, etc... they can easily see such information by simply logging out. This is how simple it would be on sites like FurAffinity and the like.

2) If you add the ability to block unregistered users from seeing your profile, they can simply register a new account using a throwaway email address (which are trivial to obtain through GMail, Outlook, Yahoo, etc...). At that point, you would have to block any new account they make.

There is one solution that works, and it's what Twitter uses for protected accounts: whitelisting. For someone to follow what you do, you would have to allow them access yourself, and do so knowingly. This allows you to pick and choose who sees what you do. It tends to be a hassle for those who use it, but it's the only thing that would do what you're looking for without having loopholes to get around it.

I agree that TFA would be nice, but remember that not a lot of people will use it. Multifactor authentication is an outright pain to use (speaking from experience), and if you have any plans to implement APIs for mobile and desktop apps, that becomes an even bigger hassle with app passwords and such.

TFA is also very user-unfriendly if there's no way to recover the account upon losing the second factor (Dropbox, GitHub), but opening the option to recover the password is also a security problem since you simply need a place to send a recovery key or something.

It's a massive double-edged sword, but one I wouldn't mind seeing on FN (even if I might not use it).