idea: federation

[Cyrix126]

Hello,

From what I understand, anyone could create a Haveno network. It is good for decentralization but it brings the issue of fragmentation. Specially for an order book, the more offers there are, the more it is useful. The solution for this could be adding federation support.

[shortwavesurfer2009]

I see 2 potentials for this.

Federation:
Pros: client makes one connection to a tor node so less data needs to cross the wire
cons: easier to DDOS even with the PoW tor defenses. (take monero.town for example as people have tried to knock it offline and succeeded for about a half hour at a time.

gossip (similar to nostr)
pros: less possible to be taken down via a DDOS since you aren't only connected to a single point of failure.
cons: you have to connect to however many networks exist one by one and ask for their order books to get a complete picture. while this may not take a long time it means more data must flow over the wire and tor is not exactly known for its "get up and go" speeds.

what both of these approaches would do is combine the order books from multiple networks together into a single order book view given to the end user. when a listing was selected the user needs to know which network it came from and who the arbitrators of that particular trade would be. they may also want the ability to block listings from one or more networks on their local client.

Personally I like the gossip idea better but both have their merits. Either way a combined order book will be needed. I figure onc a few networks are established that the base software (this one) can just add all the big networks directly into the source code so that users don't need to download a different executable for each network. that is a total non-starter.

[Cyrix126]

I figure onc a few networks are established that the base software (this one) can just add all the big networks directly into the source code

Maybe instead of having a need to list every instances, only a few addresses could be given. Then it would work like the DHT network where you only need to know one existing address in the network that will tell you of other addresses that will tell you of other addresses etc...

[mister-monster]

This is a peer to peer application. Adding central points of control is terrible. Federation in general has been a failure, it is not censorship resistant and leads to network fragmentation.

[Cyrix126]

Federation in general has been a failure

what's your reason for saying this ? what do you measure as failure ?

it is not censorship resistant

Nobody can censor what you expose on your own instance. And if you use tor (as Haveno is doing), you cannot be threaten if your stay anon.

leads to network fragmentation.

That's exactly what's federation fix by letting every instance talk to each other.

[Cyrix126]

Just a precision: a list of address to introduce the client to the network like DHT is working is not something centralized. You could always get an address from someone in a chat or a friend that is already connected to the network.

It's just that you need one, and including it in the client is more user friendly that telling them: "find someone who is already in the network to ask him to give you address."

[HardenedSteel]

PSA I stalled working on it after reactions I got from Matrix room.

[phytohydra]

Before adding federation, it would be nice to migrate all of the per-instance parameters into a configuration file, so people could install one binary, built from the haveno-dex repository, and then switch between e.g. Reto, HardenedSteel (yes, I know it's discontinued) and haveno-dex testing by using a different config file. Users shouldn't have to trust binaries from brand new sources when they can instead use a short and readable config file.

Likewise, there should be subdirectories in the app directory for each config, so we don't need instructions like this:

If you previously installed Haveno, first clear your Haveno app directory to reset things, located at:
-Linux: ~/.local/share/Haveno/
-macOS: ~/Library/Application Support/Haveno/
-Windows: ~\AppData\Roaming\Haveno\

First complete support for multiple instances, then work on federating them.

[preland]

I won’t be personally interested in looking into federation until we have completely ruled out moving to a 2:2 system.

Federation is the best solution with Haveno’s current state, but Haveno was never meant to run in its current state. Moreover, I fear that having centralized groups controlling it, especially DNMs (this was commonly mentioned in the haveno matrix channel, as DNMs would technically be the best candidates to run networks) would cause #897 to become a much greater concern, not to mention the ethical concerns that this brings up.

There is no mitigation of this risk, as banning a DNM from participating wouldn’t work (lack of centralized control, botting/social attacks, sockpuppeting, etc.) Also keep in mind that Haveno from the beginning was supposed to help Monero, not harm it.

At least, that’s the way I currently see it. As for the people currently running networks, go for it. You guys will be the actual beta test that Haveno never really got to have 👍

[HardenedSteel]

I noticed Haveno already supports federation unintentionally. For an example if you fork and hardcode your own arbitrators then you can still see the offers from other networks however you can't take and publish new offers.

I believe this can be easily fixed by recognizing other pub keys and displaying in the GUI.

[preland]

That’s interesting to hear. I wonder if that could also allow for incorrect data to be seen.

[nihilist001]

i second the gossip approach that shortwave suggested:

have the official haveno client (which is supposed to remain unaffiliated with any haveno network) with the possibility for the user to just mention which haveno network it wants to connect to.

example:

bob the noob goes on haveno-dex/haveno git repo, downloads the binary for haveno 1.0.7 for linux; and by default it does not have any seednodes hardcoded (unlike how it would be on haveno-reto for example)

so haveno prompts bob to just mention the seednodes he want to connect to.

lucky for bob, haveno reto has their list of seed nodes made public (basically a list of .onion urls) so bob copies it, into his haveno client, and now he can connect just fine without having to download haveno-reto.

Now all the reto trade offers appear, and he can take them. (arbitrated via haveno reto's arbitrators)

Bob could also put the seed nodes of another haveno network, along the seed nodes he already entered from reto, and he would also see their trade offers; arbitrated by their arbitrators.

this would avoid having to install haveno-reto, haveno-whatever packages to see the trades of each, in a different haveno client each time.
This would ALSO stay true to the principle that the official haveno client does NOT have an official haveno network, the user would have to look for one, and manually use their seed nodes

[nihilist001]

gossip approach graph to represent the idea:

[Cyrix126]

Having to search for every network seeds to have the complete order book would be very cumbersome. What will happen is some people will make a centralized "list" of networks to add, and it will be a painful process to make this list not outdated when new networks come on a small non english speaker forum for example.

Why not do like DHT. You only need one seed (any seed) to find all the others since you would ask recursively the seed node if it knows any other one.
The user would have to add only one seed node to also get all the others.

Any fork of Haveno using this feature would make it also easier for the user that would not even need to add a network manually. Their seed could be the first to introduce the others, exactly like what torrent clients do to connect to the dht network.

It would not prevent user to "hide" networks they don't want. The protocol could even include the rules of the different seed nodes (ex fees) so a user can make his own filters.