neatchee / mastodon Goto Github PK

Steps to reproduce the problem

1. On mobile, navigate to a status with enough replies to make it necessary to scroll
2. Scroll to the last reply
3. Click/tap the react (+) button on the last reply. It should be nearly flush against the bottom of the window

Expected behaviour

Emoji picker opens with its bottom edge positioned at the screen edge

Actual behaviour

Emoji picker is almost entirely off-sceen, having used the react button as its positioning anchor

Detailed description

If the anchor for the emoji picker (emoji button, react button) is too close to the screen/window edge, the picker will float outside the screen bounds and make some of all of it inaccessible

Specifications

neatchee/mastodon/main

Pitch

We added a feature to scale emoji on mouse-over. Make it a user preference in the glitch-soc pop-over

Motivation

User choice is good, and necessary to propose a merge upstream

Steps to reproduce the problem

Viewing the same remote post I reacted from my local instance to with the remote one on the original instance where the post resides, the reaction counts are different. Also, some reactions that are on the original post are missing.

Expected behaviour

Reaction counts should match remotely and locally

Actual behaviour

Viewing the post remotely missing reactions and different counts

Detailed description

Source: https://urusai.social/@pikestaff/109846321571765672

Specifications

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15

Steps to reproduce the problem

1. Enable the glitch-soc "show boosts in local timelines" feature
2. On account A, make a post
3. On account A, pull up the Local timeline
4. In a separate browser session, on account B, boost the post from account A
5. Do not refresh the page

Expected behaviour

Post appears in local timeline immediately when posted, and boost also appears immediately when boosted

Actual behaviour

Post appears in local timeline immediately when posted, but boost does not appear until the page is refreshed

Detailed description

Pretty straight-forward: posts are automatically inserted into the local timeline without a refresh, but boosts (and probably replies?) are not

Specifications

N/A - just build from neatchee/main

Pitch

For stuff like this, I'd love to still get notified, but I'd like it better if the notifications were combined into a single "User1, User2, and x others recently favorited your post"

Motivation

It makes notifications quite hard to read when there are so many favorited items in my notifications column. I'd love to see that they favorited the post in my notifications, but having so many notifications is a bit too much.

Steps to reproduce the problem

1. Keep home timeline open for a bit
2. Notice that every once in a while, day-old posts are inserted into the timeline

I'm not sure if this issue is specific to the user/instance, but it seems to happen with @[email protected] pretty often. I've seen it happen with other users too, but that's the most common one I think.

Expected behaviour

Old posts should at the very least be sorted to be lower in the timeline

Actual behaviour

Old posts appear at the top of the timeline

Detailed description

This is what it looks like

I also managed to also catch it in debugger, so here is the post which got sent over the statuses websocket connection:
https://gist.github.com/deanveloper/6b735b8e38909610363943f981013d49

Which means that the backend is, for some reason, sending old posts through the websocket connection. This might be intended, I'm not quite sure. But I feel like the frontend should at least be sorting the old posts lower.

Specifications

Chrome Version 108.0.5359.125 (Official Build) (64-bit)

v4.0.2+glitch

Pitch

glitch-soc settings "Boosts/replies on public timelines" should be split into separate options for federated vs local

Motivation

Smaller communities may benefit from local-only inclusion, where federated timelines would become too noisy.

Pitch

This is not really a feature request, but it is a suggestion. The somewhat-offensive word "otaku" can be either interpreted as a fan of anime/manga or as a general hobbyist. Depending on who you ask, this could confuse some newcomers and result in the instance's reputation of being inclusive erode away. If the server is for hobbyists or people obsessed with a certain topic besides anime, then say that the server is for hobbyists. If the server is for big anime/manga fans only, then say that the server is exclusively for anime/manga.

Motivation

I got the information about the outdated status of "otaku" from a Quora question: https://www.quora.com/Is-otaku-an-outdated-word-since-the-word-weeb-is-now-being-used.

Steps to reproduce the problem

Not sure if I should be listing this as an enhancement or a bug. I think we'll call it a bug.

1. Type "#genshin"
2. notice that weird hashtags that aren't used much get suggested first
3. "#GenshinImpact" is at the bottom even though it's the most used hashtag of the suggestions

Expected behaviour

We should prioritize hashtags that are used more often

Actual behaviour

We don't seem to? I'm a bit confused here.

Detailed description

No response

Specifications

N/A

Pitch

Allow admins to set "minimum account age" and "minimum account interactions/posts" required for posts by accounts a new user is following to show up on the public timelines

Motivation

There is an attack vector for manipulation by registering dummy accounts for the sole purpose of following accounts whose content you want to spread (e.g. a band wants their posts on federated timelines, so they make dummy accounts on many servers just to follow their band account)

Pitch

Don't show duplicate post boosts on public timelines

Motivation

Seeing the same post boosted multiple times is too noisy for public timelines

Steps to reproduce the problem

1. Make sure "Zoom in on emojis when hovering over them" setting is enabled
2. Click on a status, ie https://urusai.social/@neatchee/109619877251404963
3. Hover over an emoji with that status

Expected behaviour

Emoji should zoom on hover

Actual behaviour

Emoji does not zoom on hover

Detailed description

This is happening because I'm not properly adding the status__content--zoom-emojis-on-hover class to the status which is being detailed on this page. Should be a very easy fix.

Specifications

Chrome, latest (I know the reason this is happening)

Steps to reproduce the problem

1. upload an mp3 in a post
2. preview or publish it

...

Expected behaviour

the mp3 should play in preview and in the post after publishing

Actual behaviour

it doesn't play, hitting "play" does nothing

Detailed description

Uploaded mp3s on Urusai no longer play. This has been an issue for at least several months. They used to play, and I have several mp3 posts I made in the past that worked that no longer do. This issue effects both old mp3 uploads and new ones and happens both before the post is published (the mp3s don't play in the preview mode or on the "edit description" screen to add captions) and after. There is no error message. The mp3 uploads seemingly fine, the post is published seemingly fine, but the mp3 just doesn't play when you hit the play button, nothing happens.

The mp3s seem to play fine on my megalodon app.

Mastodon instance

urusai.social

Mastodon version

v4.3.0-alpha.0+glitch

Browser name and version

Firefox 121.0

Operating system

Windows 10

Technical details

No response

Pitch

Collapsed posts have a static height. Make it dynamic with an upper and lower bound

Motivation

Collapsed posts are either too short to grok at a single line (glitch default) or may be taller than their content at the lines (current urusai behavior). Collapsed post height should be dynamic to fit either the minimum (20px) or maximum allowed (currently 60px)

Steps to reproduce the problem

1. Using the Glitch+Urusai fork of Mastodon (via sakurajima.moe, v4.2.0-rc2+glitch), I send an emoji reaction to a post from an instance using the vanilla version of Mastodon (mastodon.social, v4.2.0).
2. Looking at the the post on the home instance, I refresh the page, check the favourites counter, and check the list of users who favourited the post.
3. After that, using a Firefish instance (via sakurajima.social, Firefish v1.0.3), I send another emoji reaction to the same post on mastodon.social.
4. I come back to looking at the post on the home instance (mastodon.social) and perform the same procedure - refreshing the page, checking the favourties counter, and checking the list of users who favourited the post.

Screencast from 2023-09-22 12-33-58.webm
...

Expected behaviour

Both emoji reactions should have been counted as a favourite for the user on mastodon.social to give a total count of "2" favourites, and both the users from sakurajima.moe and sakurajima.social should have shown up in the list of users who favourited the post.

Actual behaviour

The emote reaction from sakurajima.moe never registers for the user on mastodon.social as a favourite. Only the reaction from sakurajima.social gets registered as a "favourite", giving a total count of "1" favourite..

Detailed description

I tested this function using my main account @[email protected], I posted the test post using a test account for vanilla Mastodon instances @[email protected], and I used my Firefish test account @[email protected] as the closest thing that I have to a control in regards to a Misskey/Firefish/Pleroma/Akkoma user sending an emoji reaction.

The expected behaviour is that the Glitch+Urusai fork should perform the same as Misskey/Firefish/Pleroma/Akkoma when it comes to giving emoji reactions to a post on vanilla Mastodon - converting that reaction into a "favourite" for a user on a vanilla Mastodon instance.

Instead, the reaction from the Glitch+Urusai fork does not get converted into a "favourite" for the user on the vanilla Mastodon instance.

Mastodon instance

sakurajima.moe

Mastodon version

v4.2.0-rc2+glitch

Browser name and version

Firefox 117.0.1 (64-bit) for Arch Linux.

Operating system

Arch Linux x86_64, Linux kernel 6.5.3-arch1-1

Technical details

No response

Pitch

An option in Local/Federated timelines to toggle boosts, similar to the "Show Boosts" setting in the Home timeline.

Home settings:

Local settings:

Motivation

https://urusai.social/@lantana/109619755357242146

Hi! Is there the possibility of making seeing boosts in local optional in the future?

Personally I don't like spending too much time on social media and would prefer to see urusai posts I can interact with to avoid becoming a retoot machine myself

Pitch

Add a customization option in Glitch settings to control how many lines are visible for a collapsed status
Allows users to control how visible a collapsed status is (i.e. fully collapse to minimum size vs just truncate at the collapse trigger length)

Motivation

When the collapse feature is enabled, it can decrease visibility of the those statuses. It has been conveyed that collapsed statuses are naturally ignored because there simply isn't enough content to motivate a user to expand and read the post

Pitch

Add a way to customize which actions appear outside of the ellipsis menu for statuses. Should be similar to the UI Customization for which icons appear at the top-right of statuses, ie a list of checkboxes which determine the actions that appear for a status.

Optionally, it would be nice if we could add a way to combine the favorite and react buttons into a single button. Right-clicking or holding down on the favorite button would then allow for reacting.

Motivation

The timeline UI can get very crowded, especially on mobile after the addition of reactions. This is on a large phone screen too, I imagine this looks even more crowded on smaller phone screens

Pitch

Add a visual indication of a collapsed post to the bottom of the collapsed post (such as a small "tab" that says "vvv Expand vvv") overlaying the faded text

Motivation

It is difficult to spot collapsed posts at a glance when scrolling timelines. The small expand button at the top right of the post blends in with other UI, faded text is subtle, and the glitch-soc setting to add a background to collapsed posts is jarring af.

Pitch

Coming from Issue #38, this will be split into a separate pull request so that the other change can be sent upstream

Motivation

...

Steps to reproduce the problem

1. Someone with custom emoji in their name needs to fav/boost your post
2. look at their display name :(
   

Expected behaviour

should inline the custom emoji

Actual behaviour

doesn't inline

Detailed description

No response

Specifications

n/a

Steps to reproduce the problem

1. Navigate to my instace
2. Get an error

Expected behaviour

The page should load without any errors

Actual behaviour

The page fails to load and returns a 500 error

Detailed description

I get the following error when trying to navigate to ANY page on my instance.

I've went back to vanilla glitch-soc to check what the value for the flavour is, and it is set to 'Default'

web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] method=GET path=/ format=html controller=HomeController action=index status=500 error='NoMethodError: undefined method `[]' for nil:NilClass' duration=8.57 view=0.00 db=1.93
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd]
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] NoMethodError (undefined method `[]' for nil:NilClass):
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd]
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] app/models/concerns/has_user_settings.rb:63:in `setting_flavour'
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] app/controllers/concerns/theming_concern.rb:14:in `current_flavour'
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] app/controllers/concerns/theming_concern.rb:8:in `use_pack'
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] app/controllers/concerns/web_app_controller_concern.rb:25:in `set_pack'
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] app/controllers/concerns/localized.rb:11:in `set_locale'
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] lib/mastodon/rack_middleware.rb:9:in `call'
web_1        | [a79c1a62-82a4-4525-aa91-a5fecfaa6afd] lib/public_file_server_middleware.rb:18:in `call'

Rolling back to 5d00aabf563d66c4998b3897bf6475d1452ba704 fixes the issue.

Specifications

Redis: redis:6.0-alpine
Mastodon: neatchee/mastodon:4b9f8f7402c9a3a2e3b3bd631bd951281cb3b213 - latest at the time of writing

Steps to reproduce the problem

Builds are failing Lint

Expected behaviour

Linting succeeds

Actual behaviour

Linting fails

Detailed description

No response

Specifications

Mastodon | 4.1.0+glitch
Ruby | 3.0.4p208
PostgreSQL | 15.1
Redis | 6.0.16

Steps to reproduce the problem

1. Updated to the latest docker image (767f4ce01f1b updated to 6fbbad996b9e)
2. Ran migrations (nothing changed, as far as I can tell)
3. Received 500 error on the Mastodon WebUI (and in the logs)

Expected behaviour

Timeline should get loaded

Actual behaviour

Received an Internal Server Error

Detailed description

I'm receiving the following error after I pulled the latest image:

web_1        | I, [2023-07-20T13:59:03.233935 #11]  INFO -- : [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] method=GET path=/api/v1/timelines/home format=html controller=Api::V1::Timelines::HomeController action=show status=500 duration=296.60 view=0.00 db=82.90
web_1        | F, [2023-07-20T13:59:03.234853 #11] FATAL -- : [e30bd847-d15a-4d0a-9df1-7df64ff1cd37]
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] ArgumentError (missing keywords: :records, :associations):
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37]
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] app/models/status.rb:309:in `new'
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] app/models/status.rb:309:in `reactions'
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] app/serializers/rest/status_serializer.rb:153:in `reactions'
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] app/controllers/api/v1/timelines/home_controller.rb:14:in `show'
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] app/controllers/concerns/localized.rb:11:in `set_locale'
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] lib/mastodon/rack_middleware.rb:9:in `call'
web_1        | [e30bd847-d15a-4d0a-9df1-7df64ff1cd37] lib/public_file_server_middleware.rb:18:in `call'

Specifications

neatchee/mastodon docker image (6fbbad996b9e)

Pitch

Passkeys are a relatively new authentication system that makes it so that passwords aren't required. Would be cool if we allowed passkey authentication as an alternative to passwords!

This is probably going to be a pretty big feat since I have no clue how passkeys actually work... LOL. Here is a demo for passkeys, they're essentially a method of authentication where the browser will send a notification to your phone, and asks for a biometric from your phone.

Motivation

Passwords are... quite bad. Not only are they only a single factor of authentication, but they are also quite susceptible to being cracked, and all sorts of attacks.

Passkeys solve this by using public/private key authentication, meaning that even if a data breach occurs, the hacker would only get public keys which are next to useless for stealing credentials.

For the record I'm mostly just making this ticket for myself to track research on what this would look like. There's also a ticket on mastodon's issue tracker here: mastodon#20383

Pitch

From https://urusai.social/@rosey/109776331068351248

This proposes 2 things:

1. A "reactions list page", similar to {statuslink}/favorites or {statuslink}/reblogs which shows who reacted with what
2. Adding the information about who reacted to the post to the tooltip of the reaction

I think we can just add this information to the title attribute of the reaction, no need to go all-out like discord does with a whole overlay+tooltip system (for now).

Motivation

It's great to know who reacted to things!

Pitch

When either of the "show public boosts of public toots" settings are enabled, don't include boosts of posts made by other local users

Motivation

Anything posted publicly by a local user will inherently be on the local timeline already; don't show boosts for it.

Pitch

Multiple theoretical components to this feature:

• Small 'quote-like' box at the top or bottom a reply
• Opt-in/out options for the entire feature, as well as individually for 'show first N characters of post' and 'show username'
  • "Replying to : This is the first 45 characters of the post bei..."
  • This is a setting for the user being quoted NOT the user doing the quoting
• Default 'on' for local users but hard-coded 'off' for remote accounts; never quote a remote account that can't opt in/out
• Sanitize content before quoting; do not include mentions, media, links, etc; only simple text
• Other privacy focused elements? This needs to be extremely hardened if we're going to do it

Motivation

With the ability to push replies into public timelines, usefulness is diminished when replies show no context from the post being replied to. It'd be great to find a non-invasive/privacy-breaking way to allow replies to include very limited context of the post being replied to