This task is a main task and has to be broken into several.

Hi @johanneswilm I have a student Vladimir Stashkov @stashkov to work on it. Let's introduce him to the group in the next chance.

@sadeghiafshin Great! Should we wait for the meeting next week, or should we meet on slack or some other such place?

@johanneswilm I was going to bring him in the next Monday meeting and he showed interested in starting right now by the slack. I wanted to ask you to invite him there. I introduced him to the rough idea as an introduction but he will need to talk to you.

@sadeghiafshin Ok, that will work. From you it would be good to hear what parts of this feature are most important to you. For example, I think it should be possible to create a "diff view" between different manually invoked revisions of a file without making many large structural changes to the software. What will be much more challenging is a feature that allows the user to go back an arbitrary amount of steps in the history .

I am not even sure if we can guarantee that one can go back X number of prosemirror steps. It gets even more complicated if we also look at citations and images that a user may edit or delete. So this may be a much bigger challenge than a graphic diffing mechanism.

I favor this: "I think it should be possible to create a "diff view" between different manually invoked revisions of a file without making many large structural changes"

Imho, mostly to mention a diff will be enough. To be precise If we could say if it is an "add" or "remove" and its location in the text and the "person" who did this. I think it covers the dedicated lab time. We can think of more steps if it was too easy with him. I suggested him to look for the place that we take the diffs in the prosemirror and send to server. He must come to you soon.

OK, we'll see how it goes. Small steps is always a good idea.

I was able to install fidus locally with some tweaks (/scripts was missing during ./manage.py init step, so I created it)

fidus is running locally but I cannot login with my username. I provided username & password during init step, then I received confirmation email but when I follow this link, checked checkboxes, but I am unable to press CONFIRM button it just doesn't seem to be active

Here's the output from the console:

You're receiving this e-mail because user vladimir1 at example.com has given yours as an e-mail address to connect their account.

To confirm this is correct, go to http://localhost:8000/account/confirm-email/Mg:1d0nw9:7pjgruK7uTM8jFNma-37X7R9Wzc/

Thank you from example.com! example.com

ERROR:javascript_error:Got error: details: http://localhost:8000/account/confirm-email/:129: ReferenceError: jQuery is not defined context: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 user: <UNAUTHENTICATED> ERROR:javascript_error:Got error: details: http://localhost:8000/static/js/feedback.es5.js:122: ReferenceError: jQuery is not defined context: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 user: <UNAUTHENTICATED> ERROR:javascript_error:Got error: details: http://localhost:8000/static/js/confirm_email.es5.js:15: ReferenceError: jQuery is not defined context: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 user: <UNAUTHENTICATED> ERROR:javascript_error:Got error: details: http://localhost:8000/account/confirm-email/Mg:1d0nw9:7pjgruK7uTM8jFNma-37X7R9Wzc/:159: ReferenceError: jQuery is not defined context: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 user: <UNAUTHENTICATED> ERROR:javascript_error:Got error: details: http://localhost:8000/static/js/feedback.es5.js:122: ReferenceError: jQuery is not defined context: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 user: <UNAUTHENTICATED>

On 19 April 2017 at 10:04, Johannes Wilm [email protected] wrote:

OK, we'll see how it goes. Small steps is always a good idea.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fiduswriter/fiduswriter/issues/428#issuecomment-295152009, or mute the thread https://github.com/notifications/unsubscribe-auth/AL5RQHbKJ2WVeVx1h-T4XmTIcguG1X3Dks5rxcAngaJpZM4NAWxK .

-- Mit vielen Grüßen / Kind regards / С уважением, Vladimir.

I was able to install fidus locally with some tweaks (/scripts was missing during ./manage.py init step, so I created it)

@stashkov I don't think there should be a directory "/scripts". What step required this directory?

@stashkov Which version of Ubuntu do you have installed?

@stashkov It seems like something went wrong during ./manage.py init. I am rerunning the install process on Ubuntu 16.04 right now to see if there is any problem with it.

@stashkov: Ok, I tried it out. There is no need for a /scripts dir, and jQuery is installed as it should through ./manage.py init. I wonder if there is some other issue. Are you running this on Ubuntu 14.04/16.04? Those are the only two distribution releases we have it tested so far.

@sadeghiafshin @stashkov As for possibilities of diff views:

There are several things one can try to diff here:

1. Diffing indivual user changes. This is where ProseMirror comes in and on top of this we should create a "tracked changes" feature. Unfortunately, only 500-1000 or so of these steps are stored on the server. I just investigated it a bit and I don't think we can store them indefinitely, as each letter entered or deleted will mean one diff that makes out abour 180 bytes. So a document with 20000 words that would usually fill maybe 120kb will suddenly have a size of around 20 MB. And that is not even counting deletions nor information about who authored each diff. That is too large to send to user browsers, especially on mobile.

2. Diff json between snapshots. A snap shot is saved as a jsn file together with the images and citations used inside a zip file. This can be diffed, but there is no information about who authored which part of the file. Diffing the two json structures (current dc and old version from zip file) should not require interacting much with ProseMirror.

Right now I can see two viable strategies, but there may be more:

• Forget about who wrote what and just diff between snapshots/current versions in a visually pleasing manner so that the end user can figure out how different versions of a document differ.

• Try to implement a type of tracked changes. Instead of storing all the stpes/diffs, it would simply mark ranges of text as beign associated with a particular user and either being approved or not-approved. This marking would take place at the moment when the user enters the text. For text deletions, it would have to interrupt all deletions of text and instead of deelting the text, mark it. Using CSS, text ranges marked as deleted could then optionally not be shown. Also, ne could add coloring for the text ranges based on who authored it.

This second option could probably be made in a way so it served both as a history AND a tracked changes feature for insertion/deletion of simple text. However, it would probably get more complicated if one adds additions/splits of paragraphs, formatting and more complex elements.

@johanneswilm https://github.com/johanneswilm did you have success with 16.04? I am using this version of Ubuntu and got the error that I'm describing

Here's what I think is somewhat doable in terms of space: We are given 2 text. First one:

---

This is a test file That has some text inside I am going to change this line in the next file But this line will stay the same So the only different should be in 1 and 3 line

---

And the 2nd one

---

This is a new test file That has some text inside This line was completely changed But this line will stay the same So the only different should be in 1 and 3 line

---

The result that we store and show to the user is:

---

• This is a test file

• This is a new test file

? ++++

• I am going to change this line in the next file

• This line was completely changed

---

Advantages: We completely ignore unchanged lines In this case we will save on space (no need to save and zip all versions) We can easily serve this to client

Disadvantages: Because we don't store intermediate results, there is no way we can rollback. User is only able to view the history of changes without ability to rollback with a click. User can certainly do it by copy-pasting necessary parts.

On 19 April 2017 at 14:39, Johannes Wilm [email protected] wrote:

@stashkov https://github.com/stashkov: Ok, I tried it out. There is no need for a /scripts dir, and jQuery is installed as it should through ./manage.py init. I wonder if there is some other issue. Are you running this on Ubuntu 14.04/16.04? Those are the only two distribution releases we have it tested so far.

@sadeghiafshin https://github.com/sadeghiafshin @stashkov https://github.com/stashkov As for possibilities of diff views:

There are several things one can try to diff here:

Diffing indivual user changes. This is where ProseMirror comes in and on top of this we should create a "tracked changes" feature. Unfortunately, only 500-1000 or so of these steps are stored on the server. I just investigated it a bit and I don't think we can store them indefinitely, as each letter entered or deleted will mean one diff that makes out abour 180 bytes. So a document with 20000 words that would usually fill maybe 120kb will suddenly have a size of around 20 MB. And that is not even counting deletions nor information about who authored each diff. That is too large to send to user browsers, especially on mobile. 2.

Diff json between snapshots. A snap shot is saved as a jsn file together with the images and citations used inside a zip file. This can be diffed, but there is no information about who authored which part of the file. Diffing the two json structures (current dc and old version from zip file) should not require interacting much with ProseMirror.

Right now I can see two viable strategies, but there may be more:

Forget about who wrote what and just diff between snapshots/current versions in a visually pleasing manner so that the end user can figure out how different versions of a document differ.

Try to implement a type of tracked changes. Instead of storing all the stpes/diffs, it would simply mark ranges of text as beign associated with a particular user and either being approved or not-approved. This marking would take place at the moment when the user enters the text. For text deletions, it would have to interrupt all deletions of text and instead of deelting the text, mark it. Using CSS, text ranges marked as deleted could then optionally not be shown. Also, ne could add coloring for the text ranges based on who authored it.

This second option could probably be made in a way so it served both as a history AND a tracked changes feature for insertion/deletion of simple text. However, it would probably get more complicated if one adds additions/splits of paragraphs, formatting and more complex elements.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fiduswriter/fiduswriter/issues/428#issuecomment-295254462, or mute the thread https://github.com/notifications/unsubscribe-auth/AL5RQJ8VpiqFyJQBjXIS6iaW0TYbc8jaks5rxgBqgaJpZM4NAWxK .

-- Mit vielen Grüßen / Kind regards / С уважением, Vladimir.

Obviously there has to be restriction that you mentioned, like 20 most recent changes

On 19 April 2017 at 18:42, Vladimir Stashkov [email protected] wrote:

@johanneswilm https://github.com/johanneswilm did you have success with 16.04? I am using this version of Ubuntu and got the error that I'm describing

Here's what I think is somewhat doable in terms of space: We are given 2 text. First one:

---

This is a test file That has some text inside I am going to change this line in the next file But this line will stay the same So the only different should be in 1 and 3 line

---

And the 2nd one

---

This is a new test file That has some text inside This line was completely changed But this line will stay the same So the only different should be in 1 and 3 line

---

The result that we store and show to the user is:

---

• This is a test file

• This is a new test file

? ++++

• I am going to change this line in the next file

• This line was completely changed

---

Advantages: We completely ignore unchanged lines In this case we will save on space (no need to save and zip all versions) We can easily serve this to client

Disadvantages: Because we don't store intermediate results, there is no way we can rollback. User is only able to view the history of changes without ability to rollback with a click. User can certainly do it by copy-pasting necessary parts.

On 19 April 2017 at 14:39, Johannes Wilm [email protected] wrote:

@stashkov https://github.com/stashkov: Ok, I tried it out. There is no need for a /scripts dir, and jQuery is installed as it should through ./manage.py init. I wonder if there is some other issue. Are you running this on Ubuntu 14.04/16.04? Those are the only two distribution releases we have it tested so far.

@sadeghiafshin https://github.com/sadeghiafshin @stashkov https://github.com/stashkov As for possibilities of diff views:

There are several things one can try to diff here:

Diffing indivual user changes. This is where ProseMirror comes in and on top of this we should create a "tracked changes" feature. Unfortunately, only 500-1000 or so of these steps are stored on the server. I just investigated it a bit and I don't think we can store them indefinitely, as each letter entered or deleted will mean one diff that makes out abour 180 bytes. So a document with 20000 words that would usually fill maybe 120kb will suddenly have a size of around 20 MB. And that is not even counting deletions nor information about who authored each diff. That is too large to send to user browsers, especially on mobile. 2.

Diff json between snapshots. A snap shot is saved as a jsn file together with the images and citations used inside a zip file. This can be diffed, but there is no information about who authored which part of the file. Diffing the two json structures (current dc and old version from zip file) should not require interacting much with ProseMirror.

Right now I can see two viable strategies, but there may be more:

Forget about who wrote what and just diff between snapshots/current versions in a visually pleasing manner so that the end user can figure out how different versions of a document differ.

Try to implement a type of tracked changes. Instead of storing all the stpes/diffs, it would simply mark ranges of text as beign associated with a particular user and either being approved or not-approved. This marking would take place at the moment when the user enters the text. For text deletions, it would have to interrupt all deletions of text and instead of deelting the text, mark it. Using CSS, text ranges marked as deleted could then optionally not be shown. Also, ne could add coloring for the text ranges based on who authored it.

This second option could probably be made in a way so it served both as a history AND a tracked changes feature for insertion/deletion of simple text. However, it would probably get more complicated if one adds additions/splits of paragraphs, formatting and more complex elements.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fiduswriter/fiduswriter/issues/428#issuecomment-295254462, or mute the thread https://github.com/notifications/unsubscribe-auth/AL5RQJ8VpiqFyJQBjXIS6iaW0TYbc8jaks5rxgBqgaJpZM4NAWxK .

-- Mit vielen Grüßen / Kind regards / С уважением, Vladimir.

-- Mit vielen Grüßen / Kind regards / С уважением, Vladimir.

@stashkov Yes, I am using Ubuntu 16.04. Travis is using a clean Ubuntu 14.04 and didn't have any issues the last time it ran a few days ago. I tried the 16.04 thing today. Where there any issues with any of the installation steps prior to ./manage.py init? This step should have installed jQuery for you, but this apparently didn't happen. Also, it should not have required a script directory. What kind of error did you receive?

As for your proposal of what to do:

Because we don't store intermediate results, there is no way we can rollback.

This is OK.

User can certainly do it by copy-pasting necessary parts.

They don't need to do that. They can already roll-back as it is today to get one of these previous revisions back. The only thing they cannot do right now is see what the difference between the various old revisions and the current version is, so they have to rely on the date and a keyword they tagged the revision with when they created it. Of course, copy-paste may come in handy if they only want to roll-back the changes made to a part of what they were working on.

The result that we store and show to the user is:

Yes, but remember we are dealing with richtext content that is available as a JSON structure (which easily can be transformed into HTML). So it doesn't have a concept of "a line", just "a paragraph".

One way of doing this would be to take the old json, the new json, use the prosemirror functions to convert both to HTML and then use some library like htmldiff [1] to diff the two and generate a useful visual output. There are other ways of doing this, and I don't actually know if any of the libraries really are up for the task. This is something to investigate.

Obviously there has to be restriction that you mentioned, like 20 most recent changes.

Yes, the problem is that because it is a realtime editor, the changes are super small: every letter entered. So 20 changes going back would only be 20 letters entered, so maybe 3 words written and one word deleted. But you have at least these alternative options (and others I haven't thought about):

1. Make diffs only between saved revisions (as outlined above).

2. Mark text ranges during the document text entering and text deletion (more complex).

To expand on 2: The way prosemirror works, you can add marks to certain text ranges. This can be stylistic information, but also other thing. So for example, in this case it's bold:

This is a <strong>bold</strong> text.

is in our JSON:

[{type: "text", text: "This is a "}, {type: "text", text: "bold", marks: [{type: "strong"}]}, {type: "text", text: " text."}]

So here you can see the mark "strong" is used for stylistic reasons. But it could also be used for the purpose of marking insertions like so:

<span class="insertion" data-author="12">This text was written by </span><strong><span class="insertion" data-author="114">me.</span></strong>

[{type: "text", text: "This text was written by ", marks: [{type: "author", attrs: {author_id: 12}}]}, {type: "text", text: "me.", marks: [{type: "strong"}, {type: "author", attrs: {author_id: 114}}]}]

For this to work, one would need to add these marks every time text is inserted. And for deletion one would need to prevent the deletion and instead add a similar mark, but with a deletion attribute. This may be a bit too complex given the amount of labtime that is available.

Anyways, there may be other options I haven't thought about that make more sense. Feel free to think something up.

[1] https://www.npmjs.com/package/htmldiff (Haven't tried it, just something I randomly came across)

@stashkov One more detail FYI: Our python backend is currently not able to understand much of the JSON structure fo the files, nor does it understand the steps/diffs. This is all only handled in the Javascript frontend. I have made the Python backend make changes to the JSON in the case in the case of database migrations, but this was just so it ccould open files, make one change to it and save it again. In theory the entire logic of changes, etc. could be ported to Python, but also this would be a lot of work.

@stashkov I ran Travis again tday. No error. Travis installs a full copy of fidus writer on a virgin Ubuntu machine every time and then executed a number of tests. So if there were any problems with it, it should have shown.

Summary

table document_documentrevision

Has one-to-many relation document_id to revision_id. Does not contain information about what's inside the article.

table document_document

document_document.contents has most verbose representation of an article

document_document.metadata looks like something that can be used for history quite easily

document_document.settings some some of signatures which is appended to contents field at the end (why there is 2 fields which are almost exactly the same?)

document_document.last_diffs something which can be useful (judging by the name), but it's very verbose

files *.fidus

snapshots of the document (versions) are saved as files here /fiduswriter/media/revision/$document_id$/filename.fidus (not quite the raw text, but can(?) be used)

Looks like that's all we have which is of some relation to history of an article

@stashkov Yes, you are on to something here.

table document_document

document_document.metadata currently stores an HTML version of various elements of the document. It is not being used for antyhing currently. Used to be used for certain types of seting data.

document_document.last_diffs these are up to the last 500 or so diffs that have been sent around during collaborative document editing. We try to keep as few as possible, as they take up space and because they are problematic when upgrading from one FW version to another as the format may change, but we keep a few in case a client has disconnected temporarily.

files *.fidus

snapshots of the document (versions) are saved as files here /fiduswriter/media/revision/$document_id$/filename.fidus (not quite the raw text, but can(?) be used)

These files are connected with table document_documentrevision to document_document (You should really go through Django to access the database, otherwise you'll kill yourself trying to make it work). These are zip files that can be loaded into the the Fidus Writer client (browser) and be turned into fidus documents, fidus documents can then be turned into HTML using the prosemirror libraries in the client.

---

Conclusion: If you want to show the difference between two revisions of a django file, or a revision and the current state of the file, you can request the two revisions from the client, then transform them into an HTML structure using the prosemirror methods, and then use some JavaScript html diffing tool to show the difference to the user.

@johanneswilm I've taken a look at what you suggested, and mostly do exactly what you said. I'm gonna use .fidus files in revisions folder to compare between two revisions and also to the current version. But I'm not sure yet about converting them to HTML, that part is yet to be decided.

Could you describe how do you see a user story for this process?

My idea is as follows: I am a writer and I want to see what has changed in the last versions. I expect it to somewhere in my revisions of the article. Therefore,

On the main page, which lists all the documents, there is a column "revisions" (along with created, last changed, owner etc.). I click on on the clock symbol for specified file in revisions column, and I see "time" ,"description", "re-created", "download".

I would there to be a compare button/column, such that if I select 2 revisions it will redirect me to a page which shows the difference and that looks something like this

@stashkov

But I'm not sure yet about converting them to HTML, that part is yet to be decided.

This part was mainly to make it easier for you to diff them because I assume that there are tools out that that making displaying diffs between HTML structures easier. But if you find that you prefer working with the json, that should work just as well.

Could you describe how do you see a user story for this process?

Your story is good, but I don't understand your link:

like this

Does that commit hold anything in particular? Or do you just mean that it should look somewhat like a github diff? Somewhat like diff on github would be perfect.

In addition, this story:

I am a writer and I have written a document a few months ago. I first wrote an article for the "Garden Journal" about flowers and bees and sent it in. I saved a revision when I sent the article in and called it "garden journal". Some weeks later, the Garden Journal sent me a rejection letter, so I went back to the document, and started editing it again. This time I wanted to send it to the "International Journal of Honey Bees" (IJHB), so I removed most things about flowers and sent it in and saved it under another revision with the title "bee journal". After work one day I had a little wine and I felt this was a good time to edit the document again. I added a lot about why bees don't get drunk on nectar that night. I didn't create a revision.

Three months have passed. Now I received a letter from the IJHB. Hurray! They didn't reject me this time, but they let me know that I should revise my work. Among other things, they feel I should add more about flowers and possibly about bees getting drunk.

Because this has all been so long ago, and I don't remember exactly what i did that night with the wine, I need a history feature in the editor to find out what the difference between the different revisions (and the current doc) is, to decide what version I should start out from. I may also want to copy and paste some from the other versions.

Therefore, on the main page, which lists all the documents, there is a column "revisions" (along with created, last changed, owner etc.). I click on on the clock symbol for specified file in revisions column, and I see "time" ,"description", "re-created", "download".

I would there to be a compare button/column, such that if I select 2 revisions it will redirect me to a page which shows the difference between differenmt revisions. I would also like to see a way how a specific revision compares with the current (latest) state of the document.

Does that commit hold anything in particular? Or do you just mean that it should look somewhat like a github diff? Somewhat like diff on github would be perfect.

Yes, the link was just to show that it will look something like github diff

@johanneswilm

Here are my thoughts on your proposition to add 3 different features. 3 features being:

1. compare 2 revisions of your choice (e.g. out of 5, compare 1 with 3)
2. compare chosen revision with latest revision
3. compare chosen revision with previous revision

I think adding all 3 is a bit of an overkill, because user will not be patient enough to decide which of 3 is the best way to solve their task. Plus, the interface will be crowded with too many buttons, which will be fairly confusing.

Quite honestly, I don't see a use case for 1. Everything I can come up with can be solved with 2 or 3.

Here's my proposition. If you take a look at the screenshot you can see that on each line I want to add 2 links:

• one will compare chosen revision with previous revision
• another will compare chosen revisions with latest revision

Ideally, there has to be a single button that does either 2 or 3 but I can't decide which one. Or we keep both 2 and 3.

What do you think?

@stashkov

Here are my thoughts on your proposition to add 3 different features. 3 features being:

1. compare 2 revisions of your choice (e.g. out of 5, compare 1 with 3)
2. compare chosen revision with latest revision
3. compare chosen revision with previous revision

This sums it up very well.

I think adding all 3 is a bit of an overkill, because user will not be patient enough to decide which of 3 is the best way to solve their task. Plus, the interface will be crowded with too many buttons, which will be fairly confusing.

Indeed, you have a point.

Quite honestly, I don't see a use case for 1. Everything I can come up with can be solved with 2 or 3.

You may be right. One factor is also that there is likely to be only a limited number of revisions -- maybe 2 or 5 or something in that order. Not 100s. So in the rare cases where the user may really want to compare say version 1 with 3 out of five, the user can probably get just as much information by using one of the other two types of comparisons. So skiping this one seems fine.

Ideally, there has to be a single button that does either 2 or 3 but I can't decide which one. Or we keep both 2 and 3.

Hmm, yes that is a difficult choice. You may be right that it may be the best to keep both. Ideally we would also use icons, but I can see that it will get really difficult to come up with icons that clearly explain what the purpose of those two buttons would be.

So yes, the choice is yours.

Hi , Myself Nagesh , I am working on Track changes part in fidus writer . I was trying to use jsdiff(https://github.com/kpdecker/jsdiff) for comparing two strings character by character I have the original content when file loads in one variable and changed content of document in another variable . To use Jsdiff.diffchars i need to import jsdiff into path "fiduswriter/static-es5/js/editor.es5.js " as require("diff.js").

But when I run "npm install diff --save" and try require("diff.js") in editor.es5.js , i get module cannot be found . I have tried placing this file in many places and still not able to get a solution . Where should i have this installed diff folder and how can i access it in "fiduswriter/static-es5/js/editor.es5.js"?

editor.es5.txt

@TrNagesh Hey, nice thta you have started on this!

First thing: Don't work on the ES5 files. The ES5 files are transpiled from ES6, so you should always work on the ES6 files.

To transpile from ES6 to ES5, run

./manage.py transpile

The next is the import statetement -- these follow ES6 guidelines. Look at some of the other files inside the es6_modules folders.

@johanneswilm Thanks for the information. I have made changes on ES6 files . I am collecting the changes made by individual user . Now I need to broadcast this to all the browser where the file is opened . I am not getting the code or file where I can make necessary changes for this . Is there any existing js file where broadcasting to all browsers is already implemented ?

@TrNagesh Yes, if this is in the editor, take a look at

https://github.com/fiduswriter/fiduswriter/blob/develop/document/static/js/es6_modules/editor/server-communications.js

On the server side the communicatiosn are coordinated in

https://github.com/fiduswriter/fiduswriter/blob/develop/document/ws_views.py

@johanneswilm Thanks for the information. Is there any particular method in the file "ws_views.py" that I can look for?

It depends on what you are trying to do. That file basically opens, closes and saves documents and maintains communications between collaborators of that file.

@johanneswilm Thank you. In the file https://github.com/fiduswriter/fiduswriter/blob/develop/document/static/js/es6_modules/editor/collab/index.js - I am getting participants ID´s . Can I use this file to broadcast the changes to participants?