Checked Existing

• I have checked the repository for duplicate issues.

What enhancement would you like to see?

Remove, or at least improve, the "duplicate post" checks used by both miiverse-api and juxtaposition-ui. They are flawed and there are likely better ways to handle this

Any other details to share? (OPTIONAL)

Overview

Both servers implement a "duplicate post" check when making a new post. The server checks to see if a duplicate post is being made, and then rejects the request if one is found. The reason for this check, as stated by Jemma on Discord, is:

Duplicate post checking is unfortunately a necessity. Regardless of rate limits, the browser has this issue where someone pressing the submit button repeatedly submits exponentially more and more requests. It appears to be a flaw with this version of webkit. I've considered moving the post sending logic over to js so I can prevent duplicate requests, but it's not something I've tried yet

However I don't fully agree with this, and the checks in place are very flawed

Issues

Both servers implement getDuplicatePosts identically, so I'll only be referencing the one found in miiverse-api as it's typed. The current getDuplicatePosts is as follows:

The only checks it performs are:

• Same sender
• Same text content
• Same painting
• Same screenshot
• Has no parent
• Is not removed

While at first glance this seems fine to check if a post is the same, it fails to take into account 2 very important pieces of information; the community and the creation time. These checks would prevent someone from making the "same" post in a different community, and regardless of how much time has passed. For example, someone could create a post saying "I love this game" in the Super Mario Maker community, and then 3 years later make a post in the Mario Kart 8 community also saying "I love this game", and the server would flag it as a "duplicate post"

These checks also fail to consider edits. We do not implement post edits at this time, but if we do add them then editing a post would also bypass the check (I am aware that these checks could be updated to support edits in the future, but the point here is the highlight that the current checks are too simplistic in general). I know the stated reason from Jemma is to try and prevent a bug in the WebKit client, however from a security perspective this also isn't great. Depending on how a theoretical edit endpoint would look, someone looking to spam the same text over and over could simply

• Create post
• Edit the same post to change one thing (add a period, make a letter capital, etc.)
• Create post with the same original text
• Rinse and repeat in an endless loop

Since it also does not consider edits, it means that someone could do something such as:

• Make a post
• Edit it to fix a mistake
• Try to make a new post later on/in a different community using the same text the 1st post was edited to
• This is flagged as a duplicate post

Fixes

Ideally this whole check should just be removed, and replaced with other preventative measures. I have never seen another platform do duplicate post checks like this before, I can go on Twitter, bsky, Facebook, etc. and make the same post back to back to back all day without any issue (outside of maybe being flagged as bot after a while, but it's not the post content themselves in those cases it would be the spamming of requests)

I do not agree that the issue happens "regardless of ratelimits", personally. A ratelimit, properly implemented, would just outright block the request without doing anything if there have been too many requests within a specified amount of time. This seems like the most straightforward way to handle the issue Jemma originally described; people hitting the "post" button multiple times (which I assume means "multiple times very quickly")

Modifying the client to just disable the post button once it's hit would also fix this issue for normal users, as there would then be no way to trigger multiple requests to begin with. This would not stop someone using a custom client/script, however a normal ratelimit setup would if implemented sufficiently