I guess the reason why you don't use BigUint64Array is that it is not yet supported in Safari.

I developed an efficient encoder exactly for this problem: https://github.com/dmonad/lib0/blob/main/encoding.js

import * as encoding from 'lib0/encoding'
import * as decoding from 'lib0/decoding'

// example of encoding unsigned integers and strings efficiently

const encoder = new encoding.createEncoder()
encoding.writeVarUint(encoder, 256) 
encoding.writeVarString(encoder, 'Hello world!')
const buf = encoding.toUint8Array(encoder)

const decoder = new decoding.createDecoder(buf) 
decoding.readVarUint(decoder) // => 256 
decoding.readVarString(decoder) // => 'Hello world!' 
decoding.hasContent(decoder) // => false - all data is read

The documentation for other encoding techniques is here: https://github.com/dmonad/lib0

But I realize that this is already working in the current state. But maybe we can avoid pulling in more dependencies that are superflous.

For a header, we need to pad the values. Note the // 8 bytes comments I've mocked up a replacement class like:

class Int64 {
  constuctor (int64) {
    this.encoder = new encoding.createEncoder()
    encoding.writeVarUint(encoder, int64) 
  }
  toArrayBuffer () {
    return encoding.toUint8Array(this.encoder)
  }
}

However, when I test the recommended dependency, we get:

...
encoding.writeVarUint(encoder, 1)
encoding.toUint8Array(encoder)
> Uint8Array(1) [ 1 ]

its not obvious to me how to do pad/unpad safely, so the whole decode/encode would need a rewrite

This is interesting. So you implemented a layer around simple-peer that handles this issue.

Would it be possible that you publish a separate package that we can include as a polyfill for the default implementation? This is already done in y-websocket where we define the WebSocket as an argument.

new WebsocketProvider(URL, room, { WebSocket: MyCustomWebsocketPolyfill })

We could do something similar to y-webrtc without breaking the existing API.

new WebrtcProvider(room, yjs, { SimplePeer: SimplePeerExtended })

I'd prefer that approach because it allows us to test out your implementation before breaking everyone else's existing deployments.

i can publish a module and put something up on github, but it seems like you'd need move SimplePeer to a peerDependency to avoid duplicating code, otherwise your library is pulling in Peer while your user is also pulling in a modified peer.

Also, it looks like WebrtcConn is what's using the Peer and that's being called from SignalingConn...etc...

I can't figure out how you'd thread that option into the proper slot because it call comes from a global import Peer from 'simple-peer/simplepeer.min.js'