How does gun identify peers? Thank you for your help with this question. Time is precious, and I want to be sure this is a viable library before I take the days to experiment with it or develop with it.
How does gun identify peers?
I don't believe that it actually identifies anything. An instance knows it's peers that is it. If Authentication and permissions is what you are looking for, Gun doesn't (at least at this moment, I don't know the future plans for it) have any way of doing this. You can try to add something like that with SEA.js, I don't know much about how you could use it but it gives you cryto things such as proof of work. If you wanted to you could implement a permissions based system. I would wait for @amark To give you some more details and information though.
@masterex1000 thanks :) , @didlie he is correct, peers are hardcoded.
Edit: This has changed, 2019+ has automatic WebRTC signaling & discovery with
lib/webrtc.
If you want to know how to identify / discover new peers ontop of GUN, check out the https://gun.eco/docs/Service-Discovery page.
It would be great if you could copy this to StackOverflow tagged gun and also copy our answers, others will appreciate it a lot!
@amark ... so vague... a cartoon whitepaper. Is this WebRTC?
You can look at my "mirror" server for WebRTC here, its very complicated:
https://github.com/didlie/WEBRTC_PHP_MIRROR_SERVER/blob/master/mirror.php
@amark again, correct me if I'm wrong. It seems like that page is trying to be vague, WebRTC is just one way that peers can be connected, and is mostly limited to working in the browser. Gun doesn't have any built-in mechanic for discovering peers. What my impression is after reading that page is that it is explaining what you would need to do in regards to Gun in order to do that.
On another note... What do you mean that node isn't stable? Its just chrome's V8 engine in a server package! Even LinkedIn uses node for its backend! (I just really like node, maybe a bit to much 馃槂)
@masterex1000 ... first let me say, thanks for reading.
Second, Node may be wonderful, and I think it probably is, but if your project is server independence then Node is the devil... Node is the path to the deep abyss of server dependence.
What about using psudo-torrents for offer/answer passing in WebRTC?
Just an idea! Maybe you want to join my didlie.com project? https://didlie.com
Here is another repository you might benefit by looking at again: https://github.com/webtorrent/webtorrent
Sounds like times for one of those religious arguments about which techs are great and which suck :-)
My opinion - from the perspective of building apps on top of things ...
And working well with legacy / server-based apps, moving UI and eventually data from the server to peers is critically important to the takeoff of a new system. For example we are running GUN (under node) on one of our servers as a bridge between the backend database and Gun. (and doing similar things for WebTorrent and IPFS).
WebRTC is a great idea, but current implementations suck for decentralized web suck, I've been watching different companies drop it over the last year because it crashes the app, the browser or even the laptop. It doesn't seem to be designed for large numbers of low bandwidth connections (that are typical in DHTs etc).
Webtorrent is great - a good complement to Gun for handling immutable data. (as is IPFS)
Service Discovery is going to be crucial, its not something you want to be worrying about when building an app, having a variety of ways of handling it simply will be crucial if Gun is to grow.
I agree that service discovery is extremely important, too bad in most cases it either requires you to either re-invent the wheel or build your application around someone else's framework/lib. One thing to mention is that from my quick look at the WebTorrent repo is that it uses WebRTC.
From what I have seen, there is no good way to build a truly distributed app for web browsers right now. You have to rely on the main server. The idea of using a torrent like a system is a good idea, That's coming to the edge of what I know about distributed apps. (which is obviously not much)
What I think could work would be to have a main server running something like GUN that could keep a sort of ledger of all of the existing peers, then when a peer gets enough 'reputation' then it can automatically become a trusted peer that new clients would be able to connect to. I have no idea how one would go about this but it could work...
And continuing the debate about node...
I'm self-aware of the fact that I like my apps to be giant monoliths of code where all of the services to run an app are together. That could mostly be due to the fact that I don't have the infrastructure to be able to develop spread out apps.
I mainly try to stay clear of frameworks and libs that require you to deploy an app in a special way mainly because I like to be able to deploy it on anything that I want to deploy it on. That's one of the reasons I really like Gun. I don't need to roll a separate server/application to run a database when I'm messing around and building projects.
I probably should roll many different servers that allow me to be even more scalable but in reality, if you aren't getting contracted for the work and its just for fun does it really matter? If you really need an app to be distributed then that's where micro-services would come into play.
Node.js Isn't just going to straight up die and even if it did that wouldn't affect any of your runnings instances. It's mainly up to personal preference at the end of the day.
@mitra42 @amark @masterex1000
I am working on experiments for didlie.com, and welcoming comments on this concept:
1) passing WebRTC localDescription via WebTorrent.
?why:
a) because the byte-size on the server will be minimized, and raw-byte minimization might be the only path to server-independence b) candidates are created in the same process that enables multiple file-sharing via torrents, and direct P2P connections, c) WebTorrents WebRTC program flow appears to be relatively mature.
Opinions please.
I want to use gun for a namespace ownership blockchain, but the solution has one major drawback: user neglect of ownership, vacant squating... I don't think its viable to have a distributed-ownership application where keys to namespaces can be lost and owners can squat without contributing to the network...:: owners should contribute to the network. This is the fundamental concept for server-independence for Didlie.com.
Opinions please.
GUN now does automatic peer signaling and discovery with the lib/webrtc module.
This update per a Twitter discussion citing this 1+ year old thread is evidence contrary.
To get started with discovery, check out the 5 min tutorial: https://gun.eco/docs/Todo-Dapp
@didlie I apologize about missing your comment! Have you looked into SEA 's gun.user() for user ownership and namespacing? It uses cryptographic keys to establish ownership, how to get started with it is also in the above tutorial.
Most helpful comment
Sounds like times for one of those religious arguments about which techs are great and which suck :-)
My opinion - from the perspective of building apps on top of things ...
And working well with legacy / server-based apps, moving UI and eventually data from the server to peers is critically important to the takeoff of a new system. For example we are running GUN (under node) on one of our servers as a bridge between the backend database and Gun. (and doing similar things for WebTorrent and IPFS).
WebRTC is a great idea, but current implementations suck for decentralized web suck, I've been watching different companies drop it over the last year because it crashes the app, the browser or even the laptop. It doesn't seem to be designed for large numbers of low bandwidth connections (that are typical in DHTs etc).
Webtorrent is great - a good complement to Gun for handling immutable data. (as is IPFS)
Service Discovery is going to be crucial, its not something you want to be worrying about when building an app, having a variety of ways of handling it simply will be crucial if Gun is to grow.