Telegram Web on IPFS: is it more secure?

I have build (for experiment) Telegram Web/K and pin it on IPFS.

Now I’m trying to understand – is it more secure that usual web telegram or not …

Original post (my):

It depends.
If you open telegram web using the official link you trust the http webserver that is giving you thoses files.
If someone hacks telegram’s servers they could smuggle a version with a backdoor.

Using IPFS you only trust the CID, if you use a random CID it’s not better than just using the web version.
However unlike an http server a CID doesn’t change, if you know a CID is good it’s not possible for it to be changed to a bad version (while a good http server can be hacked or changed).

Also the CID contain the hash which makes chains of trust way better.
For example you can imagine a dev DAO that publish the official URI. If that a webserver the same webserver trust issue can happen (the server can being hacked without the consent of the DAO), that not possible with CIDs because the CID is immutable.

Since you built it yourself it should be better from your point of view. Because instead of trusting the source code, the guy who did the compiling and the http server.
But with IPFS you only have to trust the source code. (you also need to trust the guy who created the CID and who did the compiling but thoses guys are you).

For me it’s worst to use IPFS because I have to trust a random (you) that you correctly did the compiling and IPFS addition without adding a backdoor (I preffer trusting the telegram team rather than a random guy on internet).

Yes, I see.

I guess it’s a real problem with web services on IPFS as no one trust no one by default.
When I share files are just files, but when someone shares smth like code – how to assure people to trust you?

Hi! I think, IPNS can be used to build a web of trust. Trusting the code in most cases is trusting the project maintainer or (the better) a team of maintainers. But if we talk about trusting web services in a peer-to-peer network — that’s another story as we can’t check which code runs on a particular node that provides the service. However, the project maintainer could potentially point out which nodes are authorized — i.e. which nodes does he/she trust to run the code on behalf of him/her (and the whole project). That’s like the classical web hosting: the project maintainer selects a hosting provider to run the application. But it’s not like the classical web hosting as a) the hosting providers are nodes on a peer-to-peer network, b) a number of providers can be authorized, c) no DNS is needed, d) the trusting relationships are explicit and automatically verifiable.

For more information, please, take a look at A preliminary discussion of the “Workswap” protocol .

I don’t sure that understand you correctly.
Particularly this Telegram Web is serverless, you (if you use it) just fetch html/js/css and run TWeb on you local node in browser like static web page. So as I see there are no nodes which you have to trust – you run everything locally, isn’t it?

Of course you have to trust code author and the person who built web app

Yes, in the case of Telegram Web as you described it, the only use of IPFS is to transfer html+js+css content. In that case there is no need for trusted nodes (except the Telegram servers — but that’s another story). However, above you’ve mentioned the different problem — «a real problem with web services on IPFS». If I’ve understand you right, you’ve mention it in a course of some general thought about web services on IPFS, not just about sharing a pre-built software. That general question is interesting to me, so I’ve reacted.

when someone shares smth like code – how to assure people to trust you?

I think, there are two cases. In the first case you share the code as an ordinary file (technically, source and compiled code really is a file or a set of files). In the second case you want to share the result of an execution of some code — and that is a completely different thing as CID isn’t applicable there. And so you have to trust. What about giving a try to the idea of web-of-trust in that case?