What

We could unlock a number of capabilities for Graphsync and the whole transfer stack if we used UUIDs for identifiers.

Right now, we generate a ton of complexity in the data transfer stack simply tracking IDs between layers.

Going forward, we'd like graphsync to simply share an id with higher levels of the stack. Data Transfer and/or Retrieval should be able to pass an id that graphsync uses. Moreover, graphsync itself should be able to match up an incoming request with pre-existing data for higher levels of the stack (see push transfers).

RFC 4122 UUIDs have some interesting properties. They are unique not just on one system, but unique to all systems (with a non-zero but negligible chance of collision). If we used UUIDs, we could share an identifier between all layers of the transfer stack (all the way up to retrieval), and pass those around on the network.

Moreover, if an incoming Graphsync request has a UUID that matches say a previous data transfer push request, we can immediately match these two up and have them share state.

It would also unlock actually making a push mode in graphsync itself, since the id sent from another machine could be used. (this could remove the need for the data transfer libp2p protocol)

How

• Define a new graphsync protocol version (let's use 1.1.0 for now) with new message format #279
• Define serialization/deserialization functions for messages in the message layer #280
• Change the RequestID type in go-graphsync #281
• Support multiple libp2p transports in the network layer #282

Potential Downsides

The wire format described will cost approximately 17 bytes on the wire (1 varint length + 16 bytes encoding).

Moreover, protobuf doesn't define a clear UUID encoding (protocolbuffers/protobuf#2224), so this requires the application developer for graphsync to know how to encode the UUID in the same manner we are.

There's a high likelyhood if we need to operate with backward compatibility for some time, there could be an interim phase of increased complexity.

Alternatives

We could put the UUIDs in an extension (no protocol change)

We could simply expand the size of request id to int64 (would at least allow us to accept data transfer channel numbers)