Added it in https://github.com/LeonardPauli/gun-level/tree/48-no-key-crash (npm install gun-level-lptmp)

@leonardpauli if you submit a pull request with this we'll accept it and get it merged :D

@amark I ran into this same error.

TL;DR

Think it hasn't something to do with Gun user not existing on server node. Just a hunch

Environment: Chrome Latest, Node 8.11.2, Mac OS X

Repos

• Gun Server Repo(copy of the gun-starter-app that is setup to use level-down as the storage): https://github.com/509dave16/random-that-server
• Client App Repop: https://github.com/509dave16/random-that.git.
  • Branch feature/rt-gun.auth.fixes is what I'm currently working off where the error is happening.

Reproduction

Here's the rough step of steps to reproduce error:

1. Start dev server for client app(i.e. should default to port 8080)
2. Start the gun server on port 8081
3. When I attempt to do gun.user().auth(<username>,<password>, cb) the expected ack is returned. But this caused the gun.off error on the server. Might have something to do with the user not existing yet.

Screenshots/Gif

And here's some screenshots and a gif.

Code Snippets

• Client service where gun and gun user are instantiated: https://github.com/509dave16/random-that/blob/master/src/common/services/gun.service.ts
• Auth service where gun is utilized(everything is promisified) : https://github.com/509dave16/random-that/blob/feature/rt-gun.auth.fixes/src/common/services/auth.service.ts

@509dave16 your project looks really cool, I'd love to hear more? Thanks for a detailed report, it is exceptional!!

This issue is specific to gun-level or GUN in general? Because gun.user is from SEA in the main repo, not gun-level.

If this is specific to gun-level, I can't guarantee gun-level staying up to date with main GUN (the localStorage version is officially maintained). We have a new thing called RAD for GUN that is intended to replace most storage systems (and will probably have its own indexedDB plugin that will have more official support, but that is a ways out), however it isn't quite stable/ready yet.

So I don't want to slow down progress on your app just because of gun-level. Are you able to avoid it for now?

@amark Really appreciate the reply. And that is good point you made regarding the scope. Should try to do some unauthenticated ops separately and compare results. I’ll probably stick with localStorage or IndexedDB adapters for the moment moving forward.

I have been looking at syncing solutions because my consulting company is trying to get a custom Google Forms like product released that has syncing incorporated. So that we have some passive income. Currently the app has a php api with manual polling and the different client implementations have been using local storage. Which we have found is quite slow. Data would be sectioned off by companies. And then people given links to different forms would fill them out as an application(instance of the form data). The forms could be filled out offline and then be pushed to the server/peers when online. Likewise if there were any additions to the forms that needed to be filled out, those would be pushed up to device when back online.

I investigated Realm.js but it is limited to React Native at the moment. Though it did have access control levels. I have investigated using PouchDB with Couch base or CouchDB as well. Doing little demos with them. Even wrote a relational orm around relational-pouch: https://github.com/509dave16/ranksdb. But then found about RxDB which does that better. Problem with those is the locked down single js function solution to write access. And read access is only scoped at a database level. Can’t go as fine grained as documents. And deployment is somewhat hairy. And I was using superlogin to handle one database per user which is no longer maintained.

So then I found Gun.js, OrbitDB, and SyncedDB. I went with Gun.js because it’s smallest, actively maintained, most storage adapters, and it’s ACL/node level permissions are promising. I plan to write a NanoSQL adapter for gun. Then on the server or client where intensive reporting like logic needs to be done, complex queries could be performed.

The sample app you see above is just an app for cycling through randomized selections of whatever you might want to randomize. Like those extreme sports you talked about in a talk you have ;) .Here’s a demo hosted site: https://random-that.firebaseapp.com/lists
This uses just in memory seed data. And I was just working on converting it to use Gun.js for persistence and auth. Only really concerned with this on a per user basis. No sharing. The randomizing app is just for testing the waters for the most part.

But I did run into problems where clearing cookies in the browser. Removed any users
created by Gun.user().create(...). Was hoping that created users would be replicated to nodes. Like one on a server.

I can create a separate issue for that.

There are a bunch of sync and performance concerns with our current api for the forms product. Hoping Gun could be an alternative for us. We’ll also be doing for client work a contact management app as well as a similar forms app for a heater company as a PWA.

@amark Switching to another adapter completely avoided the issue I was encountering. Thanks for your input today.

@509dave16 sounds awesome. Great work. Thanks for the deeper understanding/explanation!