I was doing some first steps with gundb and it looks nice. But I'm having trouble to come up with a solution I would need for an application I'm planning.
It is actually a pretty common use case, there should be a group of users that are allowed to write posts, but all users should be able to read them.
In the documentation there is written a lot about how to heandle read access, but I couldn't find anything about how to handle write access to some data.
Is there a code example somewhere for this? And how does gun handle write permissions in general (some documentation / explanation)?
@gwildu restricted write access with public read is currently easier/beta in SEA (Security, Encryption, Authorization - GUN's permissions framework) than doing private read access (although this is perfectly possible already directly using SEA's lower level utility API, docs here). Although we're working on improving ease-of-use, abstractions/API, and other for it.
So the first thing you need to know is summarized in this fairly short guide:
That will cover introducing you to GUN's cryptographic concepts as well as how easy it is to create and login into a user.
The next step, you'll see is that writes to the gun.user() object have the same API as gun but automatically defaults it to be write-restricted (to that user, nobody else can tamper with it) and public-read.
So as of today (2018/6/27) you can use this to achieve what you want. All you need to know is the which users you want a write to come from, and then subscribe to it. With a bit of extra code, you can do this today (hit up the https://gitter.im/amark/gun for help!)
In the future, you can expect an API like this:
user.get('thingOthers').get('canWriteTo').trust(alice)
Now when you subscribe to the data, you'd get back realtime updates from those who you have allowed to write to the data:
user.get('thingOthers').get('canWriteTo').on(data => console.log(data))
Depending upon your use case (and possibly a slightly different API, but hopefully not), this would also work for others reading your data.
For instance, assume you were user Bob (so Bob added Alice as write-access), and some 3rd party viewer, say Carl wants to read Bob's data, if they were to:
bob.get('thingsOthers').get('canWriteTo').on(data => console.log(data))
It would subscribe to realtime updates from only those allowed to write to the data.
Why is there a difference here, what is the nuance you should be aware of?
A) A person may want to trust what somebody else says but NOT trust somebody else to speak on their behalf.
B) If you do trust somebody to speak on your behalf, viewers (like Carl) now must trust an authorizer (Bob) that Alice is permitted to say something. This could be come dangerously centralized!!! (From a trust/permission model, even if the algorithms are P2P/decentralized underneath, which GUN is.)
So while (A) may be a little bit more complicated nuance to understand or manage, it may be the better route. (B) is a little bit easier to think about, but could lead to centralized authority (as in, all Carls in the world just trust Bob to make decisions for them, when it would be better if Carls [using (A)] to decide who they think should have authority.)
So for instance, Bob added Alice as write-access, but Carl could too! That way if Bob and Carl ever disagree on who should have write access, they don't have to trust each other! They would both see what they allow, but not what the other allows.
Obviously, for a lot of applications, it makes sense for everybody to be "on the same page" and have all Carls' just trust Bob as determining who can write data. So (B) is still a good option, just know the implications, and know there are alternative models for trust!