Reframe peer records #279

aschmahmann · 2022-04-21T23:31:14Z

WIP but wanted to put out an initial draft for some thoughts and discussion.

Background

The Reframe protocol gives us a way to build request-response protocols across multiple transports in a data format agnostic way. The first target use case of this protocol was to be able to handle delegated operation of the various types of requests that the IPFS Public DHT handles. At the moment getting provider records as well as putting and getting IPNS records are supported. The remaining function that can be fully delegated to a third party DHT client is getting peer records (putting provider records and peer records into the DHT are not performable in a delegated way due to protocol limitations described in libp2p/go-libp2p-kad-dht#584).

Motivation

Enabling Reframe to support getting peer records will allow us to start building tooling like a standalone delegated routing server that allows consumers of content to delegate their requests to the server which in turn can query the IPFS Public DHT, Indexers, or any other routing system. More functions will still need to be added going forward to support users who want to make themselves or their content available using this protocol, but those can come later.

Proposal

The simplest proposal here would be to just have a method that requests the multiaddresses for a given PeerID. However, given that libp2p signed peer records are prevalent in the network it should be possible for peers to get those as well and choose to prioritize them if available.

Unfortunately, the libp2p signed peer records are signed protobufs which means: 1) they're not particularly Reframe "friendly" even though we could just send them as bytes 2) we can't reformat the data in a Reframe friendly way because the encoded protobuf is signed and the way in which the data is encoded into the protobuf is non-canonical.

The initial proposal allows the responder send back both unsigned lists of multiaddresses and opaque signed peer records

aschmahmann · 2022-04-21T23:34:53Z

REFRAME.md

+    type GetPeerAddressesRequest struct {
+        ID Bytes # libp2p PeerID
+        RecordTypes [String]
+    }


Having RecordTypes doesn't seem necessary as the responder could just send back all record types it knows about. Is there value in being able to ask to send back less data here? The same could be argued in other places (e.g. not sending back TransferProtocols we don't support anyway).

I'm planning to remove this, but wanted to leave this as a place for comment if there was demand for it to stay

if we do have it, we should have some recommendation of how we identify types - what are these strings supposed to be?

It doesn't seem overly harmful to have, but it does add another point of complexity in implementation.

+1: if we are to have it, it should be a union of sorts that becomes the formal spec of known record types.

if we are to have it, there must also be a case for "return all types", otherwise we preclude a dumb middlebox from pre-fetching data.

on the whole, this does seem as an unnecessary micro-optimization (at complexity cost), because the number of records a peer can ever have is limited by the number of types that exist, which is a small number. this is not something that can grow arbitrarily, so ... i would vote no here. the rule of thumb being: can the number of returned results grow in a runtime-dependent manner (e.g. # of providers for a cid depends on runtime conditions, vs number of address records is always capped by the number of types of records which is a compile-time constant)

aschmahmann · 2022-04-21T23:38:03Z

REFRAME.md

+     | Multiaddresses "multiaddrs"
+     | Libp2pSignedPeerRecord "769" // the libp2p signed peer record entry interpreted as decimal https://github.com/multiformats/multicodec/blob/f5dd49f35b26b447aa380e9a491f195fd49d912c/table.csv#L129


Wasn't sure which identifiers to use here. In particular it feels weird to be mixing text and codes like this without any sort of standard for how we do this.

@Stebalien has occasionally proposed utilizing / (since it's the 0x90 codec) as a way to bridge text + codes although I'm not sure if that applies here.

if we have codes for some of them already, can we make a code for the reframe-multiaddrs alternative to libp2p signed peer records and standardize on codes?

aschmahmann · 2022-04-21T23:48:32Z

REFRAME.md

+    }
+
+    type Multiaddresses [Bytes] # Each element in the list is the binary representation of a complete multiaddr without a peerID suffix
+    type Libp2pSignedPeerRecord Bytes # https://github.com/libp2p/specs/blob/8c967a22bfbaff1ae41072b358fdba7c5883b6a4/RFC/0003-routing-records.md


Including raw bytes like this doesn't feel great, although in order to use this peers will likely need to understand this format to send addresses in Identify anyhow so not so bad.

Are there better ideas here given that we can't just do something like the below due to the use of (non-canonically encoded) protobufs in signed peer records?

type PeerRecord struct { Multiaddresses [Bytes] SeqNo optional Int Signature optional Bytes }

I think this is fine. One variation, purely for convenience, would be:

type Libp2pSignedPeerRecord struct { Multiaddresses [Bytes] # copy of the multiaddresses from the record, for the benefit of systems that don't know/want to check signatures Libp2pSignedRecord Bytes }

willscott · 2022-04-22T06:09:40Z

REFRAME.md

+    type GetPeerAddressesRequest struct {
+        ID Bytes # libp2p PeerID
+        RecordTypes [String]
+    }


if we do have it, we should have some recommendation of how we identify types - what are these strings supposed to be?

It doesn't seem overly harmful to have, but it does add another point of complexity in implementation.

willscott · 2022-04-22T06:11:21Z

REFRAME.md

+     | Multiaddresses "multiaddrs"
+     | Libp2pSignedPeerRecord "769" // the libp2p signed peer record entry interpreted as decimal https://github.com/multiformats/multicodec/blob/f5dd49f35b26b447aa380e9a491f195fd49d912c/table.csv#L129


if we have codes for some of them already, can we make a code for the reframe-multiaddrs alternative to libp2p signed peer records and standardize on codes?

willscott · 2022-04-22T06:11:58Z

REFRAME.md

+```
+{"GetPeerAddressesRequest" : {
+    "ID" : {"/":{"bytes":"AXIUBPnagss"}},
+    "Record" : {"/":{"bytes":"AXIUBPnagss"}}


nit: there presumably isn't a record in the request, this would be in the response

Yep, I didn't update any of the JSON examples yet (marked with TODO)

aschmahmann · 2022-04-24T01:22:58Z

REFRAME.md

+    } representation keyed
+
+    type GetPeerAddressesResponse struct {
+        Records [PeerRecordType]


Does it make sense to return [PeerRecordType] here rather than just a single PeerRecordType since we're allowed to send back a stream of GetPeerAddressesResponse? Probably doesn't hurt, but we might want to build some conventions here.

I'd keep the array. A receiver might want to forward/use results as soon as the first one arrives. They have no good way of knowing that more are coming back to back.

BigLep · 2022-04-25T15:25:49Z

@petar : can you take a look at this as well?

BigLep · 2022-10-04T16:15:51Z

@aschmahmann @willscott @guseggert : from a planning perspective, are any key immediate usecases blocked on this?

willscott · 2022-10-04T16:19:22Z

I think we can mark this as deprecated - we added something pretty similar in the publish code paths for delegated routing

aschmahmann · 2022-10-12T00:33:07Z

I think we can mark this as deprecated - we added something pretty similar in the publish code paths for delegated routing

The special code in the publishing path doesn't help here. For example, the DHT doesn't always return addresses for who has the content, just their peerID, and you might need to do another lookup for the peer's addresses.

from a planning perspective, are any key immediate usecases blocked on this?

If you want to allow any system that currently uses the IPFS Public DHT to allow delegating out FindProviders queries to something like https://github.com/ipfs-shipyard/someguy you need someguy to do a FindPeer lookups in the background for peer addresses if they're missing.
Users of the DHT that want to delegate out lookups (e.g. if they wanted to use the DHT as a distributed version of dynamic DNS so they can connect to their machine no matter where it is) will be unable to do so.

How key and immediate these are you likely have better perspective on. If this isn't going to happen in the short term though then I'd recommend making the changes to someguy that are needed in the meanwhile.

willscott · 2022-10-12T00:51:00Z

maybe the other consideration is to expect an updated format around this with double hashing, which is proposing a variant on authenticated records

lidel · 2022-10-20T19:55:59Z

I am late to this PR, but I agree with @aschmahmann this is a gap that should be closed.

We have two basic concepts in routing:

ipfs routing findprovs does content routing (tell me whi peerids have this cid)
ipfs routing findpeer does peer routing (tell me multiaddrs this peerid has currently)

Currently we have "content+peer routing" in form of FindProviders method, but there is no way to use Reframe for delegated peer routing alone.

This means:

IPFS node is unable to shut down local DHT client completely, as connecting via /p2p/peerid would no longer work.
This also means we are unable to use Reframe as replacement for Kubo RPC /api/v0/dht/findpeer used in https://github.com/libp2p/js-libp2p-delegated-peer-routing – which will be a problem when we have browser nodes trying to do things like bootstrap using only peerid, or find a new Multiaddr for a peer that moved between networks (and values from cached FindProviders response no longer work)

Adding this will be necessary if we want to base delegated routing in Reframe.

willscott · 2022-10-20T20:37:12Z

I think this shouldn't be hard for indexers to support if needed

willscott · 2022-10-20T20:37:41Z

I do wonder if we want it just for hash-derived peer records, versus for direct peer records

hacdias · 2023-10-03T12:32:21Z

R.I.P. Reframe.

Partially superseded by #417 which adds peer schema to /routing/v1 API and defines a convention that could be used for returning signed libp2p records in the future.

aschmahmann added 2 commits April 21, 2022 19:07

spec(reframe): draft for getting peer records

647c842

spec(reframe): fix typos

fac8b2d

aschmahmann commented Apr 21, 2022

View reviewed changes

willscott reviewed Apr 22, 2022

View reviewed changes

aschmahmann commented Apr 24, 2022

View reviewed changes

BigLep requested a review from petar April 25, 2022 15:25

BigLep added this to the go-ipfs 0.14 milestone Apr 25, 2022

BigLep assigned aschmahmann May 17, 2022

aschmahmann mentioned this pull request May 30, 2022

feat(routing): Delegated Routing ipfs/kubo#8997

Merged

BigLep removed this from the go-ipfs 0.14 milestone Oct 4, 2022

hacdias closed this Oct 3, 2023

hacdias deleted the feat/reframe-peer-records branch October 3, 2023 12:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reframe peer records #279

Reframe peer records #279

aschmahmann commented Apr 21, 2022

aschmahmann Apr 21, 2022

willscott Apr 22, 2022

petar Apr 25, 2022 •

edited

Loading

petar Apr 25, 2022

aschmahmann Apr 21, 2022

willscott Apr 22, 2022

aschmahmann Apr 21, 2022

petar Apr 25, 2022 •

edited

Loading

willscott Apr 22, 2022

willscott Apr 22, 2022

willscott Apr 22, 2022

aschmahmann Apr 24, 2022

aschmahmann Apr 24, 2022

petar Apr 25, 2022

BigLep commented Apr 25, 2022

BigLep commented Oct 4, 2022

willscott commented Oct 4, 2022

aschmahmann commented Oct 12, 2022 •

edited

Loading

willscott commented Oct 12, 2022

lidel commented Oct 20, 2022 •

edited

Loading

willscott commented Oct 20, 2022

willscott commented Oct 20, 2022

hacdias commented Oct 3, 2023 •

edited by lidel

Loading

		\| Multiaddresses "multiaddrs"
		\| Libp2pSignedPeerRecord "769" // the libp2p signed peer record entry interpreted as decimal https://github.com/multiformats/multicodec/blob/f5dd49f35b26b447aa380e9a491f195fd49d912c/table.csv#L129

Reframe peer records #279

Reframe peer records #279

Conversation

aschmahmann commented Apr 21, 2022

Background

Motivation

Proposal

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petar Apr 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petar Apr 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BigLep commented Apr 25, 2022

BigLep commented Oct 4, 2022

willscott commented Oct 4, 2022

aschmahmann commented Oct 12, 2022 • edited Loading

willscott commented Oct 12, 2022

lidel commented Oct 20, 2022 • edited Loading

willscott commented Oct 20, 2022

willscott commented Oct 20, 2022

hacdias commented Oct 3, 2023 • edited by lidel Loading

petar Apr 25, 2022 •

edited

Loading

petar Apr 25, 2022 •

edited

Loading

aschmahmann commented Oct 12, 2022 •

edited

Loading

lidel commented Oct 20, 2022 •

edited

Loading

hacdias commented Oct 3, 2023 •

edited by lidel

Loading