This change replaces the reaction count on the reaction buttons under
the post with micro avatars of the people reacting. This makes the
whole thing feel more personal IMHO.
Performance concerns: because the posts by themselves only contain
reaction counts, this means executing an extra API call is done to
fetch the list of users who reacted. This was already being done when
hovering a reaction button, and my Raspberry Pi is doing pretty fine
despite this patch.
Further development was done to lazify the API call, so now
reaction avatars are now fetched only when the reaction bar
slides into view. This should lower the load a bit.
Borrowed some ideas from code at https://medium.com/js-dojo/lazy-rendering-in-vue-to-improve-performance-dcccd445d5f
TODO: check there might be a glitch when adding a reaction
because it is already in view
This is an attempt at introducing filtering of replies in timeline in the
style of Mastodon or Pleroma's "only replies directed at me or someone I follow".
Currently one way this surely fails is that self-replies by someone I follow in
a conversation solely with someone I don't follow will pass this filter, and
I will see a conversation I don't want to see.
This probably needs more testing to verify that it's doing what's expected of it.
This is my modification of the dark cherry theme, caused by my
annoyance that you can set a wallpaper in the client, but it's
invisible almost all the time.
What I tried to do here is make a lot more things transparent,
so that the wallpaper would be visible more. It also looks nasty
in some situations, but this is an acceptable tradeoff for me
personally.
I only use Safari (and sometimes Firefox, but not much), and I do not
particularly care for visitors to my instance, so this is again an attempt
at allowing the compiler to be more reckless wrt polyfilling to minimize
generated code.
The context menus provided by Misskey, overriding the browser context menus
on right click, were driving me very angry. This makes it much easier to copy
image URLs or even just do a quick "Inspect element".
Side victims: the reaction picker context menu feature. I never used it, so
I am only guessing what it was doing, but since I removed the whole underlying
mechanic, it only felt right to yeet the feature too.
This should also have better latency due to being a single query.
Furthermore, it's no longer a linear scan, since host is indexed.
Would be cool to simplify it further to a single query for blocks also...
Why exactly are blocks not in the db?
It works by having a day-long cache of
"when did we last successfully communicate with this instance?"
Anything over a specified threshold (1 month) will act as though the instance
is suspended - all outgoing jobs are dropped on processing.
The day-long cache is in place because the ordering is necessarily a
linear scan.
Once an instance comes back online, we will detect that is the case as soon as
we receive an activity from them (which will update the "last communicated at")
field.
Potential future TODOs:
* Improve the caching system, it's actually pretty inefficient as it is.
CacheBox with a call override?
* Think of ways to make it not-a-linear-scan, since the instances table can get
pretty big. It's around 4500 on toast cafe.
ChangeLog: Added
