Couldn't add @phritz and @mkg20001 as reviewers, not sure why

We should make sure that rendezvous doesn't allow registering arbitrary peers under a namespace. Basically, the peer id in the register request should match the peer id of the peer initiating the request, otherwise this is a potential DDoS vector. I know we're communicating the peer id in our register requests, so this might be already covered, but its worth pointing out.

Great point, care to suggest wording in the spec to clarify this?

Also discussed in Glasgow -- the registration function, apart from PoW, should return the actual TTL of the registration so that a background process can re-register when appropriate.

For the PoW function, would we apply that to every registration? So if an app wanted to register to multiple namespaces they would require a PoW for each and each subsequent re-registration on TTL expiration?

Would it be valuable to add some concept of limited multi registration in combination with the PoW function to balance this out?

Except from @dirkmc comment regarding the cookie keyword, the current state of the spec looks good to me.

Moreover, totally agree with the addition of the PoW function. And subscribe @jacobheun questions about finding a balance to this function.

Hey guys,

This looks like a great feature to have as there is no 'standard' mechanism for discovery when building a P2P networking using libp2p. Does anyone know when this will be merged ?

Where can we find impl status?

With regards to the proof-of-work function, there are questions above about whether to make the difficulty configurable and what the default proof-of-work required for registration should be.

You might consider the "hashcash auction" technique to allow the clients to determine the difficulty of the proof-of-work amongst themselves in a bottom-up, decentralized way:

https://chr15m.github.io/hashcash-auctions-for-decentralized-resource-allocation.html

You don't need to read the post to understand the basic idea which is as follows:

• Each rendezvous server would set an upper limit on the amount of messages & connections per unit time it can process (i.e. R registrations per hour). This can be estimated based on CPU, memory, bandwidth resources available or set at some sensible easily serviceable limit.
• When a client wants to connect and register it must perform a proof-of-work.
• A registration slot will be granted based on the amount of proof-of-work the client supplies. This is done by sorting all registrations by the hash power each achieved and slicing the array of registrations so that only the top (R) are granted the ability to register.
• The server publishes the current highest, lowest, and median hash power achieved for each registration by other clients that it currently holds active so that clients can try to make it into (R).

There are three beneficial outcomes from this scheme:

• As with traditional Hashcash there is basic spam prevention as DoS attacks now incur a literal CPU (and therefore energy) cost. The energy cost is proportional to the size of the DoS effort so it is somewhat self defeating - the harder they DoS the more expensive they make it.
• Legitimate users now have a mechanism to out perform a DoS attack and continue to use the service rather than the normal failure mode where everybody is locked out.
• Because a client will know of multiple registration servers and their relative proof-of-work requirements (which will be proportional to their load) clients will naturally head for registration servers with lower proof-of-work and therefore lower load. This creates a bottom-up load balancing mechanism without requiring any centralized coordination between registration servers.

There are two things to keep in mind when considering proof of work:

1. When it comes to clients, hardware matters. An PoW that's expensive on one device can be virtually free on a another. This can be a serious problem for mobile users.
2. When it comes to servers, we're basically asking people to run these servers as a public service. Given that we have to be careful about not disincentivizing participation by making the service costly to run (in terms of power).

Really, I'm more worried about the first issue. The second issue will always come down to the fact that honest nodes will need to spend enough to overcome malicious nodes.

@chr15m my worry with your proposal is 1. It would be pretty easy to completely lock-out mobile users by driving the PoW cost up.

@Stebalien yes those are important concerns.

Under the scheme I outlined the server does not perform any proof-of-work. It is specifically design to protect the people you are worried about: those running servers as a public service. The idea is to allow such resource volunteers certainty that their offering can't be abused by anonymous clients. The clients are the ones who must perform proof-of-work.

With regards to 1, @vyzo mentioned Equihash which is memory-hard rather than CPU-hard and possibly therefore friendlier to mobile phones. Scrypt is another alternative with good pure-JS presence in browsers.

For this particular use-case where most registration servers will have spare capacity it should not be a big issue since the PoW will be negligible for all clients anyway. Only in the situation of massive DoS of multiple registration servers will mobile clients find a harder time registering than higher powered CPU machines and that situation would hopefully be extraordinary in any case.

I'm not really a fan of memory hard problems (at least for use cases like this):

1. It's easier to share CPU time than it is to share memory. That is, if I frequently need a large chunk of memory but don't always need it, it still needs to be available most of the time. Basically, if we use a memory hard problem, the libp2p instance will need to hoard the memory it needs.
2. I'm not convinced of the overall security of multiple memory hard problems that can be computed in parallel. The hard part about memory is usually latency not throughput. However, when you just need to compute a bunch of memory hard problems in parallel and care more about how many problems you finish, not how long it takes to finish each one, it's throughput that matters.

@Stebalien yes good points. Of course, using plain PoW under a fixed/configurable difficulty setting also suffers from the issues you have mentioned.

Of course the real question is whether using PoW provides better protection and features than no PoW at all, and further, whether using the "hashcash auction" scheme outlined provides better protection and features than plain fixed difficulty PoW.

Changes:

• addressed @dryajov's request for explicit wording prohibiting arbitrary peer registration
• added E_UNAVAILABLE error for temporary availability errors
• added the actual ttl in the registration response
• added section (TBD) for proof of work