Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    ilovedesert001
    @ilovedesert001
    image.png
    ilovedesert001
    @ilovedesert001
    @dmonad
    This may seem to be a bug.
    When adding a large amount of data with transaction, it cannot be synchronized through webRTC .
    Will Hawker
    @whawker
    interesting, how "large" we talking?
    ilovedesert001
    @ilovedesert001
    image.png
    1000 ok , 8000 not working
    image.png
    Will Hawker
    @whawker
    hmmm, quick Google suggests max maybe 16kb? https://stackoverflow.com/a/35381583/2039219
    ilovedesert001
    @ilovedesert001
    I thought webRTC would send in chunks internal .
    ilovedesert001
    @ilovedesert001
    In lib0, is there a function to merge two(or more) unit8arrays ?
    ilovedesert001
    @ilovedesert001
    solved
    Large unit8array, first split them and sending one by one
    Rishabh Malhotra
    @Rishabh-malhotraa
    @dmonad Thank you so much for creating and maintaining yjs, previously for my hobby project I was using some other method for conflict resolution(OT) and faced some annoying bugs, but now I switched to yjs and everything works like a charm 🙌 🥳.
    If anyone is interested in what I made:
    Source code: https://github.com/Rishabh-malhotraa/caucus
    Hosted on: https://caucus-app.herokuapp.com/
    ilovedesert001
    @ilovedesert001
    Great job
    Kevin Jahns
    @dmonad
    @ilovedesert001 This is tracked in the y-webrtc issues and there is already a fix by another user. But I can't integrate that fix yet
    Cool stuff @Rishabh-malhotraa Thanks for sharing! Also feel free to post this into discuss.yjs.dev
    Will Hawker
    @whawker
    Opened yjs/y-prosemirror#54 if anyone is available to review?
    1 reply
    ilovedesert001
    @ilovedesert001

    @dmonad
    hi , this is the one you mentioned .
    https://github.com/yjs/y-webrtc/pull/25/files ,

    It looks like he has completely switched to a new webRTC library , that maybe cause more problem .

    I added three new message types , and send yjs original message in a for loop .

    rtc.png
    rtc2.png
    Nick Odumo
    @nodumo

    Hi all, I am using YJS with TipTap.
    I ran into an issue where if I set the the value of the editor I end up broadcasting an append when the user enters the note..
    this.editor = new Editor({ content: content })

    Has anyone ran into issues with setting the initial state of the tiptap editor and then connecting to a provider?

    Will Hawker
    @whawker
    could it be Prosemirror trailing node behaviour? Automatically adding a paragraph to the end?
    Will Hawker
    @whawker
    I mean, I'm happy to open a PR, just don't know the implications of CRDT and Sets with their unique values behaviour
    Kevin Jahns
    @dmonad
    @whawker, I like the idea. First, you'd need to add a set encoder & decoder to https://github.com/dmonad/lib0/blob/b4f9a4865996093c3867e5e1e6ce0b9923fc8976/encoding.js#L445 (and the decoding library respectively). Make sure to write some tests for it encoding empty and large sets. Next, you can add Set to the above function and update the documentation. Even such a small change might involve a lot of work.
    Charanjit Singh
    @charanjit-singh_gitlab
    how to access connection that updated the document in updateHandler on update?
    Charanjit Singh
    @charanjit-singh_gitlab
    Where can I find implementation of emit('update' ....?
    in Y.Doc
    Ulion
    @ulion
    @dmonad encountered a specific ydoc deadloop (take very long time to load) on the other side of y-websocket, the source side is fine, but the receive side (no other provider) will dead loop (looks like), the sync message is 600k size. for such case, what shall we do to figure out what caused this?
    Ulion
    @ulion
    截屏2021-06-25 下午3.49.12.png
    截屏2021-06-25 下午3.48.49.png
    截屏2021-06-25 下午3.47.30.png
    random debugger break got above stacks, what can I help to dig this out?
    Ulion
    @ulion
    after digging my log, it is probably caused by huge amount of repeat insert and remove element in certain place of a specific array caused by multiple clients operation dead loop. so now although the clients dead loop op is stopped, but the ydoc is still quite hard to load due to that large amount of repeat insert/delete/insert/delete ops happened before.
    Kevin Jahns
    @dmonad
    @ulion Concurrent insertions at the same position have a rather bad runtime behavior. But loading such a document after all conflicts have been resolved should still be fast. So how much time does it take to load that document?
    Ulion
    @ulion
    @dmonad it does not finish the load, at least for a few minutes.
    and cpu 100%
    I can confirm the op storm happened there, probably for 20+ minutes between 2-3 clients, so there would be large amount of insert/delete ops on the specific array.
    Kevin Jahns
    @dmonad
    Do you use any code pre-processors (e.g. babel, typescript with enabled polyfills, ..)
    ?
    Ulion
    @ulion
    yes, the final code use that. and currently it's in dev mode.
    Kevin Jahns
    @dmonad
    That could be a reason. Some polyfills for binary data are ridiculously slow. I experienced a similar issue before.
    Could you maybe share the document?
    First you should try whether the document still needs several seconds to load without polyfills.
    Ulion
    @ulion
    I think I can share the ydoc to you, via a specific websocket url.
    Kevin Jahns
    @dmonad
    Could you also download it? E.g. by calling Y.encodeStateAsUpdate(ydoc) on the loaded ydoc.
    Ulion
    @ulion
    @dmonad PM sent you the link.
    Kevin Jahns
    @dmonad

    So there is no dead loop because the process completes after 15 seconds. Apparantly, your application performs a lot of conflicts that need to be resolved. 14.5 seconds are spent in total in the integration function which iterates over all conflicts. So all seems to be in order.

    I'm not sure what you are doing exactly, but there are things that don't perform well in Yjs, or in CRDTs in general for that matter. Try to avoid creating conflicts. A few conflicts at the same position are fine. But creating many concurrent insertions at the same position should be avoided.

    Laurin Quast
    @n1ru4l
    I am working with the WebRTCProvider with document editing and have the requirement of having users join a collaboration session as read-only users. Is there an easy solution for enforcing that, did anyone already solve this issue? I assume that this is actually quite a complex problem to solve as all peers would need to know who is allowed to edit and then decline possible changes sent from the peers that are in read mode
    Ulion
    @ulion
    well, it does not load on my env in 15 seconds, it's hard to load after unload indeed, I failed to load it before websocket timeout close indeed. anyway, I found the reason caused too many conflict ops in my code and fixed the source, and deleted that ydoc and re-created it from json data. Thank you for help to dig. the conflict was created by single client itself repeat insert and delete, so it must have created huge amount conflict nodes by those op. It is reasonable since it's not normal use case in either way.
    Roman Rädle
    @raedle

    First of all, I really dig the Yjs API -- it is well-thought out!! Kudos to that!

    I am experiencing a case where an insert in a Y.Text inherits attributes from a preceeding character. Is this expected and if so, what is the reason behind it?

    Example:

    import * as Y from "yjs";
    
    const doc = new Y.Doc();
    const content = doc.getText("content");
    doc.transact(() => {
      content.insert(0, "x", { nodeType: 3, nodeName: 'span' });
      content.insert(1, "y");
    });
    
    console.log(JSON.stringify(content.toDelta(), null, 2));

    Output:

    [
      {
        "insert": "xy",
        "attributes": {
          "nodeType": 3,
          "nodeName": "span"
        }
      }
    ]

    Expected output:

    [
      {
        "insert": "x",
        "attributes": {
          "nodeType": 3,
          "nodeName": "span"
        }
      },
      {
        "insert": "y"
      },
    ]
    Roman Rädle
    @raedle

    There is also another quirk that leads to different outcomes when a document is loaded from a state update (see code below). I would expect the output in both cases to match the content delta. I am happy to file an issue on GitHub if this is not an expected behavior :)

    import * as Y from "yjs";
    
    const doc = new Y.Doc();
    const content = doc.getText("content");
    content.insert(0, "\n", { invisible: true });
    content.insert(1, "\n\n", {});
    content.format(0, 1, { nodeName: "div" });
    content.format(1, 1, { nodeName: "div" });
    content.format(2, 1, { nodeName: "div" });
    const initialState = Y.encodeStateAsUpdate(doc);
    
    function loadDoc(): Y.Doc {
      const doc = new Y.Doc();
      Y.applyUpdate(doc, initialState);
      return doc;
    }
    
    doc.transact(() => {
      content.format(1, 1, {
        nodeName: "span"
      });
    });
    
    const loadedDoc = loadDoc();
    const loadedContent = loadedDoc.getText("content");
    loadedDoc.transact(() => {
      loadedContent.format(1, 1, {
        nodeName: "span"
      });
    });
    
    console.log("content", JSON.stringify(content.toDelta(), null, 2));
    console.log("loadedContent", JSON.stringify(loadedContent.toDelta(), null, 2));

    Expected output both times:

    [
      {
        "insert": "\n",
        "attributes": {
          "nodeName": "div",
          "invisible": true
        }
      },
      {
        "insert": "\n",
        "attributes": {
          "nodeName": "span"
        }
      },
      {
        "insert": "\n",
        "attributes": {
          "nodeName": "div"
        }
      }
    ]