At least 2 separate Haveno networks have launched as of today. One is called Reto and the other is called HardenedSteel. Those are the only ones I’m aware of right now, and things are happening pretty fast.
The haveno software was designed with the assumption that only a single network would be operated. People could fork it and run their own networks, but they wouldn’t interact directly at all. But it looks to me as of this moment this is not how it is going to play out.
The client has the network info hard coded. So to use more than one, you need two copies of the client. This means that for most people they have to pick one. And, users might not understand this, just google “haveno” and pull the first git repo they see. This has significant, fast moving and quickly ossifying network effects with big repercussions.
We need to be very vigilant right now, as we are about to witness the very swift rise of a major power broker in our community. We don’t want to start using a Haveno network run by scammers or authoritarians. Each network is it’s arbitrators, and soon, the merchants on each one.
I think it’s probably a good idea to figure out a way to connect to multiple networks, and to show listings with details about which network/arbitrator set a user is trusting when taking up a listing.
I’m cautiously optimistic, Monero has gotten rid of powerful people without a hitch before. But it is a bigger community now and that will be much harder to do. If we are vigilant during this time and we get through this successfully I think we become unbeatable, but the road directly ahead of us is treacherous, the next few days are going to move very fast.
You must log in or register to comment.
Only thing that really needs to be done would be to put some sort of patch into the client that automatically brings up a dialogue box when the client starts up asking to which network you want to connect or please input an onion seed address.
Edit: That way one executable can cover all networks without having to install multiple instances of the application.
I’m currently working on a pull request that reads the public keys from a file instead of being hard coded. Distributing those files with a custom haveno.properties file could allow people to join separate networks using the same codebase unless there is some functional difference
Everybody reading this message should also read this, since it gives the details: https://github.com/haveno-dex/haveno/blob/master/docs/deployment-guide.md#register-keypairs-with-privileges
There are no servers in Haveno. Instead, there is a “developer (public) key” hardwired into the client. Instead of the owner of the localmonero.co domain (and TLS certificate, and onion url key), there is the “developer public key”. The developer public key you have in your client basically decides “whose Haveno” you want to use. This is a good thing! I always worried about the localmonero.co domain being seized by a simple letter being sent to their registrar. With the developer key system this can’t happen. The thugs have to actually go hunt down whoever has this key. The key isn’t even kept online (like a TLS key or an onion key).
Whoever has the developer key decides who the arbitrators are. Just like localmonero – whoever owned the domain name got to decide who the arbitrators were.
I think OP’s posting is kind of an unnecessarily-scary way of saying that the client ought to ask the user to type in this key (or several of them!) at installation time, instead of being compiled in. That is a great idea.
I wouldn’t say it’s unnecessarily scary. I’m just concerned that the first, biggest haveno net winds up bring run by people motivated by nefarious reasons. Trying to track people, or colluding with makers to scam users or something like that. I don’t think that the reto guys are doing this, for the record. I just think it’s important for us to understand how much trust we place in a group when we choose their network in our haveno software, and how quickly we can wind up in a situation where we are stuck with someone we don’t particularly like controlling the primary fiat to XMR route.
It’s unclear how the arbitrators are picked
The people who spin up their network pick the arbitrators. Which means which network you’re using comes down to who the arbitrators are. Eventually as these networks are running you’ll also consider liquidity and peers.
something like mastodons page at launch would fix this issue yes? like forces you to pick an instance?
What is this and why do I need it?
Because LocalMonero is no more
Sure but what does this do?
Exchange fiat for XMR?
I didn’t read the docs yet but what do the “haveno networks” do, wouldn’t it be beneficial to have a federated design? I.e. even if they don’t interact directly, I as a user of both can list their orders, make trades on each on the same UI?
It’s peer to peer, no servers, so federation isn’t an option, nor is it something you need here.
Federation in general is a bad idea. It is prone to network fragmentation and is not censorship resistant.
What you’re looking for is simply the ability to communicate on multiple configured networks. They’re still peer to peer, but each has their own listings and arbitrator set. That’s something I think is a good idea, although I’d defer to Haveno developers if that’s a good idea because I’m not all that familiar with the network architecture.
ok no servers make sense, but choosing arbitrators is like choosing a server equivalent to a multisig wallet, there is “someone’s computer” that will have the third key to resolve arbitration issues, and also can it read chat messages? if so networks should be picked with care, but of course trades can complete without it, but I was confused and called it “federation” for the fact they should be merged in the UI
