Hey @RangerMauve, I want to outline my current approach for y-dat to you.
My approach is similar to the multiwriter approach described in https://www.datprotocol.com/deps/0008-multiwriter/. Each user would basically create their own feed for writing Yjs document updates. Users can invite/authorize other users by writing the public key to their feed. But there is no need for a clock-vector, because Yjs already handles that.
My only concern is that the user-experience of giving other users write permission to the document would be pretty bad. I read an example on how that would work here https://blog.datproject.org/2018/05/14/dat-shopping-list/ I wonder if there are better approaches to grant someone write access. Ideally you could just share a link. Would it be possible to have a special metadata-feed so that other users can self-register by sharing the private key of that metadata-feed? I know that there is a chance that two users write to that feed concurrently, but what does actually happen when they write concurrently?
NP @RangerMauve Weekends without chat programs are very recommendable! In the meantime I have been looking into Dat SDK - the API looks much cleaner now - and it works in node, beaker, and legacy browsers. Really cool!
The authentication solution you described definitely makes link-sharing easier. In terms of writing a note-taking app: My only concern about this extension-based solution is that it requires two clients (the client that registers itself and an authenticated client) to open the same document at the same time to actually persist the information that a feed was added.
No matter how I look at it, it won't be possible to provide link-sharing functionality similar to other note-taking apps. Another solution to this problem might be to create ask-for-permission links. The user interaction would go somehow like this: Author sends read-only link to remote client. Remote client asks for permission by adding their Hypercore-key to the link and sending it back to the authenticated client. The remote user can immediately start working on the document. The authenticated client then can accept their changes by adding the remote Hypercore-key to the local Hypercore, or do nothing and ignore the remote changes.
Another interesting solution would be to add a trusted peer (one that also persists) to the network. This would also integrate perfectly with your extension-based solution.
At this time there doesn't seem to be a better solution to the authentication problem (none that I can adapt the protocol for), so I will probably go with my approach and just provide authentication functions for authenticating remote users. You should be able to implement the link-based approach and the extension-based approach on top of this.
lib0/testing.js. Have you ever run into that? Dunno what I'm missing. I tried building some older releases from source and had the same problem.
With the current code, if there is no local state, it falls back to an empty {}. In that case
cursor is undefined, rather than null. If the 119 when we check if it is not null, it actually passes that test, and the plugin calls setLocalStateField, setting the cursor to null, which ends up triggering updateCursorInfo again, causing an infinite loop, it seems.The fix was to explicitly set the cursor property to null on line #104 so that the explicit comparisons to null would work correctly, i.e.
const current = awareness.getLocalState() || { cursor: null }
setTimeout(() => { prosemirrorView.state['y-sync$'].binding._forceRerender() }, 0)
Thanks for bringing this up @WinstonFassett
I forgot to make an implicit comparison in the awareness cursor state. aw.cursor === undefined is a valid state, so I made sure to only make implicit checks (aw.cursor == null checks for undefined and null).
For the other issue (rendering the initial state), I now force rerender after view creation. Sorry, I never stumbled on this issue because in the demos I always start with an empty document (the server syncs after view creation).
Both issues are fixes in y-prosemirror@0.1.3.
About local development: lib0, Yjs, and y-protocols are always mentioned as peerDependecies. I forgot to add lib0 as a devDependency in package.json. Thanks for the hint. Would it be helpful to you if I describe my dev-setup? Sometimes it is necessary to debug multiple packages. In this case I clone all y-* modules (including lib0 and yjs-demos), put them in a single repository and build with LOCALIMPORTS=1(an environment variable). I could describe this setup in more detail if this is helpful to you.
Hey @WinstonFassett Sorry for the confusion. I do plan to add more persistence layers for v13. The new API makes it much easier to build custom persistence layers (I'm talking about this section). Someone just recently asked the same question about Leveldb here: yjs/yjs#170 - this thread might be interesting to you.
For now the best approach would be to either build your own persistence, contribute to y-leveldb :slight_smile:, or wait for me to add it eventually. @calibr kindly shared his leveldb approach in the above ticket.
I'm currently working on y-dat and I want to publish a simple demo app with y-dat to test if y-dat is viable in practice.