This pull request has merge conflicts that must be resolved before it can be merged.

This is also missing the style changes necessary for this to work

This was intended to be applied only after the Mastodon upstream changes were merged, which would include the style changes.
And now I realize I'm an idiot and we have our styles set up differently

Rebasing soon. Do you have opinions on the design here? I like the new look but we do need to hide follower counts.

This pull request has resolved merge conflicts and is ready for review.

This is also missing the style changes necessary for this to work

This was intended to be applied only after the Mastodon upstream changes were merged, which would include the style changes. And now I realize I'm an idiot and we have our styles set up differently

Yep :D

Rebasing soon. Do you have opinions on the design here? I like the new look but we do need to hide follower counts.

I actually don't like this change that much.
I just don't see how showing a link and follower count is useful.
I'm not sure how to best hide the count as I don't think something like in app/javascript/flavours/glitch/features/account/components/action_bar.jsx would look good.
We could change the ShortNumber component to display "-" when a negativ number is given (as the followers count is -1 when hidden), but I'm not sure if that breaks other stuff, though I'm not aware of any negative numbers in the web UI.
We could also just omit follower counts completely.

I actually don't like this change that much. I just don't see how showing a link and follower count is useful. I'm not sure how to best hide the count as I don't think something like in app/javascript/flavours/glitch/features/account/components/action_bar.jsx would look good. We could change the ShortNumber component to display "-" when a negativ number is given (as the followers count is -1 when hidden), but I'm not sure if that breaks other stuff, though I'm not aware of any negative numbers in the web UI.

Hmmm. This begs the question of how vanilla mastodon displays follower counts in this updated UI for Glitch users that have theirs hidden.
I'm assuming they actually just display the -1 value??? Which seems awful.

Is there an argument here for refactoring the entire 'hide follower counts' feature to return 0 instead of -1?

I think the value proposition for the feature is allowing people to determine at a glance whether a user (especially one who just followed you) is a brand new account, or one without much social credibility.

Though I'll admit I think the verified badge is silly, given that anyone can 'verify' an account using a free webhost

We could also just omit follower counts completely.

This gets my vote; omit the component entirely when we get a negative number back

I actually don't like this change that much. I just don't see how showing a link and follower count is useful. I'm not sure how to best hide the count as I don't think something like in app/javascript/flavours/glitch/features/account/components/action_bar.jsx would look good. We could change the ShortNumber component to display "-" when a negativ number is given (as the followers count is -1 when hidden), but I'm not sure if that breaks other stuff, though I'm not aware of any negative numbers in the web UI.

Hmmm. This begs the question of how vanilla mastodon displays follower counts in this updated UI for Glitch users that have theirs hidden. I'm assuming they actually just display the -1 value??? Which seems awful.

Vanilla doesn't have a hide follower count option. It's glitch-soc exclusive.
Oh, I might have misunderstood that bit.
I actually don't know how hidden counts display on vanilla instances.

Is there an argument here for refactoring the entire 'hide follower counts' feature to return 0 instead of -1?

This would probably cause a lot of people thinking an account has 0 followers instead of them being hidden.

I think the value proposition for the feature is allowing people to determine at a glance whether a user (especially one who just followed you) is a brand new account, or one without much social credibility.

Though I'll admit I think the verified badge is silly, given that anyone can 'verify' an account using a free webhost

I don't think numbers are a good indicator for that and there isn't really a shortcut to just looking into profiles.
I also think a lot of people misunderstand the link verification feature.
It just means you have access to the resource the link points to, which can be used to verify an identity (if you run an established website and want to say "Yep, that's mine"), but that's for upstream to make more clear.

We could also just omit follower counts completely.

This gets my vote; omit the component entirely when we get a negative number back

I would just omit it regardless of the count.
I fear that just hiding it when counts are hidden would make people think something is broken when it's not.

Sorry, I meant to ask what it looks like for a user using vanilla mastodon when they see an account card for a glitch user who has hidden their follower count.

Yeah, that crossed my mind after I sent my reply ^^
I actually don't know.
I can spin up a vanilla instance tomorrow and check.

While the feature is....questionable.... I'm personally disinclined to diverge from upstream unless there is an affirmative reason to.

I mean... that sounds like a good enough reason to me.
I'm personally for diverging. I see a lot of potential for glitch-soc to be an even better alternative for vanilla and not just vanilla with less of the bullshit, which is left on the table by staying so close to upstream.
But I also understand that it would mean more work for Claire when merging upstream changes.
(Trust me, I know the pain, I have to do the same thing downstream...)

Instead of omitting the component maybe we use the "closed eyeball with a slash through it" emoji/icon that is common iconography?

I'm actually not familiar with emojis and wouldn't know what that one is supposed to mean.

While the feature is....questionable.... I'm personally disinclined to diverge from upstream unless there is an affirmative reason to.

I mean... that sounds like a good enough reason to me.

Eh, I don't consider it an affirmative reason. "I don't see the point" isn't a good enough reason in my book :) It would need to be something like "this presents a risk or concern" type deal.

EDIT: To be fair, I'm not even close to an authority on the goals of glitch-soc in terms of removing cruft

I'm personally for diverging. I see a lot of potential for glitch-soc to be an even better alternative for vanilla and not just vanilla with less of the bullshit, which is left on the table by staying so close to upstream. But I also understand that it would mean more work for Claire when merging upstream changes. (Trust me, I know the pain, I have to do the same thing downstream...)

Yeah, this is the tough one for sure; we're gonna need to diverge to some extent either way to handle the case discussed above; just a question of how much volatility we want to add.

I'm actually not familiar with emojis and wouldn't know what that one is supposed to mean.

My reaction to your comment says it all :D I thought this was a pretty universal icon:

I can spin up a vanilla instance tomorrow and check.

Turns out I can't.
Trying to use vagrant just spits out errors and the last time I set up a VM VBox froze my system.
I'm also not risking just running it from source as the last time I did that it nuked my local DB and I need it for testing.
I mean, I could get around that, but it's not worth the effort for me.

I'm actually not familiar with emojis and wouldn't know what that one is supposed to mean.

My reaction to your comment says it all :D I thought this was a pretty universal icon:

The only context I have for that is hiding/showing media attachments, so if I see that randomly in the UI, I would try to click it to reveal what's hidden.

This pull request has merge conflicts that must be resolved before it can be merged.