Document delegated routing concept

[BigLep]

In light of https://github.com/protocol/bifrost-community/issues/1 , we should document more the concept of delegating content routing. Areas to update:

• [x] Update "delegated routing" glossary item
• [x] Update https://docs.ipfs.tech/concepts/nodes/#delegate-routing-node
• [x] Mention someguy
• [x] Mention https://delegated-ipfs.dev/routing/v1/providers/

[BigLep]

@lidel please add if there's other places you think we should update

This is a step in support of https://github.com/ipfs/ipfs/issues/499

[2color]

Just did some testing now to see how https://trustless-gateway.link is supposed to be consumed.

Is appears that it's only supported as a path gateway and that passing ?format=car as a GET parameter is not supporterd.

Nonetheless, curl -H "accept: application/vnd.ipld.car" https://trustless-gateway.link/ipfs/bafybeidfqp36qutohidaaapir743mvjefv5ipkbrvqx3li3x6vm47vrdam > site.car works.

[lidel]

iirc:

• trustless.gateway.link/ipfs|ipns/ – yes, this is a bug (for mvp we only did Accept, ?format is something we need to add before adding it to docs) – adding separate location in nginx that matches [?|&]format=car|raw|ipns-record should be enough
• delegated-ipfs.dev/routing/v1 - we want to switch it to https://github.com/ipfs-shipyard/someguy (@hacdias is working on improving it) and set up some caching before we add it to docs (don't want to publicize this without having hit/miss caching in place for better ux/performance)

cc @cewood @ns4plabs for plan visibility (+ let us know, if we should block public comms on any additional work :pray: )

[2color]

Does delegated-ipfs.dev/routing/v1 currently support IPNS names?

It seems like it doesn't, e.g. https://delegated-ipfs.dev/routing/v1/ipns/k51qzi5uqu5dlvj2baxnqndepeb86cbk3ng7n3i46uzyxzyqj2xjonzllnv0v8 returns a 406

[BigLep]

FYI there is some sort of related content in https://github.com/ipfs/ipfs-blog/pull/640