I didn't get a too much done today, but I'm starting to experiment with websocket bittorrent trackers and I also looked at i2p. i2p is not designed to work within the browser and I don't see it being easy to connect to without proxies which kind of defeats the purpose.
One thing that I didn't talk about yesterday is that for browser-based nodes to connect to each other directly you have to use webrtc, which has some limitations that must be worked around. For two browser-based nodes, to connect to each other, they must both create an SDP and somehow get the SDP transferred across to the other party. These SDP's can only be used for a single connection. So I wouldn't be able to, for example simply have a node publish its SDP somewhere, because I cannot allow multiple peers to try to connect to the same SDP (I'm actually not quite sure what would happen if two or more other peers did try to use a single node's SDP, but given there so many different types of browsers, it would be difficult in general to say).
This seems to be solved already for me, if I just use existing websocket bittorrent trackers. There aren't that many of them, at least according to here: https://github.com/ngosang/trackerslist/blob/master/trackers_all_ws.txt , so I don't want to rely on this solely. So in addition, I'm thinking of making a Captain Dirgo daemon along with the extension that uses an incoming port. Having actual daemon's in the network would open up additional possiblities, such as publishing that daemon using regular bittorrent trackers and Mainline DHT, which would be much more robust.
The only problem here is what is the incentive? I don't believe that many people would be interested in altrustically supporting the network, because what I've seen with most systems like that is that they languish, especially when they are not very well known (maybe Tor as an exception). So, running the daemon would enhance the score of a user associated with it. It would do so, by making anyone who connects to the app use PoW (as I described yesterday) to have it perform services.
I didn't get a too much done today, but I'm starting to experiment with websocket bittorrent trackers and I also looked at i2p. i2p is not designed to work within the browser and I don't see it being easy to connect to without proxies which kind of defeats the purpose.
One thing that I didn't talk about yesterday is that for browser-based nodes to connect to each other directly you have to use webrtc, which has some limitations that must be worked around. For two browser-based nodes, to connect to each other, they must both create an SDP and somehow get the SDP transferred across to the other party. These SDP's can only be used for a single connection. So I wouldn't be able to, for example simply have a node publish its SDP somewhere, because I cannot allow multiple peers to try to connect to the same SDP (I'm actually not quite sure what would happen if two or more other peers did try to use a single node's SDP, but given there so many different types of browsers, it would be difficult in general to say).
This seems to be solved already for me, if I just use existing websocket bittorrent trackers. There aren't that many of them, at least according to here: https://github.com/ngosang/trackerslist/blob/master/trackers_all_ws.txt , so I don't want to rely on this solely. So in addition, I'm thinking of making a Captain Dirgo daemon along with the extension that uses an incoming port. Having actual daemon's in the network would open up additional possiblities, such as publishing that daemon using regular bittorrent trackers and Mainline DHT, which would be much more robust.
The only problem here is what is the incentive? I don't believe that many people would be interested in altrustically supporting the network, because what I've seen with most systems like that is that they languish, especially when they are not very well known (maybe Tor as an exception). So, running the daemon would enhance the score of a user associated with it. It would do so, by making anyone who connects to the app use PoW (as I described yesterday) to have it perform services.
(post is archived)