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*asencodingfrom'lib0/encoding'import*asdecodingfrom'lib0/decoding'// example of encoding unsigned integers and strings efficientlyconstencoder=newencoding.createEncoder()encoding.writeVarUint(encoder,256)encoding.writeVarString(encoder,'Hello world!')constbuf=encoding.toUint8Array(encoder)constdecoder=newdecoding.createDecoder(buf)decoding.readVarUint(decoder)// => 256decoding.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 theWebSocket as an argument.

newWebsocketProvider(URL,room,{WebSocket:MyCustomWebsocketPolyfill})

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

newWebrtcProvider(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 likeWebrtcConn is what's using thePeer and that's being called fromSignalingConn...etc...

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