Am I right that these types of solutions would essentially need to be part of the ICP protocol suite to have the same gaurantees that ICP generally provides to canisters?
In the case of a bridge, the canisters are pretty unaffected, they just run on the Internet Computer and HTTP requests might arrive as specific anonymous queries – what guaranteeds towards canisters do you think about?
In terms of guarantees towards the users, matters are different, and I am not sure how some of the guaranteeds (e.g. certification of results) could be delivered… but if we’d knew all the answers, we probably had long built this feature
As I tried to explain above: I don’t think a bridge feature needs to textend the core system (i.e. the stuff that runs canisters, does consensus etc). Why should it? What would that even mean?
The bridge run on the same infrastructure… but that seems a rather minor point to me at this point.
Is that what you’re suggesting for now?
Yes! The difference between what you describe (and what, incidentially, I built as a proof of concept at GitHub - nomeata/ic-http-lambda: A HTTP-to-IC bridge (proof of concept)), and this being an official feature in the Internet Computer, is merely “are we using the same infrastructure that happens to also run the core Internet Computer, or are we using a separate one”.
(others could help of course, but it wouldn’t escape being a legacy system like any other).
Yes… but the Internet Computer itself runs on “legacy systems” after all! It’s not like the Internet Computer is a magical thing that doesn’t need hardware, and networks, and firewalls, and persistence, and DOS protection. Quite contrary: It has to deal with all the things so that Canister application developers don’t have to.
Same with that bridge. If someon like you wants to help the Internet Computer to succeed, and if you think the HTTP bridge is essential, and somehow DFINITY doesn’t build it for you, then you can build and host and run and scale that so that Canister developer’s don’t have to worry. And if you want it to be more reliable and failsafe by being decentralized, well, then make it so. (Not you personally – the community.)
Or, eventually, you can make a proposal to include it in the software for the nodes that happen to run the ICP itself, and re-use the same infrastructure. This may be convenient and the right thingin the long run. But the point I am trying to make is that it is not an absolute must for this feature. (There are other features that absolutely must be part of the protocol to make sense. HTTP acces is not one of them.)