Feedback Technical Grievances

  • Twórca wątku Twórca wątku Null
  • Data rozpoczęcia Data rozpoczęcia
  • 🇵🇦 Nuestro primer dominio localizado está en español en kiwifarms.pa. Our first localized domain is on Spanish on kiwifarms.pa.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Wyróżnienie
Emotes stopped working in SneedChat. ":" turns into "wow".
dienull.png
 
This is specifically for the lolcowfund.hardin.law website: If I leave the site loaded and browse another tab, after a while the confetti will aggregate and slow down the computer until you check back in again and it all shows up at once. pls fix.
 
When using SneedChat on Tor, it is unreliable. Specifically:
  1. The chat constantly reconnects.
  2. The reason it reconnects is because of "error 1006" - this means the WebSocket connection was abnormally terminated.
  3. When it disconnects, it also hides the history until it reconnects. This means your scrollback is very short - typically only 1-2 minutes.
  4. More frustratingly, if you send a message as it is disconnecting, then it will simply swallow the message.
There is no clear pattern on what is causing the disconnections.
  1. When connecting to the clearnet site with Tor, everything seems stable.
  2. When connecting to the onion, the connection closes after about 21-27 seconds. However, in a few cases, the connection was able to stay open for an entire minute. The connection always seems to close after slightly less than one minute or slightly less than half a minute; it never closes after e.g. 40 seconds.
I think that the technical root causes are
  1. Unknown Tor-related message handling issues. This may be related to DDoS protection somehow?
  2. Bad client-side behaviour in the presence of connectivity issues.
I don't know how to fix (1), which is the underlying cause. But to fix (2), I propose the following two changes to the JavaScript client:
  1. Do not send messages if the WebSocket is not connected; just gray out the button and make enter a no-op.
  2. Add retry logic for failed messages:
    1. When you send a message, after sending it, add it + the sending timestamp to a list of "queued messages".
    2. Once you receive a message where the author is yourself, remove that message, as well as all earlier messages, from the list of queued messages.
    3. (NOTE: this would be easier with a small server change, such that you sent messages by JSON such as {"body": "nigger", "id": 123123}. The server would just echo "id" back to you. This means that the server altering a message would not make this mechanism unreliable.)
    4. If the connection was broken, upon re-connect, re-send the message queue.
Here is the list of durations, in seconds:

31
33
29
32
31
30
32
31
31
65
28
29
34
29
31
31
31
32
30
31
34
29
34
60
29
62
33
29
31
34
29
30
31
31
34
28
62
62
30
35
61
32
29
30
67
27
30
31
31
31
31
31
34
29
61
31

Here's what this looks like in a graph:
1707005416625.png

(These times are obtained by subtracting the open time of WS #1 from the opening time of WS #2, and so on. It's possible they're off by a few seconds. If I just eyeball it in the web tools, I can see no WebSockets that close after 29 seconds and before 50, nor that stay open for longer than 60 seconds. A few do last for only 19 seconds or so but might be unrelated.)
 
I'm occasionally seeing semi-regular captcha pages on .st. Like 2 or 3 in 15 minutes, mobile and desktop, on popular vpn for both.
 
When you insert a media link from YouTube it says that the content is blocked and that we should contact the site owner. Not sure if that's on my part, an intentional thing, or something the entire website is having issues with.
 
When making too many login errors, the CAPTCHA that pops up displays an "ERROR for site owner: invalid key", which makes the user have to wait for a brief moment of time before trying again.
 
Wyróżnienie
Musisz się zalogować lub zarejestrować, aby odpowiedzieć.
Wstecz
Top Na dole