fix: polyfill W3C compatibility by ThaUnknown · Pull Request #324 · murat-dogan/node-datachannel

ThaUnknown · 2025-01-20T15:35:23Z

this PR aims to fix all the critical W3C compatibility issues in the polyfill

it also implements rudimentary MediaStreams [WIP]

I'll add comments to the PR explaining things

ThaUnknown · 2025-01-20T15:35:58Z

src/polyfill/Events.ts

+        if (arguments.length === 0) throw new TypeError(`Failed to construct 'RTCDataChannelEvent': 2 arguments required, but only ${arguments.length} present.`)
+        if (typeof init !== 'object') throw new TypeError("Failed to construct 'RTCDataChannelEvent': The provided value is not of type 'RTCDataChannelEventInit'.")
+        if (!init.channel) throw new TypeError("Failed to construct 'RTCDataChannelEvent': Failed to read the 'channel' property from 'RTCDataChannelEventInit': Required member is undefined.")
+        if (init.channel.constructor !== RTCDataChannel) throw new TypeError("Failed to construct 'RTCDataChannelEvent': Failed to read the 'channel' property from 'RTCDataChannelEventInit': Failed to convert value to 'RTCDataChannel'.")


required by spec

ThaUnknown · 2025-01-20T15:36:35Z

src/polyfill/RTCDataChannel.ts

+    onclosing: globalThis.RTCDataChannel['onclosing'];
+    onerror: globalThis.RTCDataChannel['onerror'];
+    onmessage: globalThis.RTCDataChannel['onmessage'];
+    onopen: globalThis.RTCDataChannel['onopen']


bettter to let the types define it, rather than manually declare any, a typed event target implementation would be prefered however

ThaUnknown · 2025-01-20T15:37:28Z

src/polyfill/RTCDataChannel.ts

-        });
+    // we need updated connectionstate, so this is delayed by a single event loop tick
+    // this is fucked and wonky, needs to be made better
+    this.#dataChannel.onClosed(() => setTimeout(() => {


the spec is very assine about how and when datachannels should close, this is the closest i was able to bring it inline with said spec, the order of events in peer, ice and dc on closing is important for some libraries

ThaUnknown · 2025-01-20T15:37:50Z

src/polyfill/RTCDataChannel.ts

+            if (!ArrayBuffer.isView(message)) {
+                data = message
+            } else if (this.#binaryType === 'blob') {
+                data = new Blob([message])


don't explicitly use buffer, also cast to Blob when the type requires it, this wasn't even done before

ThaUnknown · 2025-01-20T15:38:26Z

src/polyfill/RTCDataChannel.ts

+            if (data.length > this.#dataChannel.maxMessageSize()) throw new TypeError('Max message size exceeded.')
            this.#dataChannel.sendMessage(data);
-        } else if (data instanceof Blob) {
+        } else if ('arrayBuffer' in data) {


we're not actually interested in blob, but its ab method, this is important for Blob-like libraries

ThaUnknown · 2025-01-20T15:38:41Z

src/polyfill/RTCDtlsTransport.ts

-            state = 'closed';
-        }
-        return state;
+        if (this.#pc.connectionState === 'disconnected') return 'closed'


pc is always defined

ThaUnknown · 2025-01-20T15:39:17Z

src/polyfill/RTCIceCandidate.ts


    get address(): string | null {
-        return this.#address || null;
+        return this.#address ?? null;


|| was incorrect to use here!!! we want null checking, not falsy checking

ThaUnknown · 2025-01-20T15:39:36Z

src/polyfill/RTCIceTransport.ts

    get component(): globalThis.RTCIceComponent {
        const cp = this.getSelectedCandidatePair();
-        if (!cp) return null;
+        if (!cp?.local) return null;


didnt verify local!

ThaUnknown · 2025-01-20T15:40:01Z

src/polyfill/RTCIceTransport.ts

-    getRemoteParameters(): any {
-        /** */
+    getRemoteParameters(): RTCIceParameters | null {
+        return new RTCIceParameters(new RTCIceCandidate({ candidate: this.#pc.getSelectedCandidatePair().remote.candidate, sdpMLineIndex: 0 }))


RTCIceParams were completely missing, these still dont have password/ufrag, need to wait for upstream to expose that

ThaUnknown · 2025-01-20T15:40:20Z

src/polyfill/RTCSctpTransport.ts

    get maxMessageSize(): number {
        if (this.state !== 'connected') return null;
-        return this.#pc ? this.#extraFunctions.maxMessageSize() : 0;
+        return this.#pc.maxMessageSize ?? 65536;


should never be 0

ThaUnknown · 2025-01-20T15:40:44Z

src/polyfill/RTCSessionDescription.ts

-        this.#type = init ? init.type : null;
-        this.#sdp = init ? init.sdp : null;
+    constructor(init: globalThis.RTCSessionDescriptionInit | null | undefined) {
+        this.#type = init?.type;


worked for the library, but not as a global exposed constructor

ThaUnknown · 2025-01-20T15:41:59Z

src/polyfill/RTCPeerConnection.ts

-                // length of urls can not be 0
-                if (config.iceServers[i].urls?.length === 0)
-                    throw new exceptions.SyntaxError('IceServers urls cannot be empty');
+    setConfiguration(config: RTCConfiguration): void {


I for the most part removed the old implementation, because by default a lot of fallbacks are used, this is correct for W3C, but i'm not certain this is correct for NDC, this needs to be verified

ThaUnknown · 2025-01-20T15:42:16Z

src/polyfill/RTCPeerConnection.ts

        this.#peerConnection.onLocalDescription((sdp, type) => {
            if (type === 'offer') {
-                this.#localOffer.resolve({ sdp, type });
+                this.#localOffer.resolve(new RTCSessionDescription({ sdp, type }));


this was incorrect!

ThaUnknown · 2025-01-20T15:42:32Z

src/polyfill/RTCPeerConnection.ts

+            this.ontrack?.(e as RTCTrackEvent)
+        })
+
+        this.addEventListener('negotiationneeded', e => {


this was never implemented, and is required for polite-peer libs

ThaUnknown · 2025-01-20T15:43:10Z

src/polyfill/RTCPeerConnection.ts

    }

-    createOffer(): Promise<globalThis.RTCSessionDescriptionInit | any> {
+    createOffer(): Promise<globalThis.RTCSessionDescriptionInit> & Promise<void> {


there are some annoying deprecated overloads for some of these methods, we shouldn't support them

murat-dogan · 2025-01-25T14:49:48Z

Hello and thank you for the PR.
Unfortunately, I can not compile the changes and run the WPT tests with these changes.
I wanted to see first which tests we will achieve now to compare here.
https://github.com/murat-dogan/node-datachannel/tree/master/test/wpt-tests

I think it will be good in all cases to separate this PR into small PRs. Especially RTCRtp part.
What do you think? Then we can handle it one by one and see which tests we can now achieve.

/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:859
    return new TSError(diagnosticText, diagnosticCodes, diagnostics);
           ^
TSError: ⨯ Unable to compile TypeScript:
src/polyfill/RTCRtp.ts:45:23 - error TS2339: Property 'close' does not exist on type 'Audio | Video | Track'.
  Property 'close' does not exist on type 'Audio'.

45     this.#transceiver.close?.()
                         ~~~~~
src/polyfill/RTCRtp.ts:53:5 - error TS2322: Type 'Audio | Video | Track' is not assignable to type 'Audio | Video'.
  Type 'Track' is not assignable to type 'Audio | Video'.
    Type 'Track' is missing the following properties from type 'Video': addVideoCodec, addH264Codec, addVP8Codec, addVP9Codec, and 16 more.

53     return this.#transceiver
       ~~~~~~

    at createTSError (/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:859:12)
    at reportTSError (/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:863:19)
    at getOutput (/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:1077:36)
    at Object.compile (/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:1433:41)
    at Module.m._compile (/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:1617:30)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at Object.require.extensions.<computed> [as .ts] (/home/murat/js/fork/node-datachannel/node_modules/ts-node/src/index.ts:1621:12)
    at Module.load (node:internal/modules/cjs/loader:1207:32)
    at Function.Module._load (node:internal/modules/cjs/loader:1023:12)
    at Module.require (node:internal/modules/cjs/loader:1235:19) {
  diagnosticCodes: [ 2339, 2322 ]
}

ThaUnknown · 2025-01-25T15:24:47Z

I assumed you use some manual commands, because rollup isn't even installable as you include a package-lock, and removing it, causes version conflict errors, so I couldn't even run rollup to try compiling it

ThaUnknown · 2025-01-25T15:28:35Z

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

murat-dogan · 2025-01-25T17:44:34Z

I assumed you use some manual commands, because rollup isn't even installable as you include a package-lock, and removing it, causes version conflict errors, so I couldn't even run rollup to try compiling it

I didn't understand what you mean.
to build all npm run build
to build only tsc npm run build:tsc

for others you can check package.json

murat-dogan · 2025-01-25T17:48:42Z

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

Unfortunately, I can not split the PR.
I will welcome any changes that you suggest and that will make more tests to be achieved.

About the tracks, we need definitely a separate PR and work and of course some test cases.

ThaUnknown · 2025-04-24T18:58:39Z

@murat-dogan are you gonna look at this?

murat-dogan · 2025-04-25T17:34:22Z

Hi @ThaUnknown,

Actually, I am waiting for you.
This PR is too old now.
Could you please create a clean PR for your changes, without media things?
Then we can talk about it and merge before the other PRs.

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

Unfortunately, I can not split the PR. I will welcome any changes that you suggest and that will make more tests to be achieved.

About the tracks, we need definitely a separate PR and work and of course some test cases.

ThaUnknown · 2025-04-25T17:36:29Z

Hi @ThaUnknown,

Actually, I am waiting for you. This PR is too old now. Could you please create a clean PR for your changes, without media things? Then we can talk about it and merge before the other PRs.

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

Unfortunately, I can not split the PR. I will welcome any changes that you suggest and that will make more tests to be achieved.
About the tracks, we need definitely a separate PR and work and of course some test cases.

waiting for what....?

you said that tracks should be a separate PR, I removed them and there was no follow up from you, if I update the PR the same thing will happen....?

murat-dogan · 2025-04-25T17:46:11Z

I have clearly said here

Hello and thank you for the PR.
Unfortunately, I can not compile the changes and run the WPT tests with these changes.
I wanted to see first which tests we will achieve now to compare here.
https://github.com/murat-dogan/node-datachannel/tree/master/test/wpt-tests

I think it will be good in all cases to separate this PR into small PRs. Especially RTCRtp part.
What do you think? Then we can handle it one by one and see which tests we can now achieve.

You said

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

And I said

Unfortunately, I can not split the PR.
I will welcome any changes that you suggest and that will make more tests to be achieved.

About the tracks, we need definitely a separate PR and work and of course some test cases.

If you try to push uncompilable changes, yes unfortunately the same thing will happen, otherwise for me no problem.
We can talk about them one by one and merge them.

I think the best way will be to create small and separate PRs.

ThaUnknown · 2025-04-25T17:50:36Z

I have clearly said here

Hello and thank you for the PR.
Unfortunately, I can not compile the changes and run the WPT tests with these changes.
I wanted to see first which tests we will achieve now to compare here.
https://github.com/murat-dogan/node-datachannel/tree/master/test/wpt-tests

I think it will be good in all cases to separate this PR into small PRs. Especially RTCRtp part.
What do you think? Then we can handle it one by one and see which tests we can now achieve.

You said

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

And I said

Unfortunately, I can not split the PR.
I will welcome any changes that you suggest and that will make more tests to be achieved.

About the tracks, we need definitely a separate PR and work and of course some test cases.

If you try to push uncompilable changes, yes unfortunately the same thing will happen, otherwise for me no problem. We can talk about them one by one and merge them.

I think the best way will be to create small and separate PRs.

yes, which was all fixed by 03ac9d3 which simply nuked the things that prevented it from compiling, the changes were compatible at the time they were made, simply no follow ups on the PR made it outdated

which is why i'm asking, "what was wrong here" because there's 0 reason for me to update a PR which will just be left to sit again, with no reason as to why that happens

murat-dogan · 2025-04-25T17:54:21Z

That has no meaning.
As I said, if you want to do that, you can create a PR/PRs. We can test them and merge them.

For me definitely no problem.

ThaUnknown · 2025-04-25T18:05:19Z

That has no meaning. As I said, if you want to do that, you can create a PR/PRs. We can test them and merge them.

For me definitely no problem.

okay, I don't think we're... understanding eachother

here's what I mean:

you commented that there are build errors because of the mediastream stuff, and said it should probably be another PR later on
i agreed, removed that implementation so it can be added later in the future
there was no follow-up for months

I'm asking why there was no follow up, did you simply forget, or was there still something wrong with the PR, if I update the PR will it be left hanging again with no reason given?

murat-dogan · 2025-04-25T18:15:36Z

No, I didn't forget it.

I was so complex to handle in one go, even after the changes.
I proposed you split up the changes into PRs to point to exact tests or purposes, instead of a PR that solves "all" problems.
You said no, and I could not do more.

As I said this conversation has no meaning.
Please create PRs that we can handle and merge.

ThaUnknown · 2025-04-25T18:23:00Z

No, I didn't forget it.

I was so complex to handle in one go, even after the changes. I proposed you split up the changes into PRs to point to exact tests or purposes, instead of a PR that solves "all" problems. You said no, and I could not do more.

As I said this conversation has no meaning. Please create PRs that we can handle and merge.

which brings me back to the whole "will you look at this"

this PR is not even remotely complex, 95% of it is just correctly declaring types which was also pointed out in #346, fixing error naming to be inline with W3C spec, and fixing nullish coalescing as the logical OR operator was used in many places incorrectly

this PR only actually has 3 functional changes:

datachannel close event order [covered by wpt]
non-explicit buffer
simpler blob array buffer check
correct message type returns [covered by wpt] which was also pointed out in fix: use binaryType correctly #348

murat-dogan · 2025-04-25T19:01:35Z

I don't really know what to say.
After this conversation, you are still trying this PR.
Ok, let's try your way.

Build gives error

npm run build:tsc

test gives error

npm run test

wpt tests give error

npm run wpt:test

fix: stricter type definitions

murat-dogan · 2025-04-25T19:17:45Z

I think the main reason for this PR is fixing more compatibility issues, so we can pass more tests right?
Could you please run your PR against Wpt tests so we can compare them with the current ones?

Please note that I don't know why but there is a problem with the "'/webrtc/no-media-call.html'," test
Just comment it out, we can look at it later.

Also, tests still fail.

ThaUnknown · 2025-04-25T19:18:18Z

build now works, i was still in the progress of fixing it when u sent that

npm run test isnt runnable on windows, I assume you're running linux

same as above

also IIRC wpt tests require a network hosts setup, which is not included in the commands

murat-dogan · 2025-04-25T19:27:40Z

Yes, I am using Linux.

Please see here for Linux instructions, Since I am not running on windows I can not tell commands for windows to setup the hosts.
https://github.com/murat-dogan/node-datachannel/blob/master/test/wpt-tests/README.md

You can run this to run the server

npm run wpt:server

In another terminal you can run the tests

npm run wpt:test

And this is exactly why I am saying we should go with small PRs.
It will be easy to see the problem, compare the test results and fix it when needed.

ThaUnknown · 2025-04-25T19:28:35Z

Yes, I am using Linux.

Please see here for Linux instructions, Since I am not running on windows I can not tell commands for windows. https://github.com/murat-dogan/node-datachannel/blob/master/test/wpt-tests/README.md

You can run this to run the server

npm run wpt:server

In another terminal you can run the tests

npm run wpt:test

And this is exactly why I am saying we should go with small PRs. It will be easy to see the problem, compare the test results and fix it when needed.

the PR could be 1 line of code, it doesn't change that the problems are with the commands and test suite, not the PR, we're not even getting to the "run code part" here

ThaUnknown · 2025-04-25T19:41:37Z

welp I don't have the time to fix the native code for this today, i'll have to re-visit this later, since the changes that were made in the past 3 months broke the PR, which causes NAPI to exit the entire process, and jest refuses to log when that happens, woeful

fix: cross-os env definitions fix: WAY stricter type defs fix: imports

mertushka · 2025-05-05T01:05:45Z

Just wanted to jump in here to clear the air a bit and help us move forward. @murat-dogan @ThaUnknown

I believe this PR is still important. It fixes a bunch of subtle but real issues, like spec compliance, proper typing, event ordering, and buffer handling — all things that improve stability and help us get closer to passing more WPTs.

@achingbrain already split some parts off, thanks for that, but they still haven’t been merged. Let’s make things easier for everyone and done the remaining parts.

ThaUnknown · 2025-05-06T06:03:59Z

Just wanted to jump in here to clear the air a bit and help us move forward.

I believe this PR is still important. It fixes a bunch of subtle but real issues, like spec compliance, proper typing, event ordering, and buffer handling — all things that improve stability and help us get closer to passing more WPTs.

achingbrain already split some parts off, thanks for that, but they still haven’t been merged. Let’s make things easier for everyone and done the remaining parts.

if you want to have this merged they badly, you've seen the discussion, simply try to get wpt to work and contribute the changes

murat-dogan · 2025-05-07T18:55:03Z

@ThaUnknown
Please create a PR only for #347 and #348 , so we can merge directly.
Then please create another clean PR with other changes, I will help with the WPT tests.

ThaUnknown · 2025-05-07T19:01:58Z

@ThaUnknown Please create a PR only for #347 and #348 , so we can merge directly. Then please create another clean PR with other changes, I will help with the WPT tests.

oh sorry, I didn't mean you, I meant the guy above us who's rushing us, while contributing nothing

those PR's are already crated, you linked them...?

also please diff the files in

there aren't actually many changes as I said, most of it is stuff like proper constructor errors, and type defs, and the specific changes are commented in my original review, rather than focusing on getting WPT working, just read those and you'll see the changes are just cookie-cutter copy-paste fixes, I'll get the WPT stuff working later

mertushka · 2025-05-07T19:34:32Z

@ThaUnknown You’re saying I haven’t contributed anything, but what exactly am I supposed to do on top of an existing complex PR? Instead of arguing endlessly, I told you to just structure the PR the way Murat asked — which, by the way, is the correct approach.

Here’s an example of how a PR should be made:
#327

And here’s a clear example of how discussion should be handled properly:
#320

Hope you take something from it.

murat-dogan · 2025-05-07T19:39:08Z

Yes, I also understood correctly, that you are saying it to @mertushka

Since you said I made also these changes, I said to create a PR for #347 and #348, in order to not block the other things.

I don't think it is a good idea to merge this PR like this.
It could be even one line that's breaking the binary.
We need to understand that before merging.

I am trying to be polite, but I don't think we are a good match.
I am doing this volunteer and this does not help me.

I guess it will be better to do what you said before.
I will split and merge it and mention your name, when I have time.
Thanks.

you can feel free to split up this PR, I kinda lost my will to live after implementing the video/audio track shenanigans, mainly because of how they are exposed, I think the bindings need to do it a bit better than what we currently have, but that's honestly above what I'm willing to do, so I tried somewhat finishing it, even tho I don't think it actually works correctly as I couldn't find how to properly create and consume tracks and transceivers

ThaUnknown · 2025-05-07T23:11:42Z

I am trying to be polite, but I don't think we are a good match.

yeah I... agree.... my tone is very.... passive aggressive I guess? people tend to not like that, but I don't like mincing words because it leads to miscommunication, for which I often don't have the time

I am doing this volunteer and this does not help me.

you and me both, trust me, I'm running my own fork of this library, so I wanted to contribute all the fixes I've applied to it, which is a dependency of another library I maintain, which is a dependency of another library I maintain, which is a dependency of another library I maintain, which is a dependency of another lib I maintain [not even joking ndc fork -> simple-peer -> bt-tracker -> torrent-discovery -> webtorrent, FOSS is hell!], which is then used by a bunch of my apps, all of which have a lot of their own "only in the world" solutions and dependencies too

That's why I was so unwilling to split this PR, because it's a lot of work, which for me feels unnecessary and is a waste of time I already don't have.

I will split and merge it and mention your name, when I have time.

yeah, I documented all the changes in the reviews, so you should have no problem finding what problems they solve, feel free to close this PR and use it as a reference in the future, I never got pre-negotiated data channels working, neither in your lib, or mine so there's something fun for you to poke at too haha

Remove Extrafunctions from pc and add webrtc package part of #324

fix: polyfill W3C compatibility

076764a

ThaUnknown commented Jan 20, 2025

View reviewed changes

fix: lint, update lockfile

c478a52

fix: force assert types [probably a bad idea]

03ac9d3

achingbrain mentioned this pull request Jan 25, 2025

feat: accept preconfigured PeerConnection as polyfill arg #260

Merged

fix: nuke mediastream impl

8b46bef

This was referenced Apr 24, 2025

fix: memoize RTCDataChannel fields #347

Merged

fix: use binaryType correctly #348

Merged

Merge branch 'master' of https://github.com/murat-dogan/node-datachannel

ca42b99

fix: correct rollup exports

29913e7

fix: stricter type definitions

ThaUnknown force-pushed the master branch from 9a043ee to 29913e7 Compare April 25, 2025 19:07

ThaUnknown added 2 commits April 25, 2025 22:34

fix: incorrect blob tests

7e208e0

fix: cross-os env definitions fix: WAY stricter type defs fix: imports

chore: package lock

fe4d96f

murat-dogan mentioned this pull request May 24, 2025

Types #355

Merged

murat-dogan closed this May 24, 2025

murat-dogan mentioned this pull request May 24, 2025

Remove extra functions #356

Merged

murat-dogan added a commit that referenced this pull request May 24, 2025

Merge pull request #356 from murat-dogan/remove_extra_functions

a917c0f

Remove Extrafunctions from pc and add webrtc package part of #324

Uh oh!

Conversation

ThaUnknown commented Jan 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

murat-dogan commented Jan 25, 2025

Uh oh!

ThaUnknown commented Jan 25, 2025

Uh oh!

ThaUnknown commented Jan 25, 2025

Uh oh!

murat-dogan commented Jan 25, 2025

Uh oh!

murat-dogan commented Jan 25, 2025

Uh oh!

ThaUnknown commented Apr 24, 2025

Uh oh!

murat-dogan commented Apr 25, 2025

Uh oh!

ThaUnknown commented Apr 25, 2025

Uh oh!

murat-dogan commented Apr 25, 2025

Uh oh!

ThaUnknown commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

murat-dogan commented Apr 25, 2025

Uh oh!

ThaUnknown commented Apr 25, 2025

Uh oh!

murat-dogan commented Apr 25, 2025

Uh oh!

ThaUnknown commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

murat-dogan commented Apr 25, 2025

Uh oh!

murat-dogan commented Apr 25, 2025

Uh oh!

ThaUnknown commented Apr 25, 2025

Uh oh!

murat-dogan commented Apr 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ThaUnknown commented Apr 25, 2025

Uh oh!

ThaUnknown commented Apr 25, 2025

Uh oh!

mertushka commented May 5, 2025

Uh oh!

ThaUnknown commented Jan 20, 2025 •

edited

Loading

ThaUnknown commented Apr 25, 2025 •

edited

Loading

ThaUnknown commented Apr 25, 2025 •

edited

Loading

murat-dogan commented Apr 25, 2025 •

edited

Loading

ThaUnknown commented May 7, 2025 •

edited

Loading