Thoughts? I'm not a dev any more, but thinking about Bitcoin and other stuff maybe there are some ways forward that we've missed...
Dispute resolution, spam and distributed data structures -------------------------------------------------------- A key is disputable if: 1) It is an SSK or similar signature-based type where multiple valid values are possible, and 2) It is popular enough for ULPRs et kick in, i.e. most nodes have copies of and ULPR subscriptions to this key. For any disputable key, any darknet node can vote at most once. Votes are relayed in a fixed path across the darknet, so that only one vote passes a given directed edge for a given key. Ideally, votes are blind while they are being routed; the previous iteration of the key publishes a public key and then later broadcasts the private key. It follows that votes are pseudonymous (i.e. can be correlated), and heterogeneous node degree may reduce some people's voting power. However overall this should be Good Enough (tm). Disputable keys are used for the root of big distributed datastructures, such as the set of all valid posters on WoT, a keyword search index, a PKI indexed by any suitable identifier etc. (A block chain is of course another way to do this) We can enforce any set of invariants on such data structures via the voting system, as well as incorporating explicit user input. For example: The agreed root is the root of a hash tree. But we don't need to traverse the tree: - The index is divided by hash length into blocks of a large enough size that the individual blocks won't fall out. - The root includes the minimum and maximum USK offsets for all blocks in the index. It includes the base hashes for this version and the last few versions of the root. - As long as this range is small, we can fetch a block directly by its hash. The block will contain proof that it is included in the hash tree. This proof includes the actual CHK nodes as blobs, which will be randomly inserted/healed. - Each node also includes version range information. - All updates to the tree must maintain the invariant that the gap between the minimum and maximum value is reasonable. We can enforce this using the voting system above. In the absence of detectable attacks, hashing should tend to ensure this anyway. Ideally there would be only one such tree, so that we could use classic timestamping service tricks such as publishing the current hash etc. Thoughts on network architecture -------------------------------- We can provide strong anonymity, and reasonable robustness guarantees on a darknet. We can't achieve this on an opennet. We still need some sort of guest mode, and we need strong incentives to move to the proper darknet. So what should Freenet look like? Core darknet - High uptime, reasonable bandwidth. - Many F2F links. - Eligible to participate in dispute resolution as above. - Stores data permanently, i.e. has a store not just a cache. - Some tunneling system similar to PISCES for privacy. - Single coherent network. Non-core darknet - Similar to darknet, but lower performance. - May be penalised by load management. - May have less access to dispute resolution because of having very few links. - May still use tunneling. - In extreme cases (e.g. 1 link), lower security / need to trust peers more. Gateway nodes - Hybrid, connect to both opennet and darknet nodes. - Eligible to become a seednode; responds to announcements. - May also qualify as core darknet nodes. - Must be able to prove connectivity to the Core Darknet. - Requests entering guests are treated as lower priority than intra-darknet traffic, and reset HTL when they become true darknet traffic. - Requests are never routed from darknet to opennet. Guest/opennet nodes - Cache only. No store. - User requests a set of gateways from a seed service. - If true transient, entirely reliant on gateway. Requests are sent directly to the gateway, possibly using tunneling. Tunneling requires trusting the gateway, although if there are multiple gateways we can compare them, especially we keep a versioned network map using the dispute resolution mechanism. - If semi-permanent, can announce to gateways and get a bunch of opennet nodes to talk to. Requests will be routed through local opennet for some limited HTL, and then sent to gateway. - Limited to no access to dispute resolution. Seeds: - Any gateway may be a seed, and gateways' identities are assumed to be public. - Seed service maintains a list of gateways, demands some trivial proof of work (e.g. CAPTCHA, unique gmail address a la Tor), and returns a list of gateways and access tokens. - Seed service requires gateways to prove their connectivity to core darknet, and may implement its own scarcity, robustness and connectivity policies.
