Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If you put data in a key with one gun instance, then change that data on another gun instance, the first instance will be unable to read the change #1330

Open
ViteOrder opened this issue May 29, 2023 · 5 comments

Comments

@ViteOrder
Copy link

ViteOrder commented May 29, 2023

Minimal reproduable example, would print true twice if there werent a bug.

Heres a senario where having multiple instances is handy: You want to give someone else permission to write certificates for a node, so you make that node its own SEApair, and give you and that other person a copy of the pair. Now you and your friend write data into it by making a new gun instance, and authing into it.

@amark
Copy link
Owner

amark commented Jun 1, 2023

Peering the 2 instances will work (erm... there's an example of how to do this buried somewhere)

But it may be pretty hard to do this without because it means the adapter has to be aware of changes/modifications to the filesystem, and it would need to know how to do this uniformly across all file systems (browser, cloud, desktop, etc.) which would complicate things pretty quickly.

Without peering, GUN has no way of knowing whether the 2 instances aren't actually separate machines, threads, processes, etc. do you have any clever ideas?

@draeder
Copy link
Contributor

draeder commented Jun 1, 2023

If I'm not misunderstanding the issue and example, I believe that the desired use-case is what I did with Gunsafe CLI's sync functionality.

@ViteOrder
Copy link
Author

ViteOrder commented Jun 1, 2023

I dont know about any of this peering buiness. For my usecase, if I were just able to be authed into multiple users on one instance, I'd be golden

Maybe if the put function had an option like this:
.put(data, undefined, {opt: {putAsUser: SEApair}})
now that would be perfect

@draeder
Copy link
Contributor

draeder commented Jun 1, 2023

I think what you're looking for is GUN's Certify

@dirtboll
Copy link

dirtboll commented Jun 3, 2023

I've stumbled across this issue too when I tried to write unit tests for different gun instances with different users. After reading the localStorage.js I thought it was impossible to sync between two local peers only through the storage layer since gun only read the db once at "create" event (cmiiw). Soon it's confirmed by Mark that it needs peering. I also considered to use SEA.certify() but it gives me privacy issue for my use case since gun sends the certificate along with the associated public key for every put using it. Though I'm interested to know how to put for multiple user without login or certify.

For now, I just use peering as a workaround. I didn't aware that there's documented example to do this so I implemented my own. :/

Here's what I've come up with.

function makePeerFrom(gun) {
  let { mesh, pid } = gun.back("opt"), peer = {
     id: pid,
     wire: {
       send(msg) { if (msg) mesh.hear(msg, peer); }
     }
  }
  return peer
}

function doPeering(gun1, gun2) {
   let [peer1, peer2] = [makePeerFrom(gun1), makePeerFrom(gun2)]
   let [{mesh: mesh1}, {mesh: mesh2}] = [gun1.back("opt"), gun2.back("opt")]
   mesh1.hi(peer2)
   mesh2.hi(peer1)
}

I've updated the code from your example with my method, it now prints true twice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants