Live gateway list?

[JustMaier]

It might make sense to add a feature to IPFS gateways to opt-in to gateway announcement. This gateway checker could then pull the list of gateways from that announcement. I'm not sure the best way to announce your gateway availability to the network, but two things come to mind (I'm new to all of this, so these might be completely unfeasible):

1. PubSub: potential gateways could join a PubSub topic and announce themselves periodically
2. DHT: potential gateways could add themselves as gateways.

One concern is that this would result in a lot of noise, so I wonder if a static list is also maintained (like the one here), but it's used to signify that a gateway is verified/trusted.

[lanzafame]

//cc @mburns @olizilla

[jamiew]

Cool idea

Could we implement this right now just by using something like a public_gateways pubsub topic?

Maybe this could be a small daemon people ran alongside their IPFS node which cached those topic replies, maybe checked on health from time time, then made that list available via a simple HTTP API? Any other ideas for how a static status page like this could query for live public gateways without using a cached list or a centralized webservice?

[JustMaier]

It'd be cool if it was an HTTP service provided by every gateway. Basically, pick a gateway you trust, then get this list of available gateways from them.

Alternatively, gateways could essentially load-balance by redirecting requests to other online trusted gateways. Basically, by opting in to be a public gateway, you become a part of the load-balanced gateway network. You could probably bake it into the js-http-api as well so that it pings a member of the gateway network to get the best gateway for the client.

[jamiew]

I was thinking the same thing but figured it'd be a lot harder to get into the official daemons vs. running a sidecar. Do you think it's worth going that route for a v1?

[JustMaier]

I'd say it really depends on whether or not there is much interest in this. If the core team thinks it's a good idea, I'd say fork the daemon and add it there. If there isn't much buy-in, you're right, a sidecar would be better.

Either way, it'd probably be good to start a discussion about this on the daemon repo (not sure which one would be best since they are fragmented by language).

[jamiew]

A side daemon could hypothetically also report general node metrics, like Ethstats IIRC that project was also originally a side process, but was eventually integrated into geth and parity

On Mon, Jul 8, 2019 at 6:05 PM Justin Maier ***@***.***> wrote: I'd say it really depends on whether or not there is much interest in this. If the core team thinks it's a good idea, I'd say fork the daemon and add it there. If there isn't much buy-in, you're right, a sidecar would be better. Either way, it'd probably be good to start a discussion about this on the daemon repo (not sure which one would be best since they are fragmented by language). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#61?email_source=notifications&email_token=AAAAO37L2JAMM7GBPVFFAKLP6O2Y5A5CNFSM4H5H6GV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOPQZQ#issuecomment-509409382>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAO32ASYO2KOKT37Z3FSLP6O2Y5ANCNFSM4H5H6GVQ> .

-- @jamiew <https://twitter.com/jamiew> | https://jamiedubs.com <https://www.jamiedubs.com/>