Add a new property "userID" to the "class ID" in the yjs rep

[folencao]

Is your feature request related to a problem? Please describe.
We use y-websocket and trying to know which user did the change in the ydoc.on("update") event on the server, currently, the update message data include the client which can get by Y.decodeUpdate(update).structs[0].id.client, but as the client value will be changed for the same user, so one user may have many client values, it is hard to track client value map to which user unless we persist all the data of client <> user(too many data).

Describe the solution you'd like
Add a new property userID to the class ID in the yjs rep(utils/ID.js), ideally we can pass this userID in the y.Doc constructor, every update message will include the userID like id.client property which from createID function, so we can get the userID from the update message easily, also this userID can be used to highlight the change text as well(in the prosemirror-versions rep/project).

We need to persist all the historical update data, so include the userID in the update message will be very useful, especially when you check an old update as the client value already changed for that user, but the userID never change.

[dmonad]

The clientID is supposed to be randomly generated. Tracking changes is supposed to work with PermanentUserData not by setting a clientID manually. I discussed this at lengths several times. Please have a look at the discussion board discussions: discuss.yjs.dev

[folencao]

Appreciate your reply @dmonad, I saw the discussion about clientID, I was not saying set or change clientID, I was saying add a new property userID to the class ID which already includes the client and clock properties.

The userID will be the userID in the specific app for one user, so with the new property userID we can identify which user did the change easily(update event in the backend).

The problem of clientID is it will change for certain user if refresh the page or close and reopen the app, so there will be many clientID values for one user and we have to persist these clientID values in order to know the real user in the future. It is fine that yjs internally use clientID, but for the app that uses the yjs/y-websocket, the new property userID will be useful.

[folencao]

@dmonad - Basically the new suggested property userID can think of a customData, so different app can set this custom data when new Y.Doc({customData}) and use it for different purpose, just for our app, we want it to be the userID which never change for specific user.

[dmonad]

This is what PermanentUserData is for. It maps from user-identifier to a list of clientIDs. It also keeps track of deletions.

I will not add userID to the ID object because that would be a huge performance issue for Yjs. Ideally, you shouldn't even come in contact with the ID class. There can be A LOT of instances of the ID class (in the worst-case one ID instance for every single character). So we need to make sure that it is represented efficiently in memory. userID is duplicate information because it can be derived from the clientID - which is why PermanentUserData exists.

[folencao]

@dmonad - Appreciate your explanation, that's fine, we will implement and maintain the relationship between the clientID and userID on our side.