Show HN: Decentralized P2P Messaging with Blockchain Verified Identities
stealthy.im
stealthy.im
1. How decentralized is this dAPP? Stealthy is decentralized in two main ways. The first is that it does not require a centralized signaling server to establish connections, when two people have added each other as contacts. That of course requires that they initially co-ordinate outside of stealthy (though we do however have a convenience mode that does a one-time centralized introduction / discovery service if both users have that enabled). The second is our storage, which is built atop Blockstack's GAIA storage system (more info here: https://github.com/blockstack/gaia).
2. How secure is Clientside javascript crypto? In other HN posts, I've seen quotes like: 'Nobody who's serious about security is going to use an app that does crypto in javascript. Why not make browser plugins to avoid this complication?' and posted the classic Javascript cryptography being considered harmful article. Blockstack gets around this in a way similar to being a plug-in with their one-time browser download (which is essentially a node process that also has your crypto keys/generation capabilities so you're not transmitting those back and forth for acquisition purposes). You can find more information on that subject in this forum post: https://forum.blockstack.org/t/blockstack-vs-clientside-js-e...
You can store your files redundantly on S3, Azure, Google Cloud, Dropbox, and even IPFS. We just have to enable all those drivers :)
- How are my messages to another user retrieved from my encrypted storage? - Does sending you a message push the message into your storage? - Do I (i.e., my Blockstack node) have to be online for my message to you to be retrieved later (say, the next time you're online)?
We have offline messaging (file polling) and online messaging via WebRTC.
You don't have to be online, your contacts are polling your storage and as long as your storage is online, the messages will be sent.
We're also considering ephemeral messages so the messages aren't stored at all.
I admit to being out of my element on this, so I may not be phrasing things correctly, but reading through this discussion it seemed like there would be lots of public metadata for a would-be attacker to work with.
Thank you lawl & 18pfsmt for highlighting protection of metadata vs. content. At this time protecting content seems like the minimum bar by which one should measure, with metadata protection being the ultimate goal without sacrificing performance or convenience.
Signal for example is great when it comes to confidentiality and actually easy enough to use so my mom messages me on signal, not so great when it comes to not leaking metadata. Nobody else I know uses Tox. But I know that when I use Signal it's a trade-off I'm fine with, but I'm aware of it.
Your comments and 18pfsmts got me thinking about metadata from a different angle than I had been considering prior--that of a state actor's capability to observe the entire network. Your comments never came across as negative.
> Tox generates a temporary public/private key pair used to make connections to peers in the DHT. Onion routing is used to store and locate Tox IDs, to make it more difficult to, for example, associate Alice and Bob together by who they are looking for in the network.
Again, I'm not sure if that'd be all that helpful in a case where e.g. Azure sees all the edits, I think timing attacks are pretty simple when you see the entire network. But then again, I'm not an expert and I also have no clue how your software works, so i don't want to go out on a limb.
What is the centralized storage used for? Offline messages and history sync between devices? edit: i didn't see the dAPP part, is it also used in P2P messaging?
How does your decentralized lookup avoid leaking friend requests out into the open?
On your website it also sais you use WebRTC for P2P communication. Am I correct in my assumption then that the STUN/TURN/ICE server at least knows who started talking to whom and when?
I really miss a detailed architecture/protocol overview. It doesn't have to be as detailed as for example the signal docs[0], but just something to be able to understand your architecture and the choices you made on a high level.
1. "A blockchain, implemented using virtualchains [6], is used to bind digital property, like domain names, to public keys. Blockstack’s blockchain solves the problem of bootstrapping trust in a decentralized way i.e., a new node on the network can independently verify all data bindings." [https://blockstack.org/whitepaper.pdf]
2. I believe collecting an email is required in case you need to recover your 12 word pass phrase.
3. The default storage that comes with a Blockstack account is a Microsoft Azure Blob. If you implement your own GAIA hub, you can circumvent that with a number of other options, but conventionally you would refer to the other options as 'centralized' too. Consider this though: "We decentralize data storage with relationship to trusted 3rd parties - remove control from app developers, cloud storage providers, etc and give it to users." [https://forum.blockstack.org/t/gaia-decentralisation/4275/2].
Anyway, each user's storage is used for the following things: - contact lists - conversations - offline messaging - initiating WebRTC connections
It is all encrypted client side.
4. We have two forms of discovering users.
The first is where the users coordinate outside of Stealthy to add eachother as contacts--at this point communication is established only between the two chat clients with no third party, consequently there is not traditional leakage that may occur in this mode.
The second (which can be disabled from options) uses a centralized DB and listeners to simply exchange the notion that someone wishes to talk to you. If that centralized DB were to be hacked, that request could theoretically be leaked. The invitation to talk only occurs initially when both parties are not within eachother's contact lists.
5. We do use WebRTC for P2P communication and it can be disabled from the options or during initial configuration. The STUN/TURN/ICE server could certainly acquire some of the information that you mention.
6. We agree with your notion of an architecture / protocol overview and are currently considering precisely how we will proceed with that. Earlier this month we spoke with a representative from the EFF and their advice was to publish a paper on the subject and then commence with formal review of our work, similar to Signal.
Hopefully this helps.
edit* looks like the identities are stored in a decentralized manner, and that all of this should integrate with blockstack's keychain and browser
The reason you need an .id is because we have to register your identity on the blockchain and propagate your zonefiles.
We can help you register a .stealthy.id that gives you access to the tool if you create an account today :)
How do you deal with illegal content? Aka people using this service to host bad content.
We don't host any data, it's stored in the users data store; the user controls all their data.
An interesting architectural point is that because you as the user choose your storage provider, you are essentially hosting bad content along with your storage provider. We and Blockstack simply provide you with a means of transporting your data to others without getting in the middle.
*Edit: Though recently I've been considering the system and Stealthy's use of it for scaling purposes and it's likely that we'll be looking into running our own hub(s). A brief discussion on throttling of the free hubs, best practices, and performance here: https://forum.blockstack.org/t/gaia-read-write-and-throttlin...
How does stealthy address this issue?
"Your identity wallet and master private key are controlled by a locally-running node.js process. The Blockstack Browser code is served locally, so none of the concerns about remote code injection apply. The crypto code for this is downloaded once when you install it."
More information in the thread here: https://forum.blockstack.org/t/blockstack-vs-clientside-js-e...
* "Can Blockstack control my data or ID when I use it? No. When you're using a Blockstack client you control your data and ID with a private key. This private key never leaves your device and is meant to stay on your laptop/phone. As long as no one gets access to your private key, no one can control your data or ID. When you use Blockstack, by design, your private keys are never sent to any remote servers." [https://blockstack.org/faq]
* "The main difference between blockchain identities and accounts on any other service is that blockchain-based systems have strong ownership. Blockchain identities can't be confiscated by any service because the system defines ownership according to ownership of public-private keypairs, just like ownership of coins on Bitcoin. This is in direct contrast to Twitter or Facebook usernames, which could be confiscated or censored at any time by the respective companies that they belong to." [https://blockstack.org/posts/blockchain-identity]
* "Identity is user-controlled and utilizes the blockchain for secure management of keys, devices and usernames. When users login with apps, they are anonymous by default and use an app-specific key, but their full identity can be revealed and proven at any time. Keys are for signing and encryption and can be changed as devices need to be added or removed." [https://blockstack.org/intro]
The thing I've been wondering is how this works without a Blockstack ID? What does someone do if they don't have an ID?
Good news is we can register you for a .stealthy.id when you create your account and thus you don't have to pay for a Blockstack ID.