Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2024 Poal.co

1.1K

I was thinking about DHT and I'm not quite sure if it's the best network. The main problem is that it is focused on short simple messages to many different peers, which works well for UDP. However, since I want to be able to have browsers be full nodes on the network, I am relegated to using WebRTC, which is a much slower protocol when establishing connections.

I'm not sure what the implications of that are, and whether it will be a problem or not. I think I need to do some experimentation on that.

The other idea is to use freenet's algorithm, which has long standing connections and would be a better fit for WebRTC. I only skimmed freenet's whitepaper, so I need to delve into it more deeply so that I can better make a decision.

Other than that, I came up with an initial roadmap for Captain Dirgo, which is subject to change which is still based on DHT.

The idea is that version 1 would make it necessary to run a daemon along side the browser. Version 2 would allow firefox to not need a daemon anymore, and version 3 should work with chrome and other browsers.

Below is the breakdown of the roadmap on a rough architectural level:

Version 1:

  • node ids are ip and a public key (like bittorent BEP42 and s/kademlia)
  • public key is used as a user id
  • we only have a DHT network, nothing underneath
  • DHT contains:
    • nodeid - address/port (in the future, webrtc, etc.)
    • userdata - a separate key from userid, contains data associated to user, good and bad. Split into 3 separate locations to prevent fuckery. (using hash of nodeid+1, nodeid+2, nodeid+3). T
    • username - the userid associated with a username ... do we really want this?
    • urlstart - keyed of the hashed url, contains block, or a merkle tree root of contained blocks
    • url+block - a merkle tree node of a url (referenced by a higher up url+block or urlstart)
  • To write a message, upvote, etc. a put_value is run
  • To use must run a daemon app that browser locally connects to
  • nodes keep a log of estimated network size (for determining if other nodes are considered trustworthy given their distance to the infohash)
  • upvotes give proof of work

Version 2:

  • webrtc integration
    • we need websocket support in the daemons
    • we have special messages for SDP, add, claim (and responses confirming or denying the claim)
  • firefox support w/o daemon
  • chrome still needs daemon

Version 2.1

  • chrome support w/o daemon (hopefully)

Version 3:

  • Global state, blockchain.
I was thinking about DHT and I'm not quite sure if it's the best network. The main problem is that it is focused on short simple messages to many different peers, which works well for UDP. However, since I want to be able to have browsers be full nodes on the network, I am relegated to using WebRTC, which is a much slower protocol when establishing connections. I'm not sure what the implications of that are, and whether it will be a problem or not. I think I need to do some experimentation on that. The other idea is to use freenet's algorithm, which has long standing connections and would be a better fit for WebRTC. I only skimmed freenet's whitepaper, so I need to delve into it more deeply so that I can better make a decision. Other than that, I came up with an initial roadmap for Captain Dirgo, which is subject to change which is still based on DHT. The idea is that version 1 would make it necessary to run a daemon along side the browser. Version 2 would allow firefox to not need a daemon anymore, and version 3 should work with chrome and other browsers. Below is the breakdown of the roadmap on a rough architectural level: Version 1: * node ids are ip and a public key (like bittorent BEP42 and s/kademlia) * public key is used as a user id * we only have a DHT network, nothing underneath * DHT contains: - nodeid - address/port (in the future, webrtc, etc.) - userdata - a separate key from userid, contains data associated to user, good and bad. Split into 3 separate locations to prevent fuckery. (using hash of nodeid+1, nodeid+2, nodeid+3). T - username - the userid associated with a username ... do we really want this? - urlstart - keyed of the hashed url, contains block, or a merkle tree root of contained blocks - url+block - a merkle tree node of a url (referenced by a higher up url+block or urlstart) * To write a message, upvote, etc. a put_value is run * To use must run a daemon app that browser locally connects to * nodes keep a log of estimated network size (for determining if other nodes are considered trustworthy given their distance to the infohash) * upvotes give proof of work Version 2: * webrtc integration - we need websocket support in the daemons - we have special messages for SDP, add, claim (and responses confirming or denying the claim) * firefox support w/o daemon * chrome still needs daemon Version 2.1 * chrome support w/o daemon (hopefully) Version 3: * Global state, blockchain.

(post is archived)

You are currently inside a comment thread.
Click here to see all the comments (2).
[–] • 1 pt

I could be off here, but since you are planning to create a daemon to facilitate gets and puts from from your DHT anyway, which functions as a distributed file system, might it be easier to piggyback an existing distributed file system tool, like BTFS? I know it's a lot of infrastructure to front, but it's looking like you may end up here anyway?

Again, I could be way off....just a thought. https://www.bittorrent.com/token/bittorrent-file-system/

[–] • 0 pt (edited )

The problem is that these types of systems require some sort of payment to store data. I don't want to make Captain Dirgo a system where you need to pay to make comments. Just the friction of setting up an account with initial funding I would think make it a non-starter with a lot of people.

I know that some people think that a decentralized system where people store things for free is impossible, but my idea is that increasing your user score is a valid trade for running a daemon. Specifically, just like on poal.co where you get a little bee flair icon next to your username if you donate to the site, Captain Dirgo would give you a little flair icon if you run a daemon and/or extra points to your user score. It's an appeal to vanity rather than real money. I think that is better overall because once money is involved, people will search for any loophole to get more of it, but a trick to increase a user's vanity score would not catch on much at all, so it would help prevent disruptions.

The free non coin network already called freenet that I mentioned in my post has been running for over 20 years now. The way it works is that you have to run a daemon to connect to the network and by doing so agree to store encrypted but unknown files. I was thinking of possibly integrating with it, but I decided against it because I've heard that a lot of illegal things are stored there, and in order to run a node you'd need to store gigabytes of data and constantly be ferrying other peoples data back and forth who are primarily looking for videos/games/whatever. For only a comment system this is a lot of network and disk usage that would be burdened on the user if I went this way.

I could change my mind on having coin eventually, but for now it seems the best way to get a lot of people on board is to make signing up and using it as easy as possible.

Anyway, thanks for thinking about this. I really do appreciate other people's thoughts on it.