Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add rendezvous recommendations #302

Merged
merged 3 commits into from
Apr 30, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 37 additions & 8 deletions rendezvous/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,19 @@ and spec status.

[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

## Table of Contents

- [Overview](#overview)
- [Use Cases](#use-cases)
- [Replacing ws-star-rendezvous](#replacing-ws-star-rendezvous)
- [Rendezvous and pubsub](#rendezvous-and-pubsub)
- [The Protocol](#the-protocol)
- [Registration Lifetime](#registration-lifetime)
- [Interaction](#interaction)
- [Proof of Work](#proof-of-work)
- [Protobuf](#protobuf)
- [Recommendations for Rendezvous Points configurations](#recommendations-for-rendezvous-points-configurations)

## Overview

The protocol described in this specification is intended to provide a
Expand Down Expand Up @@ -94,6 +107,8 @@ greatly simplifies real time discovery. It also allows for pagination
of query responses, so that large numbers of peer registrations can be
managed.

The rendezvous protocol runs over libp2p streams using `/rendezvous/1.0.0`.
vasco-santos marked this conversation as resolved.
Show resolved Hide resolved

### Registration Lifetime

Registration lifetime is controlled by an optional TTL parameter in
Expand Down Expand Up @@ -186,14 +201,14 @@ message Message {
}

enum ResponseStatus {
OK = 0;
E_INVALID_NAMESPACE = 100;
E_INVALID_PEER_INFO = 101;
E_INVALID_TTL = 102;
E_INVALID_COOKIE = 103;
E_NOT_AUTHORIZED = 200;
E_INTERNAL_ERROR = 300;
E_UNAVAILABLE = 400;
OK = 0;
E_INVALID_NAMESPACE = 100;
E_INVALID_SIGNED_PEER_RECORD = 101;
E_INVALID_TTL = 102;
E_INVALID_COOKIE = 103;
E_NOT_AUTHORIZED = 200;
E_INTERNAL_ERROR = 300;
E_UNAVAILABLE = 400;
}

message Register {
Expand Down Expand Up @@ -234,3 +249,17 @@ message Message {
optional DiscoverResponse discoverResponse = 6;
}
```

## Recommendations for Rendezvous Points configurations

Rendezvous points should have well defined configurations to enable libp2p nodes running the rendezvous protocol to have friendly defaults, as well as to guarantee the security and efficiency of a Rendezvous point. This will be particularly important in a federation, where rendezvous points should share the same expectations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit pick: The rest of the specification is wrapped at 80 characters. Can you do the same here for consistency?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed


Regarding the validation of registrations, rendezvous points should have:
- a minimum acceptable **ttl** of `2H`
- a maximum acceptable **ttl** of `72H`
- a maximum **namespace** length of `255`

Rendezvous points are also recommend to allow:
- a maximum of `1000` registration for each peer
- defend against trivial DoS attacks
- a maximum of `1000` peers should be returned per namespace query