At the time being, building decentralized social media applications on top of ipfs seems to me quite an hazard.
Imagine participating to a social network in which people can easily track and link your activity to your IP address. That is not good for social media app, it’s too risky.
My two cents. I might be wrong but to me it seems that the safest way to connect to the IPFS network is by means of a star-signaling-node - which however requires trust.
In addition, it might be unfeasible to delete some contents. This is a huge issue which, in my opinion, does not have enough attention. Let us move away for a second from IPFS and consider the Bitcoin Blockchain. What if someone decides to publish really sensitive data on the bitcoin blockchain? Imagine the crazy stuff people are willing to do during a war and imagine what could happen.
All in all, I think that it will be difficult to reach end-user at this stage and I suspect that what people are going to build will not help the end user having better products and experiences.
Finally, whatever the protocol, it’s hardly impossible to move away from the requirement of having a VPS.
Please do explain how you think that can happen?
What you describe is how the “old web” works. There you have a central server that serves the site. That central server can monitor (just the webserver logs really) and try to track users.
How does that same logic apply to a distributed network? You miss the central part to even be able to monitor. The most you can do is monitor who accesses the files on nodes you control. But if you site is populated on more nodes then even that kind of monitoring will - at the very least - be inaccurate and more likely to be just useless.
If you think that way, just use central servers. Why do you need trust? In IPFS the trust is guaranteed due to the hashing going on that your node internally verifies for you.
That’s both a strength and a weakness. A well known one.
While the data might be online and available through the network, that doesn’t mean it’s easy to find. Let’s continue your hypothetical case with something more tangible. Lets say a “youtube on IPFS” alternative exists. Somehow somewhere there needs to be a list of “files” to present on that site. You can - and in a distributed world should - use a mechanism where there is still a certain amount of control on that list. That would allow those in control to prevent certain entries from getting on it or remove them if they got on it. This doesn’t mean the data is gone. It only means the easy access point is gone.
Explain that please? You sound like you’re skeptical and try to motivate people not to use IPFS. Why?
Have a look at this (which does not depend on Brave by the way). If one develops a social media application he MUST informs users about that. Also, it seems that VPN and TOR might not be enough to really protect the ip address. And this is a problem.
If you have a solution, please tell me. Cause I wanted to build social application but I will not allow user to run their local node cause I will not jeopardize their privacy. Because of that, I prefer a star signaling server which must be deployed somewhere. And here is were trust is needed for the provider sees the connections. Yet, I still prefer this model.
Alternatively, the network could be really distributed with just local nodes and that would be really cool. Unfortunately it’s too risky. That’s my opinion.
I don’t think you can just put any information on Bitcoin blockchain.
It wouldn’t be possible to remove content easily, but that doesn’t seem to be a problem to me, this problem also exist centralized applications. Suppose you post a picture on Instagram, and someone have seen it and downloaded it. And later you delete the post, now there is no way for Instagram to remove the copy from the person who downloaded it. (Think this as caching in IPFS, and there is no difference)
A simple thing to remember, anything on client side isn’t secure, either it be centralized or decentralized apps.
I would agree on this, the end user doesn’t care anything about whether the backend is centralized or decentralized. At this stage the creators/developers of applications using these technologies are going to benefit more than the end user.
You may need a VPS in the beginning, so that at least one guaranteed peer will have the replicated database. This will ensure that your site won’t disappear into nothingness. But the advantage would be, the more the number of users the less you spend on resources.
You can think about BitTorrent, it is a technology useful for sharing large files and will cost less for creator of the file to distribute the file. But it is has become a synonym for piracy, I can think the same thing will happen to IPFS, it’s features will do more bad than good.
On the bitcoin blockchain you can post string data, the only constraint, as far as I know, is that the more data you write the higher the fee you have to pay. However, nothing prevents you from delivering the contents in different transaction would there be a kind of max size limit.
Thank for your first point and example with Instagram, I think you are correct.
Could you explain more in depth your point “anything on client side is not secure”, what do you mean precisely?
So you want full 100% anonymity.
Using IPFS would already be many many many times better then a normal website.
I think you’re misreading the notes from Brave as a concern for you.
Let me put it in the most clear terms i can imagine: you don’t know who visits your site therefore you can’t track your users.
Now that statement is true if your site is distributed enough. As the users amongst themselves keep the site online.
Even when users interact with your site you only - i repeat, only! – see their CID. A CID (in IPFS, not true for IPNS) cannot be traced back to a specific user.
As for your local node reluctance. Forget it. If you don’t want a local node then just forget about IPFS. IPFS lives by the sheer number of users running a node. If you don’t want to participate then don’t use it.
It will be, the issue is that IPFS is BIG and we need to cover anything.
For example a dumb Tor transport might work but will not protect you from DNSLink leaks, so you need to cover that too. You also need to cover the 0.0.0.0 resolver, maybe it also leaks IPs.
It’s not so much of “can’t be done”. But more of: “require A LOT of security audits”
lol watch your tone.
First, I do not want 100% anonimity I am just trying to understand. You said I did not understand, so please explain, if you can of course.
It seems to me that the ip can be linked to the peer ID thorugh the DHT table. If this is not possible just tell me it is not possible and this is fine. https://news.ycombinator.com/item?id=12719771
And about your final point. I was just thinking about that running a browser node is MORE SAFE than a local node, so please teach me coding not decentralization
If you want 100% anonymity then,
IPFS with I2P is best for protecting everyone’s privacy, nobody reveals there IP address but still use BitTorrent like technologies, only significant drawback the network is too slow, which would change as the number of nodes increase on I2P network.
Let’s take example of Netflix, anything available on Netflix is being pirated easily, now Netflix maybe using encryption and other standards to protect there content from being pirated, but anything that is delivered to client side will be misused in someway.
YouTube Vanced is a mod version of YouTube where there are no ads, now this is a different client that the original YouTube, but Google simply can’t stop this from happening.
People think encryption will protect everything, this is good for transferring something between 2 trusted parties, so that middleman couldn’t do anything, but whenever you are sending to a client, you should never trust it.
That’s why these companies trust on law and order not there client side apps.
JuST DoNt PUt youR IP In ThE DhT ThEN. (use IPFS over Tor or i2p).
The issue again, is that writing a good tor or i2p transport require covering lots of conner cases and features.
Again.
You don’t know the peer id’s.
There is no central place for you to “monitor for peer id’s”.
You’re concerned about something you should just forget. You don’t see peer id’s. Period.
You will see CID’s (content identifiers). You cannot trace back a CID to a peer id.
So therefore you cannot trace a CID back to an IP.
I’d advice you to just try and make something. You’re scared of problems that are really the least of your concerns when using a distributed technology.
Maybe I’m being pedentic, but you do see Peer IDs, you just don’t really know what they do.
For example you can do
ipfs dht findprovs Qmfoo
To find peerIDs that host the file Qmfoo.
Then:
ipfs dht findpeer 12DFoo
To find their addresses (so IPs if they don’t use Tor).
But you don’t know if that is caching, if this node is lying when they say they host that file just to throw you off or if they actually created a file.
This is what I found on the Ipfs docs about privacy. It seems to me that what you are saying is, if not totally false, at least misleading. In any case, a social media app in which IP are easily linked to id it’s dangerous. If you think it is not it’s the problem of your end users, not mine.
Finally, thank for your advice but I am building something. What I am saying is that for now i prefer using the star signaling server. You are just saying the problem does not exist. Maybe I have to study more, and I will continue to do it.
Correct me if i’m wrong, but that’s when you actively search for who hosts a given CID.
In a website or app context you will never see that, right?
So I have begun working on something like that though it will probably turn out to be a microblogging platform eventually.
You have to think of this differently.
Data on the IPFS will ALWAYS be public, so f you are looking at privacy from the perspective of making it hard for people to download someone else’s photo or get someone’s personal details, then you need a more centralized approach. Maybe IPFS isn’t the best for that. I am sure that what you are storing with OrbitDB can also be accessed in some way from IPFS like @Jorropo demonstrated its possible to get peer ids for a file on IPFS.
Think of it like this:
SINCE you ALWAYS know WHO uploaded a file to IPFS, you can ALWAYS verify who is the OWNER of the file.
Maybe you can write a function that just checks whether the user has got the file from somewhere (that he is trying to upload to your website/app) or he created the file on his own system using the website/app. If he wants to still upload the file to IPFS, he can still do that but it won’t be part of YOUR network since YOU have complete control over that. You can list whichever files you want on your website/app and no one can inject files into your DAGs - which is why IPFS.
Your Merkle DAG is YOURS. Completely.
For more on that you should definitely do this course:
Thank you for your answer. I completely agree with you, however to me the problem is not about the the fact that it’s possible to infer who is the owner of a file but the possibility of finding the link between her id and her ip through the dht
