Conversation
🚀 Build Preview on IPFS ready
|
| ## Extension To Delegated Routing | ||
|
|
||
| Making content discoverable can be achieved by offering a delegated routing endpoint | ||
| ([[http-routing-v1]]). An Edge IPFS server responds to routing requests for CIDs |
There was a problem hiding this comment.
I would be more specific here about the endpoint only implementing section 4 of the spec, i.e., the Content Routing API.
| that it knows about with a peer routing response the `Protocols` array of which | ||
| must have a `rasl` entry. | ||
|
|
||
| Correspondingly, there must then be a `rasl` field in the peer response object, |
There was a problem hiding this comment.
| Correspondingly, there must then be a `rasl` field in the peer response object, | |
| Correspondingly, there must then be a `rasl` field in the Peer Schema object, |
One thing that's slightly awkward is that the peer-schema requires an ID:
ID: the Peer ID as Multihash in Base58btc or CIDv1 with libp2p-key codec.
So the question is whether we want to require every RASL server to also have a key, or to work on adjusting the spec. I'm sure the latter will get push back, given that this assumption is baked in to a bunch of implementations — but still worth having the discussion, given that with HTTP, you are most likely relying on TLS and certificate authorities for transport encryption, rather than key based authentication, transport encryption.
2 participants
Just playing around with this idea.