Thanks!

1/ Unfortunately a lot of the existing p2p terminology for centralized components (signaling server, rendezvous server, tracker, etc…) are overloaded with multiple definitions. We chose “Introducer” because unlike other constructions, it’s sole role is to facilitate the WebRTC handshake. Peer discovery will probably also be provided, but the Mesh node will be implemented such that it could use a whole host of other peer discovery mechanisms (e.g., DHTs, bootstrap lists/nodes, etc…) and will not be limited to using a centralized entity to do so. It will be centralized for the MVP release but we plan to decentralize this part of the network before the 1.0 release. We are considering a construction where peers could be introduced on any arbitrary introducer server that happens to be online and available. One could imagine peers adding their peer ids to a DHT, along with the URL of the signaling server they have associated themselves with. A peer wishing to connect would connect to the specified signaling server and request an introduction to that peer. This is not very different from the current construction, but in order to make sure a signaling server is available and has high uptime, we intend to implement and run the first one as well as hard-code it’s use into every 0x Mesh node.

2/ There is no concept of gas in the 0x Mesh network. Can you elaborate on what you mean by this?

3/ Unfortunately the on-disk storage used for operating the 0x Mesh node will be opinionated. The current iteration is using LevelDB which is a low-level key/value store. We do not intend for relayers to query this data-store directly. Rather, a WS endpoint will be provided that will deliver a stream of discovered orders, as well as order state updates for stored orders (filled, cancelled, expired, etc…). Our intention is for an operator/relayer to ingest this stream and store/update the orders in a database of their choice. This operator-chosen database will power a relayer’s API & frontend, and it can be optimized for such use-cases.

4/ The reserves required by a spammer are much higher then those required by an honest user. A users reserve gets divided by the number of orders they send into the network. As such, a spammer with a balance of 10 ETH and 10,000 orders in the network can have it’s order displaced by any user with 0.0011 ETH and a single order (displacements only happens once nodes hit full capacity). Remember that orders take up very little space and therefore the total capacity per node in the network is quite high. Because of this, we expect the ETH requirements to start out at slightly above zero (ask me about this if you are curious why not 0). As the network becomes more popular and grows, the ETH requirement will raise slightly, but when nodes are at capacity, it’ll still be very easy for genuine users to replace the orders of spammers. Since ETH has a real world value, and one must have control over the private key in order to use them as “reserves”, it’ll be hard for spammers to borrow ETH to conduct an attack. They will need to own the ETH, and cannot use it for other purposes while maintaining the attack.

5/ Haha, noted. That will make order spreading much more efficient. We just need to do it properly so that we maintain a desirable network topology.

Feel free to ask any follow-up questions.