>> I know the meaning of the individual words, and the structure of the >>sentence, but not the meaning of the sentence as a whole (also, I probably >>don’t know).
>I was wondering if the consensus of freenet is the same as the consensus of >gnunet. Freenet is proof of trust. I do not know for gnunet. It would be a bit clearer if you replace ‘the consensus’ by ‘the consensus algorithm’, assuming that’s what you mean. I don’t know what Freenet uses consensus for, so I can’t really tell for sure. On https://freenet.org/news/summary-delta-sync/ I see a bit about consensus methods used to determine what to consider as current state in case concurrent updates. But it doesn’t mention trust anywhere. Proof of trust is mentioned on https://freenet.org/news/799-proof-of-trust-a-wealth-unbiased-consensus-mechanism-for-distributed-systems/, and while that blog post claims it is a consensus mechanism, nowhere does it mention how it goes from ‘trust’ to ‘consensus’. Looking a bit further (on https://github.com/freenet/freenet-core/discussions/443), it the ‘proof of trust’ seems to be a _component_ of the consensus algorithm(s) rather than the consensus algorithm itself, as a method to prevent Sybil attacks against the consensus algorithm. There are a few things in GNUnet that have some kind of consensus algorithm (multi-peer set reconcillation and network size estimation come to mind, though I don’t think the latter really counts since AFAIK it’s not a problem if different peers have a different estimate, it just needs to be a rough estimate). But, the algorithm used seems rather subject-specific, and some things simply don’t have and have no use for a consensus algorithm. For example, while I’m not too familiar with set reconcillation, I got the impression that Sybil attacks are non-applicable to them. So, “what is the consensus algorithm” doesn’t really have an answer. The first blog post mentions ‘key -> value’ associations. The closest things to thatin GNUnet, seem to be GNS and DHT. In the former, the truth is simply ‘whatever has a correct signature’ so there is no need to approximate truth by consensus, you could simply verify the signature instead. In the latter, for most things ‘key’ is a function of ‘value’ and peers can verify locally, without extra information, whether this mapping is correct (since it involves hashing or signatures). In some cases multiple values are correct, in which case they might be combined (I’m not sure whether it’s always a commutative monoid, but when they are, that is kind of like described in the blog post except that the algorithm is stored & run on the peer(*) instead of running the wasm thing) (*) As it should – then you can update and optimise the relevant algorithms, and you can take into account information that does _not_ lie within ‘key->value’ mappings (^). Also software freedom reasons. Putting software on the network (also known as “smart contracts”) does create its own form of rigidity, even if the intention is to add flexibility! (When GNUnet DHT encounters key->value1, key->value2 mappings with multiple values, and it does not recognise the type so doesn’t know how to combine them, it just leaves the key as-is, so it can still propagate – not all peers need to understand every type, and applications can define their own types if they wish to.) (^) I have a use case for this. Another thing is that GNUnet peers aren’t interest in knowing the whole DHT (it is, after all, a _distributed_ hash table), unlike the eventual-consistency situation described on the blog (though I imagine Freenet probably has its own DHT as well). In FS, there is also some kind of algorithm for determining whether peers are leeching or contributing (with potential delays in-between, so an occasional burst of lots of asking for resources can be fine), but IIRC it doesn’t take the form of a consensus algorithm – the peer needs to guess whether other peers are being reasonable (and communicate such information to other peers), but that doesn’t sound like it requires consensus or eventual consistency etc.. >At last but not least, I would love to know how you deployed gnunet on your >own please? I can not connect my own 2 peers together from the doc at >https://docs.gnunet.org/latest/developers/tutorial.html#starting-peers-using-the-testbed-service > . there might lack of doc. For non-testing setup: I just used a single peer, not two peers. For the test suite of the software I was writing: I just used a single peer, set ‘UNIXPATH’, didn’t use any transports yet, and (IIRC) directly started the relevant services instead of using gnunet-arm. I didn’t yet need to connect multiple peers to each other, IIRC all testing so far could be done with less than a single peer (e.g. do things like ‘only start the DHT service if all you are testing is communication with the DHT service’). Best regards, Maxime Devos.
